Please, please FreeBSD gurus, I need your help! 🙏

[winnielinnie]

@victor

You said here that this works.

It works, and I guess it’s good enough for now.

EDIT: Correction, it’s exhibiting the behavior of “no internet” again. Now I’m trying to backtrack how it worked the first time.

---

I thought custom rc.d scripts were fairly intuitive, but apparently there’s more under-the-hood of FreeBSD that I don’t understand.

Interestingly, I think this might be the application itself (slskd). The reason I suspect this is because if I use the same rc.d script, but change the command to a simple ping -c 4 vps.slsknet.org, it pings the server without issue.

Likewise, other rc.d scripts for ports built against FreeBSD connect to the internet just fine, and they use similar syntax and layout.

[victor]

They are intuitive once you understand how they work. I struggled for a long time trying to figure out the “failed to set user environment” issue.

I finally had to just go read the manual, which was extremely helpful.

Do you mind sharing how you installed the app? I could try to run it myself.

[winnielinnie]

@victor

Do you mind sharing how you installed the app?

I followed the instructions from here.

Keep in mind that his “steps” are not entirely accurate, as he mixes plain English “in” with explicit commands of “cd”.

Just notice when to “correct” some steps. Otherwise, you’ll find that some steps will say “file/folder not found”.

Essentially, at the very end you’ll have a directory named freebsd-x64 under the “dist” folder. This contains the executables, libraries, and web files. It can be renamed to slskd and copied to /opt or wherever you prefer. (I like to use /opt for applications built/installed that do no exist as official ports or packages.)

You’ll obviously need git and npm, so his first command might as well be:

• pkg install git npm dotnet sqlite3

Contents of my /opt/slskd after everything is finished

config
etc
libe_sqlite3.so → /usr/local/lib/libsqlite3.so
LICENSE
slskd
wwwroot

There’s a YAML config file that doesn’t exist, but it can be copied from config/slskd.example.yml and copied into the user’s local directory at $HOME/.local/share/slskd/slskd.yml

You absolutely need to uncomment and edit the following lines to create a user account to connect to the Soulseek Network. As long as the username is not in use, it’ll automatically login as “this” account. So for testing purposes, you can make it very random. I’ll provide an example that you can change accordingly.

You must uncomment those three lines, and only edit username and password. The “spacing” must be kept intact, so only remove the # symbol with a single DEL or BACKSPACE stroke.

 soulseek:
#   address: vps.slsknet.org
#   port: 2271
   username: RandomHuman1234
   password: 1234WXYZ

It’s up to you if you want to change some defaults in the slskd.yml config file. (The default username/password for the web GUI is slskd/slskd, and the default HTTP port is 5030.)

The moment you login, you’ll see if it’s connected to the Soulseek Network. (The logs will also provide additional information, which are accessible in the web GUI → System → Logs)

I’d recommend, of course, running the executable manually to confirm it connects before trying the rc.d method.

---

When all is said and done, even if this can work as an rc.d service with full internet access running as root, I still will not run it as root, and would rather keep it as a non-root user. (I used pw to create the user soulseek before I built this application.)

[victor]

Failed to create CoreCLR, HRESULT: 0x8007FF02

When running the “dotnet” build command.

Mlock mlock

[John]

Have you tried an alternate client?

This one is the ports tree.

Nicotine+

[victor]

I’m not getting it to work using the RC script. The only way it seems to work is by using the root user.

[winnielinnie]

@John

This one is the ports tree.

https://nicotine-plus.org

That’s a graphical desktop application.

---

@victor

I’m not getting it to work using the RC script. The only way it seems to work is by using the root user.

Sadly, it seems there’s “something” about this application (which never got first-class FreeBSD support) that doesn’t play nice when running it as a service with a non-root user.

So it’s either RC script + run as root, or just use @Jailer’s method of adding it to the user’s crontab, and setting it to run “@reboot”.

[victor]

I think it’s more of an issue with the way service scripts run. Because it seems to run fine when you login with that user and then run the command.

[John]

That’s a client. …So this thing you’re trying to compile and run is a server then.

The idea I was going on was that they may not have implemented the daemon code properly (-i.e. maybe they fork the child, sit and wait, but they don’t handle the signals all that well. *shrug* I’m just working through an idea). Which .net did you install (7,8,9) BTW (maybe there is something there with the version and mlock)?

Have you tried:
https://man.freebsd.org/cgi/man.cgi?query=daemonize&apropos=0&sektion=1&manpath=FreeBSD+13.2-RELEASE+and+Ports&arch=default&format=html

EDIT: I just read the man page and daemonize may not work any better but I’m still thinking it’s worth a quick shot.

If the host operating system provides the daemon(3) library routine, daemonize will use it. Otherwise, daemonize uses its own version of daemon(3).

[victor]

I can’t even get the script working as root…
It still says failed to resolve…

The only way it works is if you invoke the command directly from the command line.

[John]

Make a wrapper script to restart the server every ten seconds (not sure how well something like that will work with this app but, just an idea). …?

NOTE: a cron job could take the place of this wrapper script too so take this with a grain of salt. However, I suggested the wrapper script because, the wrapper script could check the PID file to see if the server is still running instead of just blindly starting every ten seconds but I’m not very confidant in the developers daemon so there is a good chance the PID file doesn’t get closed…

/usr/local/etc/rc.d/slskd.sh:

#!/bin/sh
if [ -x /opt/slskd/slskd_wrapper ] ; then
    echo -n " slskd"
    /opt/slskd/slskd_wrapper &
fi

/opt/slskd/slskd_wrapper:

#!/bin/sh

: ${slskd_user:="soulseek"}
: ${slskd_config:="/home/${slskd_user}/.local/share/slskd"}

while true ; do
    /opt/slskd/slskd --app-dir=${slskd_config}
    sleep 10
done

I quite possibly make a mistake on the wrapper script / arguments so, please look them over.

[victor]

I’d like to see the answer to this though. Maybe you could ask on the FreeBSD forums?

[winnielinnie]

@victor

I can’t even get the script working as root…
It still says failed to resolve…

You mean as the root user, but via the rc.d script?

There’s got to be something in the internals that doesn’t place nice with FreeBSD’s RC.

---

@John

Make a wrapper script to restart the server every ten seconds

I might have missed the earlier context to this, but why restart slskd every 10 seconds?

[winnielinnie]

On a Linux-based system (in this case Arch Linux), a packager can create the “service” for slskd very simply:

Check out this service file from the AUR package.

slskd.service for Arch Linux systems (systemd service)

[Unit]
Description=Slskd Service
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=slskd
Group=slskd
SyslogIdentifier=slskd
WorkingDirectory=/var/lib/slskd/
ExecStart=/usr/lib/slskd/slskd
Restart=on-failure

[Install]
WantedBy=multi-user.target

It runs in the background as the user “slskd” by launching the executable /usr/lib/slskd/slskd

Can be controlled with systemctl commands, such as systemctl stop slskd

There’s really not much to it…

---

That’s what I was aiming for with a FreeBSD RC script. And while it “worked”, it had no internet access. (Unless you launch it without using RC.)

So this tells me that it’s not enough to just “port” something to FreeBSD or allow it to be “built” for FreeBSD, but other modifications likely need to be patched into the code to make it truly work 100% with FreeBSD. Reading the GitHub, this isn’t the only time that the developers don’t seem too concerned with making something work with the same parity on FreeBSD as it does with Linux (and ironically, macOS and Windows sometimes.)

I say this because, for all intents and purposes, a FreeBSD package maintainer could technically create a port/pkg for slskd, just like an AUR packager did so for Arch Linux. But how would the FreeBSD package maintainer include it as a service, which the AUR packager managed to do so successfully? Such a person would be in the same boat as us.

---

EDIT: I will say that using the (not as ideal) “cron” method is working as expected. The application runs as a non-root user (“soulseek”), and I have successfully searched for and downloaded some files from the Soulseek Network over a WireGuard VPN connection.

[John]

@winnielinnie

this isn’t the only time that the developers don’t seem too concerned with making something work with the same parity on FreeBSD as it does with Linux (and ironically, macOS and Windows sometimes.)

That service file is for making a daemon from C# code in Linux. It’s more about laziness or ignorance from the developer. – Daemons are written differently than normal programs. Not to get into the weeds but a program is essentially a signal handler–signals are generated from events and those signals are delivered to the program and it knows what to do about those; daemons have another level of signal handling and that server/app/program doesn’t have that code in it. That service file is essentially the linux version of “daemon” so the developer doesn’t have to (to know?) write all that signal handling, forking, etc. daemons need.

Writing a Linux daemon in C# | Red Hat Developer

[FrankWard]

I don’t run jails. I have a Debianb VM in TrueNAS that runs Portainer which in turn handles all of the apps I’d have jailed back in Core. Never had an issue. Perhaps a different approach is the salvation you seek.

[LarsR]

Hell will freeze over before @winnielinnie will leave core for scale xD

[winnielinnie]

@FrankWard

Perhaps a different approach is the salvation you seek.

I’m not going to commit to the overhead of virtualization / VMs just to run native software that can run directly from a jail. I want my CPU and RAM to be free to any and all processes (including ZFS’s ARC), without putting anything to the side for a VM.

EDIT: You’ll notice that slskd “works” in a Core/FreeBSD jail. The only caveat is that it cannot be launched as a daemon with a custom rc.d script. (It will run just fine… but not connect to the internet.) So for now, I created a crontab entry that automatically starts it when the jail starts. Thanks to @Jailer.

Core? Jails. SCALE? I’m looking at Incus or whatever iXsystems settles on for legit, fully-supported “Linux jails”. And I do mean fully-supported, where it has the same parity as jails under Core: full, untethered root filesystems with complete network stacks, as if each jail is its own mini server on the local network. (I plan to create/maintain a handful of “Arch Linux” jails if/when the time comes, since I will have access to the latest upstream releases of software, plus the massive and underrated “AUR”.)

Ever since the days of FreeNAS 0.7 up until now, I’ve never ran a VM on my NAS server. Never had to, and probably never will.

[winnielinnie]

@LarsR

Hell will freeze over before @winnielinnie will leave core for scale xD

The forecast shows hell freezing over some time in the year 2026…

[John]

Boring is best.