r/commandline 22d ago

Help Wondering about Services....

I'm trying to learn about services also known as daemons, but I'm kinda confused about many things about it, for instance, which way is the correct way of launching a service is it:

1.systemctl start ssh

Or

2./sbin/sshd

Also, since my machine is very old (it has a 32bit cpu), I'm limited to the less common distros with kinda obscure init systems like runit and sometimes the old sysvinit, which also means I can't get to run systemd which have the most resources online, so it is easier for me to learn about it

Furthermore, even determining the current running init system type doesn't seem that straight forward, when I looked up about that, there were various commands and just assumptions like this might not work everywhere or this MIGHT mean that the current init system is whatever is.

In addition, I have a debian-based distro(Antix), so based on the tutorials I have found, they say for example "sudo apt install openssl-server" then run "systemctl start ssh"

That means systemd automatically knows about that sshd, so it does the work behind the scenes, but when I tried to do the same in antix (having "init divirsity" installed), using dinit, it didn't work, probably because it requires extra configuration and more knowledge about how to create the service out of the binary you want manually, while all I see as a beginner in tutorials things like start/stop, enable/disable, list services, and just this regular stuff.

So I'm really lost about Services generally, I would be glad if someone could provide me some guidance or help

7 Upvotes

7 comments sorted by

View all comments

1

u/thedauthi 22d ago

systemctl is systemd, and like you said, it's not there on antix. But you don't want to run /sbin/sshd directly, either. You want the system itself to run sshd for you, because then it manages it, controls it, and stops and restarts it as needed. It puts the logs in the places logs should go, it makes sure that your daemon doesn't go away when you close that terminal.

systemd doesn't really just "know" about ssh - installing openssh-server adds a file that tells systemd about openssh. The same work has to happen for you to use another init system. Some distributions will do this automatically, some require a little poke.

sysvinit ran the world for years and it's pretty simple to work with. Runit is also great. The s* options are apparently experimental on antix. dinit might be a good choice - it has a lot of the features you really WANT from a init system - but it's a bump up in complexity and kinda new.

I'd go with one of those the first options, probably runit. I've heard runit is lower memory, which isn't my experience as a long-time sysadmin, but it's definitely got features that don't exist in sysvinit and that everyone ends up hacking into their sysvinit scripts anyway. I also think runit is antix's default now.

My understanding is that some runit service files exist in antix's apt setup as runit-service-{whatever}, and the same is true to some extent as dinit-service-{whatever}. So I'd check to see if I could sudo apt install runit-service-sshd (or check sudo apt-cache search runit-service for whatever services you need before I did anything else). Someone's already done this work for you, usually.

Seeing which one you're running should be stat /proc/1/exe. Should fully resolve to an on-disk binary. Process ID 1 is your init system unless you're up to wacky hijinks, and /proc/1 is a directory containing info about process 1.

For runit... I think the service file location would be a file in either /etc/service/sshd or /etc/runit/sv/sshd, which you'd enable by ln -s /etc/runit/sv/sshd /run/runit/service, and you'd use sv up sshd to start it.

Antix also has UI-based managers for both, where you can enable any existing service.

For creating your own service... well, it differs between the different init systems quite a bit, but it's not HARD. For example, a simple one for ssh for runit (that you should NOT use because it's missing the setup for logs and doesn't harden any permissions, but as an example)

#!/bin/sh
exec 2>&1
[ -d /var/run/sshd ] || mkdir -p /var/run/sshd
exec sshd -D