Enough is enough, despite several warnings it seems now to go about the ini-style format instead of bartgymnasts efforts. Warning time is over, action follows.
For any participant in this thread, if you see offtopic posts, do not reply to them, but report them, so that proper moderator action can follow without further interfering with the thread.

2 members found this post helpful.

In any case, Samba uses it because it is similar to the Windows initialization for a service it is emulating.

The OLDEST "ini" format file I know of was for Kerberos. The initialization ALSO uses that format - along with additional syntax.

It was used there because it was simple to parse.

Bart, I was also thinking about this in regards to the systemd service files.

Slackware has an rc startup manager to which it lists a few daemons you can enable or disable using this ncurses tool (forgot the exact application name so AlienBOB, Patrick, and Robby please don't murder me... LOL) but it's ran on the Slackware install disk during the final setup of daemons.

Will this tool be switched out, removed, or rewritten to work with your port better or be redrafted to serve as an enable/disable switchboard for possibly a legacy rc script handler perhaps. I know it works with the existing default rc scripts to make them executable, I think.

I would suggest it is still too early for that.

first get systemd working, and at least as reliable as what is present now.

THEN make installation alternatives. There shouldn't be that much really to change, only the low level installation of the rc scripts, or use of systemctl...

JP you got me just thinking right now... we could probably still use Slackware's INIT system, but just redraft all the service files to load Slackware's rc scripts in batchworks rather than the defaults.

It's thinking ahead, but could it be done to where technically nothing has to actually be changed out?

Maybe I'm overthinking ways to keep it drop in and drop out ready.

The big problem is the core systemd processes: mounting filesystems, procfs, udev, log files, dbus. If these can be confirmed as "ready" before running any other scripts, I don't see why not.
I'm not sure. That was why I thought of the FUSE based /run to be able to generate the "i'm ready" signals back to systemd instead of having to modify every external service. The only script changes might be the specification of the pid file, and for most things, not even that.

The other reason is that pseudo filesystems are ALREADY being used to provide communication between independent processes (udev via devfs and anything using devices is one major place, another is using tmpfs for shared memory tracking).

One other advantage I thought of this approach has is that it makes it trivial to double check on active services... a simple ls command would show that.

One idea in my head was something along these lines for a simple management script:

Had to borrow Bart's example a page ago. Keep in mind this is only for an example only and doesn't reflect a true working condition:

And in rc.oss (borrowed from the SBo) you would have:

This way, OSS still can use the native rc.oss from traditional Slackware scripts while being managed only by systemd.

Not sure if that's 100% viable, but it's just a thought.

More or less it would technically be assigning systemd to be merely a daemon control management service working with the existing init services and files.

Of course, I could be wrong, you know.

Depending on which service daemons could be loaded off a single string of executions you could technically still have batches of daemons loaded parallel and the sequential daemons from each batch loaded linearly.

Not to say this would work, but it's one idea for the table.

As long as the sound service doesn't have any processes that depend on it, that would work.

BUT. note that it is started JUST before the multi-user start. So if it isn't ready by the time something else (say, GDM sent an announce message...) then it could just as easily not get the message...

The next problem is that systemd cannot manage the sound server - by doing things like restart it if it dies... or direct it to exit during shutdown, or determine when dependent services (like an audio screen reader) needs it available for use.

yes, you have a stop request... but you don't know WHEN it has terminated, so it is just as possible that systemd halted the system before it is finished.

Now, for the OSS sound server itself, that would be rather unlikely. But still possible.

That was why I was suggesting the fuse interface to systemd - it would allow a communication between the service and systemd (the pid to be monitored) and without requiring changes to either the script or the service other than configuration specification for the pid file name.

BTW, I just realized it can be started ANY time before multi-user start....

And there isn't any specification for its dependencies... (guess what - it depends on udev having the device ready...)

Right now, I don't know if that is an automatically implied dependency by systemd or not.

Hmmmm... Well... we'll figure it out sooner or later... Maybe.

These service scripts just seem so redundant and problematic. It's like the only real way to have any control is to pass everything off to systemd, but if we do that then we'd have to fully and completely remove the Slackware rc-init system, which would mean backwards compatibility or legacy support gets pushed out leaving everything to rc.local. Even SBo packages would need entirely new scripts if not the entire system.

All my knowledge is geared towards rc styled init systems and sysv scripts unfortunately with minimal knowledge geared towards ini/service stylized script files.

Unless we can promote some compatibility between the rc scripts and systemd service files, we'd basically have to draft up complete systemd script sets for all Slackware service daemons as well as those in SlackBuilds as well. That's kind of needless.

In other systems that use systemd or have it optional to another init, how do they package or handle the start scripts for daemon packages against multiple init services?

As far as I know, they don't. It is a complete replacement, with no real compatibility. The only services that don't really need modifications are those that have no other services depending on them.

So far Fedora has been modifying the service daemons making them incompatible with anything else.

The systemd specification files are all that it needs anyway - as long as the service is also modified to tell systemd when things are ready. Those are the "tentacles everywhere" problem. It already makes dbus, and udev incompatible with alternate inits now.

The historical plan was to have systemd as an alternate for Fedora 14. It didn't work. So it got pushed back to Fedora 15... and made the default init system. Upstart WAS available... but the people that tried upstart reported so many errors they couldn't get it to work.

@ReaperX7,

there are different types of service.
Forking means start script.
It will not monitor the program.
the way to use forking is to actually be able to start a script with kind of legacy fallback.

It is great for transition in my opinion when we would have systemd in /testing

for the installer part, I have actually been thinking about adding something to the Slackbuild that checks witch scripts in /etc/rc.d/ are executable and create a standard ..service file from it.
However, some script will be useless as the are natively started by systemd, so exceptions needs to be placed in that script aswell.

That might be the only way as you said Bart.

I might take some time next week and get back to my research of Runit. I might attempt a build of it and start a port of it for Slackware since you've gotten this far. All this alternative init work relit my interest again in trying to port it.

That's the business strategy of RH to keep their market position: embrace, extend, extinguish.

I don't see why adding unit files for services implies that the rc-scripts would have to be removed. They can coexist, just use one or the other.

But that destroys any possibility of having another service depend on it.
Doesn't work if one of those scripts depends on another to be ready to run. Even running all of the rc.d scripts in one unit doesn't work if any of them depend on a service that is started outside of that. That was why I suggested having rc-M.service be run AFTER everything that systemd does, and then have rc-local.service run AFTER that. You can't use the "After=network.target", as any script that has such a dependency could be run BEFORE that service is ready. It is one of the reasons apache/mysql fail.. sometimes.
And that is what destroys the reliability of the rc.d scripts. The required ordering is lost.