i only asked about a functionality in this thread opened by me because I read important things except last two answers fully useless

I'm sorry, but I'm going to call you out on this. I've been observing a trend with you: you have a high propensity to post caustic and/or rude responses to people here. The biggest criticism that I can actually think of for tuxuser1 is that perhaps he/she/they should have started a new posting thread about the work that he/she/they are doing on their init. Nobody is obliged to use tuxuser1's new init. But yes, many slackers out there DO like to tinker, and I say let them knock their socks off as long as it doesn't threaten your system.

7 members found this post helpful.

I think... isn't that how everything started? Linus? Pat?

You clearly enjoy it (?), make use of it, so why not? Carry on, ask for suggestion if needed...

A GUI for superior overview of services would be nice... have a look at Windows...


Best of luck! I'll keep stalking you!

3 members found this post helpful.

There is nothing intrinsically wrong with sysv-init. It is indeed reliable and gives the user the flexibility that one could expect. Perhaps with a little imagination, one could also tweak it to make up for any additional features other more modern init systems have, but I confess that I do not afford enough time to try it out.

I see a lot of questions on why a user might want to replace the sysv-init with runit. As I had authored the "long README" on SBo, I think that I may shed some light on the matter.

I had just tried Void Linux and I was blown away. The speed with which it boots up is amazing and runit is well structured and does not require much arcane syntax. I would say that it follows the "UNIX philosophy". A user may want to try runit if they would like have fun learning Slackware's booting up scripts and try to speed up the process.

Also, I find that listing additional services to /etc/rc.d/rc.local may not be "elegant". Runit gives the user better visibility on the system's services.

My concern with runit is that it appears to be unsupported, but I am not following the Void community anymore, so I may be wrong.

5 members found this post helpful.

runit is hosted on smarden.org, and it hasn't had a very recent update, but it has had updates in the past 2-4 years iirc. If an init is done properly and no new features are added, a lack of further development doesn't necessarily indicate a problem. Perhaps in the eyes of the dev it's reached its perfection, and no new bugs have been discovered? Don't forget that runit itself is based directly off of djb's daemontools, so much of the heavy lifting had already been done and was well tested.

1 members found this post helpful.

I got a few "Why did you write that when $thing already exists!" responses when I posted my slackscan and slackup scripts. Some folks are just like that. Don't feel you have to justify your choices to anyone: if you've got an itch, scratch it, then shove it in a github (other hosting services are available) repo for anyone who might be interested.

So far, I think I had a whole two people show interest in my creations. Doesn't matter, I wrote it for me, because I wanted to scratch that itch.

6 members found this post helpful.

Yeah, I can't speak about sysv-init because I don't know it enough.
I run Runit because I alreay used it but, anyway, it also lacks some features for me.
There isn't a real one shot process management. Yes, you can do it but it requires a bit of hack which is not pretty elegant.
Additionally, it doesn't provide important data which can be very useful if you are a system administrator.
There isn't a real "restart" management.
Systemd provide that but, at the same time, I don't want it because it handles the "world".
My init system will provide all that, informing you all that happen about a service like a history. (Systemd doesn't give you that), moreover, it will not handle the "world" thus trying to following UNIX filosophy.

1 members found this post helpful.

I fully agree with you!
Anyway, I'm not justifying me....I only asked about an init system functionality which, yet now, I can't find an useful use.
I leave it in the future.

1 members found this post helpful.

I have a doubt about service enabling.
You imagine this scenario:

I have a process which requires the "multi-user" runlevel.
We set "multi-user" as default runlevel.
To enable this service, I create a symlink to "multi-user" runlevel.
Client side, when we show the data, just find the symlink show it as enabled.
So far so good.
Now, you would create a service which requires "reboot" or "poweroff" runlevel.
The init system also predicts these runlevels which can never be set as default.
I create a symlink to "reboot" or "poweroff" runlevel.
That means that they will be executed when reboot or poweroff the machine.
Client side, How should I show this service ? Enabled or not ?
Any ideas?

In my view, such a service in the "enabled" state will execute stuff when state changes to reboot/poweroff and is in the "disabled" state when it will not.
As an example: let's say your system has a "clear /tmp dir on shutdown" service installed... you may chose to enable it or not based on whether you want to clear /tmp on reboot/poweroff or not... even though the service will only execute stuff in a different run-level than the one the user is currently on, one should be to see if it is enabled (will do the thing) or diabled (will not do the thing).

Does that make sense?

It makes sense but unfortunately it can't resolve my problem.
The configuration file of my services predicts some runlevels including poweroff and reboot.
As said above, I could configure a service only for reboot and poweroff but, at the same time, the default runlevel is multi-user (just an example).
Since I will not found the symlink in multi-user (default), client side, how should I have to consider it ?
I hope explain well.

On runit, you are free to enable and disable services independently from runlevels.

By way of example, you can have a default runlevel that starts kdm, and another runelevel, say named terminal, that does not.

The underlying problem with sysv-init is that is doesn't (by default) know how to monitor a service to ensure that it is still running.

I've been running a dovecot server on a local 14.2 machine for years now. I have not been able to depend upon my system startup to ensure that dovecot is actually running when the system comes up. Sometimes it does; sometimes it doesn't.

i'm almost done writing a new init system called Unitd. when I'm done you can try it and see if it meets your requirements

If dovecot may run undemonised way, you may want to read my wiki for possible solutions

https://docs.slackware.com/howtos:slackware_admin:runit