FreeBSD is unsupported (but there is a workaround!)
Trying to run slskd as a daemon on FreeBSD12.3-p6 and it tells me it can not find the icu-libs, albeit devel/icu is installed in the newest version and /usr/local/libdata/pkgconfig/icu-i18n.pc is present. Can i link that or something else to the proper path to make it work?
I've added freebsd-x64 and freebsd-arm64 runtime targets in #906. Please give one of these a shot (once they are published in a little bit!) and see if that resolves your issue (I'm somewhat doubtful).
I did find this documentation that describes the dependencies needed to build the dotnet runtime; it may provide some clues but will almost certainly list stuff you don't need, since you aren't building the runtime, just running it.
There's also a somewhat lengthy open issue in the runtime repo here. The fact that it's still open is not a great sign.
I'll leave this issue open; if you happen to get it working please follow up!
Unfortunately the new freebsd runtime IDs are just for show and the release based on #906 failed. I'm reverting the inclusion of those RIDs in #907.
I think there may be a way to get this working but you'll likely need to compile your own .NET runtime, and if you get that working, you'll need to build slskd from source and omit the self-contained executable flags.
Sad it did not work out. Hopefully some times this can be implemented. Alternatively, since i dont need all that unicode stuff since the files are in ANSI only, maybe there is a way i can set the parameter "configuration flag System.Globalization.Invariant to true", somehow for slskd on FreeBSD, too?
FWIW, I use slskd under FreeBSD/x64 with decent results. I experience the occasional crash but otherwise it's working very well.
I use it with SDK 7.0 from https://github.com/sec/dotnet-core-freebsd-source-build. After building, I had to symlink bin/Release/net7.0/libe_sqlite3.so -> /usr/local/lib/libsqlite3.so (from pkg install sqlite3). I'm not a .NET guy but this had to do with not being able to install a package. Apparently the native shared lib is similar enough that it works.
@jonasoh thanks for sharing the workaround! I've updated the title of the issue to reflect this.
Quick update to this. FreeBSD now has an official port for dotnet (lang/dotnet), making its installation a bit more convenient. Just compiled slskd with it and it seems to be working great. There is no nuget yet so symlinking libe_sqlite3.so to /usr/local/lib/libsqlite3.so is still required for running the executable.
I've been using slskd (0.20.1 (0.20.1+220189e3)) in a FreeBSD 14.0 jail for a few months now, and it works pretty well. I'm running .NET 8.0.100 and had to do that same SQLite library symlink to get it to work. I don't know which of my issues (may) have been fixed in a newer build of dotnet.
Notes:
- .NET doesn't want to be built in a jail, or run in a jail, and will give you some errors. I had to add
allow.mlockto my jail's config to get this to work. I think this is fixed or will be fixed soon. - Sometimes when I do a search, .NET crashes. It only happens when on some searches, but it seems like it always happens when I do certain searches. I have the service set up to restart when it fails so it's not the end of the world. Once it resumes, the failed search shows in the UI as still going, but the stop button does nothing and I can't delete it without going into the DB and changing the search status to completed first. Sometimes the stack trace is a little different, but it's always error
0x80131506and it always passes throughThreadPoolWorkQueue.Dispatch().
Anyway, slskd on FreeBSD is pretty dang serviceable as-is. I suspect the issues are entirely within dotnet, but I felt inspired to share.
A stack trace from the error I mentioned:
Fatal error. Internal CLR error. (0x80131506) at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task, System.Threading.Tasks.ConfigureAwaitOptions) at System.Runtime.CompilerServices.ConfiguredTaskAwaitable1+ConfiguredTaskAwaiter[[System.__Canon, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].GetResult() at Soulseek.Network.PeerConnectionManager+<>c__DisplayClass33_0+<<AddOrUpdateMessageConnectionAsync>g__GetConnection|2>d.MoveNext() at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1+AsyncStateMachineBox1[[System.__Canon, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[Soulseek.Network.PeerConnectionManager+<>c__DisplayClass33_0+<<AddOrUpdateMessageConnectionAsync>g__GetConnection|2>d, Soulseek, Version=6.4.1.0, Culture=neutral, PublicKeyToken=null]].ExecutionContextCallback(System.Object) at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1+AsyncStateMachineBox1[[System.__Canon, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[Soulseek.Network.PeerConnectionManager+<>c__DisplayClass33_0+<<AddOrUpdateMessageConnectionAsync>g__GetConnection|2>d, Soulseek, Version=6.4.1.0, Culture=neutral, PublicKeyToken=null]].MoveNext(System.Threading.Thread) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1+AsyncStateMachineBox1[[System.__Canon, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[Soulseek.Network.PeerConnectionManager+<>c__DisplayClass33_0+<<AddOrUpdateMessageConnectionAsync>g__GetConnection|2>d, Soulseek, Version=6.4.1.0, Culture=neutral, PublicKeyToken=null]].ExecuteFromThreadPool(System.Threading.Thread) at System.Threading.ThreadPoolWorkQueue.Dispatch() at System.Threading.PortableThreadPool+WorkerThread.WorkerThreadStart()`
Hi there,
I've never used dotnet before so it was not entirely sure how to build/install, took a bit of time, leaving my steps here for whoever in the same situation as me in the future. Thanks a lot for slskd, still missing a few things, but it's already my fav slsk client!
pkg install dotnet sqlite3git clone https://github.com/slskd/slskdcd slskd- in
src/webnpm installnpm run build
rm -rf src/slskd/wwwroot/cp -av src/web/build src/slskd/wwwroot- in
src/slskddotnet build --no-incremental --nologo --configuration Releasedotnet publish --configuration Release -p:PublishSingleFile=true -p:ReadyToRun=true -p:IncludeNativeLibrariesForSelfExtract=true -p:CopyOutputSymbolsToPublishDirectory=false --self-contained --output ../../dist/freebsd-x64
- in
dist/freebsd-x64ln -s /usr/local/lib/libsqlite3.so libe_sqlite3.so./slskd
aaaah so many thx @320x200 !!! this worked! was doing this in a jail on TrueNAS facilitating 13.4 release image.
a little detail for those who'll be doing this on TrueNAS (in a bsd jail): allow_mlock jail property should be enabled in order for the jail to execute dotnet binary. there's multiple explanations on this detail with dotnet and mlock for those who interested, but not a subject to our topic.
@320x200 what a magician you are! was hoping to find some recipe for this for a year!!!
someone clever, please merge this into pkg, make a target in Makefile or whatever=)
Has anyone created a working rc script for this? Every time the program starts it fails with "Failed to resolve hostname vps.slsknet.org"
Everything else works.
How does slskd try to resolve the hostname when it runs?
Here's my rc script:
#!/bin/sh
# PROVIDE: slskd
# REQUIRE: DAEMON NETWORKING
# KEYWORD: shutdown
# Add the following lines to /etc/rc.conf to enable slskd:
# slskd_enable : set to "YES" to enable the daemon, default is "NO"
. /etc/rc.subr
name=slskd
rcvar=slskd_enable
load_rc_config $name
slskd_enable=${slskd_enable:-"NO"}
logfile="/var/log/${name}.log"
slskd_chdir="/root"
procname="/home/sue/slskd"
command="/usr/sbin/daemon"
command_args="-u sue -o ${logfile} -t ${name} -r /home/sue/slskd"
run_rc_command "$1"
(assuming that you're running slsk as a user named sue and that your slskd binary is in that home directory)
I ran into that same hostname resolution issue. I'm trying to remember what the cause was - I vaguely remember deciding it was a dotnet bug. In any case, my lazy solution was to put vps.slsknet.org and api.github.com into my hosts file. Resolution stopped failing and the server could start and do update checks normally.
Okay, having gone back through my notes, I do believe it is due to the use of Dns.GetHostEntry in the Soulseek.NET library, which fails when your host can't retrieve PTR records for a lookup, apparently.
This comes into play when ConnectAsync is called here
Interesting. I tried adding that to my hosts file as well, but still couldn’t run it.
I’m not running the program from the users home directory. I’m just running it out of /usr/local/www/slskd but with slskd as the user.
Would that affect anything?
BTW, the program runs flawlessly when just running it from the command line. This only arises when it is invoked via the rc script.
The rc script won't run your program unless you modify it to match your configuration, which is an exercise left to the reader.
The rc script won't run your program unless you modify it to match your configuration, which is an exercise left to the reader.
My rc script works fine. It loads everything, the WeUI etc…
The only thing that doesn’t work is resolving the hostname.
I think I've got it. The problem was the chdir needs to be set to the below, then it works.
${name}_chdir=/root
Here is my rc script
#!/bin/sh
#
# PROVIDE: slskd
# REQUIRE: DAEMON NETWORKING
# KEYWORD: shutdown
#
# Optional settings:
# slskd_enable (YES/NO): Enable or disable the service.
# slskd_user (system user): User to run the service as.
# slskd_group (system group): Group to run the service as.
# slskd_appdir (path): Path to application data.
# slskd_config (file): Path to application configuration file.
. /etc/rc.subr
name=slskd
rcvar=slskd_enable
load_rc_config $name
: ${slskd_enable:="NO"}
: ${slskd_appdir:="/usr/local/www/slskd"}
: ${slskd_config:="${slskd_appdir}/${name}.yml"}
: ${slskd_user:="soulseek"}
: ${slskd_group:="soulseek"}
slskd_chdir="/root"
pidfile="/var/run/${name}/${name}.pid"
command="/usr/sbin/daemon"
command_args="-P ${pidfile} -H -o /var/log/${name}/${name}.log ${slskd_appdir}/${name} --app-dir=${slskd_appdir} --config=${slskd_config}"
start_precmd=${name}_startprecmd
${name}_startprecmd()
{
mkdir -p /var/run/${name}
mkdir -p /var/log/${name}
chown -R ${slskd_user}:${slskd_group} /var/run/${name}
chown -R ${slskd_user}:${slskd_group} /var/log/${name}
}
run_rc_command "$1"
And if anyone wants an easy install script, see https://github.com/tschettervictor/bsd-apps/tree/main/slskd
Greetings again. Now we are running into this issue. It is failing to build on FreeBSD 14.x with the following error.
/slskd/src/slskd/slskd.csproj : error NU1101: Unable to find package Microsoft.NETCore.App.Host.freebsd-x64. No packages exist with this id in source(s): /usr/local/share/dotnet/library-packs, nuget.org
Restore failed with 1 error(s) in 8.2s
/slskd/src/slskd/slskd.csproj : error NU1101: Unable to find package Microsoft.NETCore.App.Runtime.freebsd-x64. No packages exist with this id in source(s): /usr/local/share/dotnet/library-packs, nuget.org
/slskd/src/slskd/slskd.csproj : error NU1101: Unable to find package Microsoft.AspNetCore.App.Runtime.freebsd-x64. No packages exist with this id in source(s): /usr/local/share/dotnet/library-packs, nuget.org
/slskd/src/slskd/slskd.csproj : error NU1101: Unable to find package Microsoft.NETCore.App.Host.freebsd-x64. No packages exist with this id in source(s): /usr/local/share/dotnet/library-packs, nuget.org
Restore failed with 3 error(s) in 7.4s
Checking https://www.nuget.org/packages?q=freebsd shows that the packages for FreeBSD are deprecated. Also, I cannot find those exact package names there at all.
The packages do seem to exist inside /usr/local/share/dotnet/library-packs so I'm not sure what is going on really.
Has anyone been able to build this lately under FreeBSD 14? @panzertime @tulse-luper @320x200 @jonasoh
Hi @tschettervictor, I have made some progress getting it to compile on FreeBSD 14.2-RELEASE. First, I tried using the lang/dotnet8 port, but this seemed to cause some issues (perhaps related to the freebsd.14-x64/freebsd-x64 difference in RIDs).
Then, i changed the TargetFramework to net9.0 in slskd.csproj and made a symlink for the sqlite lib (sudo ln -sf /usr/local/lib/libsqlite3.so /usr/local/share/dotnet/shared/Microsoft.NETCore.App/9.0.3/libe_sqlite3.so). This makes dotnet run and dotnet build work (in the src/slskd dir). However, dotnet publish still fails due to some issues with the tests.
I know next to nothing about .NET, but it seems to me that the problem seems to be caused by incompatibilities between the dotnet and dotnet8 ports...
It is possible to change the identifiers/versions in the system .nupkg files (these are apparently just zip files), but I didn't get to a working state using that method.
So, this is what I do to compile slskd on FreeBSD 14.2, currently (with lang/dotnet 9.0.3):
cd src/slskd
sed -i '' s/net8.0/net9.0/ slskd.csproj # set the target framework to net9.0
dotnet publish \
-c Release \
--runtime freebsd.14-x64 \
--framework net9.0 \
-p:ReadyToRun=true \
-p:PublishSingleFile=true \
-p:IncludeNativeLibrariesForSelfExtract=true \
-p:Version=$(git describe --tags --abbrev=0)+$(git rev-parse --short HEAD) \
--output ../../dist/freebsd.14-x64 \
--self-contained &&
ln -sf /usr/local/lib/libsqlite3.so ../../dist/freebsd.14-x64/libe_sqlite3.so
I don't know what difference the --framework and --runtime options do, if any. the -p:CopyOutputSymbolsToPublishDirectory=false, which is used in the bin/publish script, makes the build fail so it's been omitted here.
EDIT:
It's working. I forgot to set allow.mlock inside my jail. But I'm still getting the same errors when building.
I tried removing the --runtime freebsd.14-x64 as well as changing it to freebsd-x64 but no go.
When set to freebsd.14-x64 it says it can't find the runtime identifier.
EDIT 2:
It's working. On my 14.1 jail, for some reason the files in the library-packs directory are freebsd.13-x64 instead of 14.
Added a variable to my install script that defaults to 13, but can be changed by the end user.