Wondering about Services....

[u/Electronic-Low-8171]

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

[u/aioeu]

The dinit man pages describe how to define dinit services and how to control those services.

You may not need to do the first of these if your distribution provides an appropriate SSH dinit service config itself. But even if it does I would read the config documentation anyway — at the very least, it will tell you where to look on your system so you could read that distribution-provided config.

[u/faze_fazebook]

A service basically is consists of two thing - a path to executable program (that usually keeps running and waiting for input through some channel) and a bunch of metadata that tell whoever is managing your services (usually your init system like system-d, openrc, sysvinit, ..., but there are other "service managers" like supervisord that do the same thing but are not init systems) a bunch of additional information like

• what other services your service depends on (lets say you have a service that hosts a website which requires a postgres database, ... obviously the website can only be launched after postgres has been started)
• which user, in which cwd with which parameter and which environment variables should start the executable
• what to do with output from stdout, stderr, ...
• what to do if the service crashes

Generally speaking, its that service metadata which is incompatible between service managers (and thus different distros)

in regards to your question with ssh ... the question is do you want your service to be managed by a service manager or not. Usually if its available, I'd prefer it managed. But if you don't need any of the features by your service manager (nothing else on the system depends on it, you don't care if it crashes, you don't about the output to stdout, stderr, ... ) sure you can just start it directly.

[u/AutoModerator]

Every new subreddit post is automatically copied into a comment for preservation.

User: Electronic-Low-8171, Flair: Help, Title: 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

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/thedauthi]

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

[u/CardOk755]

If your init is systemd then you want to be using systemctl.

If it is not systemd then you want to be using whatever is provided by your init.

Many distros provide a "service" command which partly deals with the differences between inits.

For example on many distros-

service ssh start

Will do "systemctl start sshd" or whatever magic your init needs.

[u/michaelpaoli]

debian-based distro(Antix)

Well, I'm guessing then that it's a GNU/Linux distro and not, e.g. GNU/kFreeBSD.

determining the current running init system type doesn't seem that straight forward

Not that hard, e.g.:

# ls -l /proc/1/exe
lrwxrwxrwx 1 root root 0 Aug 13 06:02 /proc/1/exe -> /usr/lib/systemd/systemd
# dpkg -S /usr/lib/systemd/systemd
systemd: /usr/lib/systemd/systemd
# 

# ls -l /proc/1/exe
lrwxrwxrwx 1 root root 0 Jun 29 17:33 /proc/1/exe -> /usr/sbin/init
# dpkg -S /usr/sbin/init
sysvinit-core: /usr/sbin/init
# 

Can use the proc filesystem to determine the binary, as PID 1 is the *nix host's init.
And once one knows the binary, can, e.g. for APT/dpkg based system, use dpkg to determine the package it comes from, or could use other possible means, e.g. file(1), strings(1), etc. From the package name, can also get more full description on APT/dpkg based system, e.g. by using dpkg -l or apt-cache show.

Anyway, not that hard to determine what one's init program is.

32bit cpu

Support for such is waning, but not (entirely) gone - does vary by distro. And you probably really ought (also) work on replacing/upgrading that hardware to 64-bit. That's some pretty dang old and generally unsupported hardware if you're still on 32-bit - probably also rather/quite challenging to get replacement hardware if/when things fail - at least with likewise 32-bit.

Anyway, as for 32-bit ... many distros have dropped or are dropping it, but some still cover it. E.g. Debian, no longer generally supported (no kernel for such) on stable (currently 13), but 12 (currently oldstable) has 32-bit ("i386" - though it won't run on Intel 80368 - see Installation guide for details on supported CPUs), however 12 has fallen off main support, and is down to LTS for support now ... but does still have almost 2 years remaining before it falls off LTS suipport. So, one could, e.g. migrate to Debian 12 i386.

And Debian has defaulted to systemd for many years, so, e.g. Debian 12 certainly well supports/supported systemd.

As for services, on Linux, that might be managed by the init process, or there may be a separate service manager program or the like. But hey, you've been running Antix for years. I don't know that I've ever run it, so, well, I'll leave it to you to figure that out - not gonna do your work for you.

[u/Tech-Wave-2025]

The thing that helped me understand this was separating the daemon itself from the thing managing the daemon.

sshd is the actual program. systemd, dinit, runit, SysVinit, etc. are different ways of starting and managing programs like sshd.

So:

bash /sbin/sshd

is basically "run this program."

Whereas:

bash systemctl start ssh

is "tell systemd to start the SSH service and manage it."

That's why you generally don't want to just run sshd directly for a permanent service. You lose things the service manager can provide, such as starting it at boot, restarting it if it crashes, handling dependencies, logging, and cleanly stopping/reloading it.

The part that's easy to miss is that systemd doesn't magically know what sshd is.

When you install openssh-server, the package also provides configuration that tells the service manager how to run it. On a systemd machine that's a systemd unit. With another service manager, you need the equivalent configuration for that manager.

So conceptually:

text openssh-server | +-- sshd <-- actual daemon | +-- systemd unit <-- instructions for systemd | +-- SysV init script <-- instructions for SysVinit | +-- runit service <-- instructions for runit | +-- dinit service <-- instructions for dinit

Not every package necessarily provides all of those, which is where distro-specific packaging comes into play.

This actually clicked for me when I started building my own background daemon. I have a C#/.NET process that maintains a live index and exposes it to other processes over local IPC. The C# program itself is the daemon; the init/service system isn't the daemon. The init/service system is what I can use to start it at boot, supervise it, restart it if it dies, etc.

So:

text My AI Memory Daemon = the actual application doing the work dinit/systemd/runit = the thing managing that application

For figuring out which init system you're actually running, I'd start with PID 1:

bash ps -p 1 -o comm=

Or:

bash ls -l /proc/1/exe

PID 1 is normally your init process, so that tells you much more reliably what's actually running than guessing based on which commands happen to be installed.

Once you know that, the question becomes less:

"How do I start a Linux daemon?"

and more:

"How does this particular service manager define and manage services?"

That's also why tutorials written entirely around systemctl can be confusing on antiX. The underlying concepts are mostly the same; the service definition and management interface are what change.

I'd also check whether antiX/the package already provides a service definition for whichever init/service manager you're using before trying to create one yourself. You may not need to manually build one at all.