SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I stumbled across this news of Alpine Linux sponsoring work for an alternative service manager to systemd, and to my surprise they plan to work with the creator of S6 init, which i saw some people tinker with here or on reddit.
Technical details about this evolved S6: https://skarnet.com/projects/service-manager.html
So to anyone who is tikering/using S6, whats your experience with it?
With these new changes could it provide a nice systemd alternative for slackware?
Not so much for running services as a user though (services things like syncthing come to mind), that's something I'd like to see.
What did you mean by "running services as a user" ?
On the latest Slackware-current is quite simple to run a program on background as user - started on user login, ensuring that a single instance is started no matter how many user sessions are started, then the program to be automatically quit on user logout.
This is exactly what we do with the PipeWire daemons triad, using the libSlack's daemon supervisor, included on Slackware not so long ago and creating three XDG autostart files.
And a XDG autostart file for the pipewire daemon looks like this
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Media System
Comment=Start the PipeWire Media System
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire /usr/bin/pipewire
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
You need a XDG autostart file also for pipewire-mediasession and pipewire-pulse
So, for babysitting your syncthing in the same way, probably is needed a XDG autostart file, like this:
Code:
Desktop Entry]
Name=Start Syncthing
GenericName=File synchronization
Comment=Starts the main syncthing process in the background.
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=syncthing --command="/usr/bin/syncthing serve --no-browser --logfile=default"
Icon=syncthing
Terminal=false
Type=Application
Keywords=synchronization;daemon;
Categories=Network;FileTransfer;P2P
This is on starting user services when the user goes on a desktop session, but there also are people who starts VPN services on a Linux console login (which automatically stops on user logout), by putting appropriate commands on ~/.profile
Last edited by LuckyCyborg; 04-28-2021 at 01:48 AM.
In my humble opinion, we do not need the systemd's little brother.
Probably way more useful would be a discussion regarding the systemd development news, because the applications will start sooner or later those new systemd features, which in the end will affect us, by not working on Slackware for whatever reason.
I believe that for us, right for staying away of systemd, is the best to have a really informed view about systemd and how the applications interact with it.
Last edited by LuckyCyborg; 04-28-2021 at 02:03 AM.
In my humble opinion, we do not need the systemd's little brother.
Probably way more useful would be a discussion regarding the systemd development news, because the applications will start sooner or later those new systemd features, which in the end will affect us, by not working on Slackware for whatever reason.
I believe that for us, right for staying away of systemd, is the best to have a really informed view about systemd and how the applications interact with it.
Is s6 really "systemd's little brother" ? With the cursory examination of it that I did, it seems to be more in the vein of runit, which IS what I use for an init system. As good as the default init is in Slackware, I find it lacking in flexibility and for on-the-fly changes. I am also a pretty strong proponent of daemon supervision, and I am annoyed by forking processes to the background instead of just having the init manage them.
So Slackware's system initialization rc scripts? Magnificent. But for using them or sysv for launching daemons (other than dhcpcd)? Not so much. My two cents.
Yes, by the very idea of parallel running of services/units it's a lot like systemd's PID EINZ which everybody hates and fundamentally different of what Slackware do. And I do not care if PID EINZ was inspired from runit, which was inspired from upstart, which was show in a dream vision by Santa Klaus.
However, no matter what, I for one I believe that IF EVER Slackware will have to change fundamentally its init system, the single worth change would be to the systemd adoption.
At least, this way we will get the compatibility with everybody else, excluding probably Alpine, Obarun and few others.
Quote:
Originally Posted by mishehu
With the cursory examination of it that I did, it seems to be more in the vein of runit, which IS what I use for an init system. As good as the default init is in Slackware, I find it lacking in flexibility and for on-the-fly changes. I am also a pretty strong proponent of daemon supervision, and I am annoyed by forking processes to the background instead of just having the init manage them.
So Slackware's system initialization rc scripts? Magnificent. But for using them or sysv for launching daemons (other than dhcpcd)? Not so much. My two cents.
The latest Slackware-current already includes an excellent daemon supervisor, about I already talked. And it was designed originally and literally for supervising services on init systems.
I told you that's also really small and a single binary program?
BUT, how the Slackware init scripts would be adapted in future to use it, or IF there EVEN will be changes of such type, this is another discussion.
However, as "a pretty strong proponent of daemon supervision" as you are, feel free to research ways of using the daemon supervision on Slackware init scripts (using the tools which are already included) and propose them to our BDFL.
I for one, I was interested solely on the user side of running certain services designed for systemd, like are the PipeWire daemons.
Last edited by LuckyCyborg; 04-28-2021 at 03:48 AM.
What did you mean by "running services as a user" ?
I mean services that come up at boot time, are running as my own user, and can be watched/checked through a daemon supervisor (hopefully firing the service back up again if it goes down). Even better if it had support for putting processes in containers (without involving root), that would be ideal.
Quote:
Originally Posted by LuckyCyborg
On the latest Slackware-current is quite simple to run a program on background as user - started on user login, ensuring that a single instance is started no matter how many user sessions are started, then the program to be automatically quit on user logout.
It's not exactly what I want, but sounds pretty handy to ensure only a single instance. I'll take a look, thanks.
Yes, by the very idea of parallel running of services/units it's a lot like systemd's PID EINZ which everybody hates and fundamentally different of what Slackware do. And I do not care if PID EINZ was inspired from runit, which was inspired from upstart, which was show in a dream vision by Santa Klaus.
However, no matter what, I for one I believe that IF EVER Slackware will have to change fundamentally its init system, the single worth change would be to the systemd adoption.
At least, this way we will get the compatibility with everybody else, excluding probably Alpine, Obarun and few others.
The latest Slackware-current already includes an excellent daemon supervisor, about I already talked. And it was designed originally and literally for supervising services on init systems.
I told you that's also really small and a single binary program?
BUT, how the Slackware init scripts would be adapted in future to use it, or IF there EVEN will be changes of such type, this is another discussion.
However, as "a pretty strong proponent of daemon supervision" as you are, feel free to research ways of using the daemon supervision on Slackware init scripts (using the tools which are already included) and propose them to our BDFL.
I for one, I was interested solely on the user side of running certain services designed for systemd, like are the PipeWire daemons.
runit itself does not derive from upstart. It derives from Daniel J. Bernstein's daemontools. And I'm not aware of s6 deriving from upstart either, but I haven't actually installed it on any machine nor looked at its code in depth.
If your argument is that runit starts processes in parallel, and thus that makes it the "little brother of systemd", that's quite a weak one. They share no code, and only loosely share *some* concepts. And runit doesn't have an equivalent of the worm & apple game which is stuff like 'systemd-fstab-generator'.
Unless you're actually creating entries into /etc/inittab, how are you doing actual daemon supervision without doing it in a terribly ugly and hackish manner? I'd still rather launch most daemons via inittab were I to not be using runit or anything else.
I don't find your arguments here to be very compelling. But the nice thing is that we're free to disagree, and I can freely run runit or s6 as my PID 1 system. :-)
I mean services that come up at boot time, are running as my own user, and can be watched/checked through a daemon supervisor (hopefully firing the service back up again if it goes down). Even better if it had support for putting processes in containers (without involving root), that would be ideal.
The daemon supervisor included in Slackware-have the ability to run as a different user (if itself is executed as root) on the init scripts, and to --respawn its client program if it goes down.
Like I said already, it is an daemon supervisor designed for usage mainly on init scripts, from what I known. And it offers a quite nice set of features for this.
Only not so long ago (at @ZhaoLin1457's feature request) it got also the ability to communicate with (e)logind, for watching for the user logout, when to quit itself and it's client program.
We wanted this particular feature for properly handling the PipeWire daemons, which does not known how to quit themselves on user logout, like PulseAudio.
BUT, the daemon was from its inception and it is literally even now an init system tool.
Quote:
Originally Posted by drgibbon
It's not exactly what I want, but sounds pretty handy to ensure only a single instance. I'll take a look, thanks.
Like I said, you can can run on init system side a particular service as user. All depends of your imagination.
Last edited by LuckyCyborg; 04-28-2021 at 06:51 AM.
I don't find your arguments here to be very compelling.
Neither me, your arguments that Slackware shall change its init system, because reasons...
In fact, starting a thread saying that whatever is "a nice systemd alternative for slackware" means that there are people who wants systemd, but because reasons they look for alternatives.
BUT, I believe that the Slackers are quite happy with the actual init system and that's WHY the Slackware does not switched to systemd too.
I for one, I do not need either systemd or any other "nice alternative" of it, because simply I am quite satisfied by the actual init system. And apparently like me are many.
I mean services that come up at boot time, are running as my own user, and can be watched/checked through a daemon supervisor (hopefully firing the service back up again if it goes down).
FWIW, if you use the combination of s6 + s6-rc + s6-linux-init as your init system, you can create a user supervision sub-tree that is run as your user and make it as one of the system services that should be started at boot time. After that, you can then add your own services to that supervision sub-tree. For example, in my system, here is a snippet of what the process tree looked-like (ignore the additional "runuser" process, that's just for applying resource limits, set by PAM, that are defined in /etc/security/limits.conf and /etc/security/limits.d/*, although I don't really use it for now):
(I don't start my supervision sub-tree at boot time, just when I log in. But, the process tree will probably looked similar like above.)
EDIT:
Actually, you probably don't need to have an s6-based init system to do that, you can probably use /etc/inittab to launch an s6-svscan instance that is run by your user, supervised by Slackware's "init" program.
Last edited by mumahendras3; 04-28-2021 at 04:55 AM.
Reason: Additional info
FWIW, if you use the combination of s6 + s6-rc + s6-linux-init as your init system, you can create a user supervision sub-tree that is run as your user and make it as one of the system services that should be started at boot time.
Neither me, your arguments that Slackware shall change its init system, because reasons...
I am making no such argument. I am perfectly fine with the default init being shipped, and then being able to replace it with whatever init of my liking is.
Quote:
Originally Posted by LuckyCyborg
In fact, starting a thread saying that whatever is "a nice systemd alternative for slackware" means that there are people who wants systemd, but because reasons they look for alternatives.
That can mean "has some concepts in common with systemd". Systemd itself does have some nice concepts. But it is the actual design and implementation where it fails, in my opinion. I work with systemd at work, and I've had to learn to deal with those shortcomings.
Quote:
Originally Posted by LuckyCyborg
BUT, I believe that the Slackers are quite happy with the actual init system and that's WHY the Slackware does not switched to systemd too.
Maybe, maybe not. Pat tends to be resistant to "change for change's sake". To some extent, so am I. That's why I'm not advocating that Pat replace the default init with runit, s6, systemd, or any other init.
Quote:
Originally Posted by LuckyCyborg
I for one, I do not need either systemd or any other "nice alternative" of it, because simply I am quite satisfied by the actual init system. And apparently like me are many.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
