So, you ask us to replace the SysV init system and the well tested init scripts of Slackware for... some fancy logs on daemon supervision?

But we have a daemon supervisor included in Slackware 15.0 and it's NOT an init system - it's just a program which executes and watch another program and it's called daemon. You can find it's homepage there:

https://github.com/raforg/daemon

Feel free to contact the daemon's developer and to propose features or patches. Looks like he's a very cool guy. And maybe together with him you can find a way to add your fancy logging to this daemon.

So, please do not tell me we should change the init system and to tailor OMG! WTF? number of unit files, just for doing a proper daemon supervising. Because that's not true, as was demonstrated practically, it's enough a standalone program for this. And we already have it on Slackware.

However, no offense intended, BUT apparently the Slackers aren't that interested about daemon supervision, because looks like they do not use so much the Slackware included daemon supervisor, outside of supervising the PipeWire daemons on user side.

Honestly, personally I use to remember them from time of time that we have a daemon supervisor within Slackware, BUT nobody looks too enthusiast regarding the daemon supervision on the init system scripts.

Regarding how fast is the parallel execution of services by an init system, several people explained already that the speed is not that impressive on a full fledged init system. I for one I will tell you that I do not think that the current openSUSE Tumbleweed boots noticeable faster than Slackware current. Maybe it's a bit faster. BUT, I do not think that that "a bit faster" is worth to change a well tested SysV init system with something like UNITD, which is experimental at best.

I have nothing against you project, BUT I think that you have chosen a wrong target audience.

Because from what I seen, the Slackers aren't that eager to change their SysV init system, they aren't that interested in the daemon supervision and IF you look for Slackware adoption of your UNITD, well... I'm afraid that our lifespan is too short for this to happen. Because Slackware is very, very slow to adopt new major technologies, like is an init system.

Honestly, I believe that Slackware will change it's init system ONLY IF it will be forced/required by the included software to do this. And this may happen to be systemd, because the software depends more and more on its features.

1 members found this post helpful.

When I written this thread was only for informat you that a new init system is out there.
Many users on Slackware uses Runit, included me. Now their have another choice.
I never think to want replace sysvinit.
You are saying that i want to replace sysvinit...I never said and i never thought.
You have built a "tower" uselessly.
Run another daemon to supervision another daemon?
Unitd have not need of that.
Unitd makes that and It makes well. It meets my requirements.
Sysvinit should need it.
I am aboslutely calm and happy.

3 members found this post helpful.

I've asked this before, but could you please provide a practical example of how this would work?

How would we use daemon to supervise (for example) ntpd?

I don't know about ntpd specifically, but daemon allows you to "daemonize" any program. I personally use it for running syncthing as my user (automatically brings it up on login, and quits on logout). It's called like this:
Then syncthing is running and can be interacted with through various commands; `daemon --list` will show "syncthing" as a daemonized process. The "--bind" argument means it stops when my user's logind session ends, and "--respawn" will bring it back up if it crashes (you can use --acceptable to set a limit on respawns). There are a bunch of other options but I've not looked into them too much.

I have some questions:
1 ) That means for each process which I want to supervise, will I call "n" times "/usr/bin/daemon --respawn --bind etc etc?"
2) If someone or something kills your process, daemon informs you of this event ?
3) Does it keep track the old process data?

Well, a translation of /etc/rc.d/rc.ntpd to the usage of daemon supervisor will start with instructing the supervised program to not daemonize itself. It should run in foreground, which for ntpd is the parameter '-n'

Also, the daemon supervisor knows how to switch to a particular user itself while running, then we will instruct the daemon (not the ntpd) to run as user ntp and group ntp .

Then, a literal translation of the init script would be like:
You will note the variable $DAEMONARGS which contains a series of common parameters passed to daemon.

You may avoid its usage by using a configuration file for the daemon, put in the /etc/daemon.conf.d/ntpd.conf and with the content:
Where the first word from this line represents obviously the --name passed to daemon, while everything else are parameters used for this --name .

In this case, the init script will become:

Yep. In fact, it's supposed this to happen in different init scripts.

Believe or not, the Slackware uses SysV init and init scripts written in the noble Bash language.

I have no expertise to respond to those questions, neither to evaluate the features usefulness, so how about to ask the daemon's developer directly?

Like I said already, he looks being a very friendly guy, so I'm almost certain that he will explain you in detail.

Anyway, the daemon supervision and the program running as PID EINZ are totally different things, as demonstrated by The Practice.

And anyway, if you believe that those are some really useful features, I think that they should be added eventually to Slackware's daemon supervisor, not the people to change their init system for reasons.

What means "many" to you? Anything more than two or three, but still a number small enough to be counted on a hand?

There is no need to ask to the daemon developer because I don't see some command which retrieves these informations.
Probably, if him doesn't store these informations, I think that him could makes it without problems.
The point is not this. Do we realize how many daemon instances have to we create to do that??? You are crazy!
I never judge the job the other programmers in particular the daemon developer job which will have done a nice work.
You say that my logs are fancy, I'd say that "fancy" is the attempt to add this feature to an now obsolete init system. It had its life. The world goes on!
To the slowness we also add useless resources usage.
I can bet that after seeing Unitd supervision many programmers will add their project a similar support.
I didn't write that before because i don't know sysvinit and how it works but now, seems clear the advantages which Unitd leads on the table.
Unitd also offers an interface for someone who wants a GUI.
Last but not least, the software design of Unitd should permit whatever changes.

Personal Opinion
I worked for many years in IT world and I always saw that the companies refuse to use systemd free distro
on their servers because the processes administration tools which their offer are not enough.
The systemd free distro was always installed on the simple desktop of a generic person which hasn't particular meets but never on the server.
Unitd can invert this trend offering a processes supervision, informations that nobody offer with fastness and lightness.

1 members found this post helpful.

Technically and practically, ZERO.

As you noticed, the Slackers are so interested about daemon supervision that 4 (four) months later after the release of Slackware 15.0 they still asks about basic examples of the daemon supervisor usage in the init scripts.

I heard those slogans 15 years ago or so in the Ubuntu forums.

IF someone dared to ask a question about SysV init (the one with a bunch of symlinks) there was a bunch of Masters of Nothing who loved to derail the thread on how obsolete is SysV init.

You know what? When Ubuntu adopted systemd, honestly I loved to see them running away yelling that the world is doomed and with a big carrot stuck on their back. I've laugh with tears!

Blah, blah, blah. Again, those are slogans known by mine since 15 years at least. You can do better, you know?

Nope. It's only about admins training...

When you learn Fedora's init system, you know also how to handle Ubuntu, SUSE or even Arch Linux. Because they use the same init system. All of them uses systemd.

What makes you to believe that Slackware is a "systemd free" distribution?

In fact, there's no official statement that Slackware is "antisystemd" distro and it already contains elogind and eudev, which represents 2/3 of original systemd solution.

In fact, with your so original systemd init system, err... unitd, the Slackware will complete the original solution of systemd. With units on init system!

Blah, blah, blah. Keep dreaming about our PID EINZ!

To be fair, I'm not convinced that it's required. The Slackware servers I administer (which are being used for commercial purposes) have never had a service fail.

At this point the record is measured in decades.

2 members found this post helpful.

Until I don't show you the supervision, you spoke about it,
now you say that the slackers are not interested to a daemon supervision... hahahah
You are great and very fun!!
Now the advantages that Unitd brings on the table are clear and cristallin like the water.
You can judge, attack or whatever you want but the facts are these.
Happy week-end and stay serene!

For you, indeed. If for others too, they will try it.

Just a few thoughts, OP posted this was an idea and interested persons thing and got
blasted on here as trying to reform Slackware is a harsh wow. Don't post new ideas
on here is what I gather from this . I was jumped on the other thread for merely asking
when to update. Not a very friendly thing. Been using Slackware since V3.2 kernel 2.0.29

as OP posted "Exactly, Unitd was born for who wants use it.
Linux is freedom."

They had no implications on reforming Slackware and this post has a lot of "we" statements that imply
they are part of dev. WOW, I guess free to post new ideas is a no-no !!

4 members found this post helpful.

I think that this thread was quite civil compared with what Mr. Pottering got, after all...

I understand that when you staring at other peoples Pid One, you should also have a hippopotamus skin.

I would believed you if OP would have posted this news thread in the Fedora Forums. But he did not did it, and even he did it, they would have laugh in his face.

Then why he posted here, in the forum of a Linux distribution using SysV init? Because I suspect that in his mind is nothing about "freedom", but about potential "market" as he thinks that SysV is obsolete.

Announcing his invention in the Slackware Forums and not in the Fedora's of Arch's Forums, respectfully I ask you to believe something else.

However, the Slackware 15.0 was released with some of its features like Wayland suport for KDE Plasma5 or a functional PipeWire, because there was some regular users who teamed up and solved some particular issue of software which wants systemd.

Out of brilliant work of Mr. Hameleers there was LuckyCyborg and GMGF who struggled with taming elogind to bling up the Plasma5 on Wayland. There was LuckyCyborg, 0XBF. me, marav and many others who struggled with taming the PipeWire daemons, widely used on Wayland and by those who want a better alternative to PulseAudio.

So, yes. There is a "we" of regular users who struggled and sweated to make work software which otherwise needs systemd. All this effort was done in the premise that Slackware uses its custom SysV init system and it's landmark.

Again, I would have been agreed with you if OP posted a thread in the Fedora Forums, but he posted here, in the forums of a Linux distribution who still uses the "obsolete" SysV init.

Looks like it's all about "market" and don't let me imagine Slackware adopting unitd and several years later "we" , as in Slackware community, running donation mills because his dog got cancer or an airplane landed on his cat.

Why "we" should take care about his dog's health issues, considering that SysV init exists since immemorial times and anyway there's systemd if we can't live without init services handled by "units" ?

Then let "us" to explain him that we have no strong feeling against systemd, runit or unitd, but "we" just want to use SysV init, for what we sweated for.

1 members found this post helpful.