Maybe... but you are forgetting that systemd replaces init. It mounts the filesystems. It starts dbus. It starts the logging.

Now, not using ANY systemd configurations except rc.local would work (it would still be mounting filesystems as that is built in). but remember, there are no levels anymore.

By default, rc.local is SUPPOSED to be started AFTER the network is running... but that could be changed. The dependency list would have to be modified (personally, I think it would be more reliable) by having a specific target that would guarantee that whatever systemd does, is completed BEFORE rc.local is started. Then put a simple shell script version if the sysVinit startup in there (my Slackware VM isn't running at the moment, but I think it already has one). That way things could be slowly migrated. There will still be a lot of difficulty in debugging the migrated services though - each service added causes a change to most of other services due to scheduling alterations and that can introduce/identify additional overlooked dependencies.

I have had to disable NetworkManager (it just doesn't handle things very well for me) and enabled the network.service (which runs the normal network startup scripts for Fedora). rc.local still depends on the network, but at least my network is stable first.

As an alternate thought - it doesn't have to be called rc.local. Call the service target rc-M.service. Then make rc.local depend on rc-M (After=rc-M). That way you still get to isolate rc.local from rc.M done by systemd. Now the rc-M.service would need the After=remount-rootfs (I believe that is the minimum that systemd has to have), but you would have to think about it. things like procfs, devfs, udev, journald, still have to be processed VERY early in the boot process.

There is also the things about the shutdown order that has to be thought out too.

2 members found this post helpful.

Exactly, and good idea jpollard adding an rc-M.service file idea.

It's more or less a rehashing of the same concept that was used to add sysvinit support to bsdinit.

I only wish we could restore the runlevels to systemd. It's beneficial to have diagnostic modes available and low level administrator modes for system maintenance.

ReaperX7, those modes are still there
they are just not named by their number anymore
its rescue (runlevel 1), multi-user (runlevel 3), grahpical (runlevel 4), etc,

for having a rc-M.service file I don not see the use of it at all.
With the latest systemd it should work normally.
If a program that depends on mysql, fails to start, it is an issue of mysql
If mysql has been compiled with systemd support, than mysql reports back to systemd that it is ready (thats why systemd is a service manager)

The point of rc-M is better safe than sorry. Even if it may work right there should be a fail-safe fallback that can be enabled at will to ensure things do work not just right, but correctly.

It's the same concept of the rc.sysvinit executed at the end of Slackware's rc startup scripts to load sysvinit scripts in compatibility mode.

Having rc-M.service would still allow for non-systemd Slackware startup scripts to load in a legacy mode, or even serve as a backup in case the normal service files become problematic, or as even as a curious alternative.

but you can write service scripts accordingly.

for example 2 different mysql.service scripts:

or if you want to start it tradionally from /etc/rc.d

All that is very nice...

Except that if mysqld is not modified (like every service really needs to be modified), systemd ASSUMES it is ready as soon as the process starts.

It is what makes it incompatible with SysVinit.

One of the long standing issues all parallel daemon service loaders including OpenRC, RunIt, s6, and systemd have had to contend with is if one part of the system starts before another part is ready, it breaks things to the point that these init systems batch load services in hybridized linear-parallel modes or make parallel loading entirely optional.

This does require lots of modifications to packages and startup scripts alike.

I think it is perfectly reasonable to have a discussion like this one on a thread about porting systemd
I learnt a lot with it

2 members found this post helpful.

I disagree, and I was quite annoyed with all the attempts to derail the purpose of the thread. We already have "systemd bashing" threads on this forum, in which I enjoy participating (I am not a supporter of systemd) but Bart's thread is about getting systemd to work on Slackware, and that is a commendable goal in itself.
Technical discussion on how to implement systemd on Slackware is OK, but politically inspired posts do not belong here.

My two cents.

Eric

7 members found this post helpful.

Yes - and that "devolves" into what the original inittab was for, and did very well.
yes. And trying to avoid that is what systemd doesn't do.

I did have a thought about it though.

If a fuse based mount for /run were done, and the parallel init would use it - THEN, the normal scripts COULD be done, and monitoring the service process could ALSO be done. The filesystem would only hold things like the "xxx.pid" files, which only hold the pid of the service. This would identify to systemd (or equivalent) what process should be monitored. Second, it fixes the notification requirement as the pid file cannot be recorded until AFTER the process forks the daemonized service (in which case it should be ready for requests...). Putting that recording there would appear to solve the "ready" requirements, as well as solve the startup requirements (the PID of the setup process would be known as systemd is the one that forked it). If the service didn't require any "ready" (or monitoring was undesired) then none would be provided.

For complex services that use multiple processes (the one that comes to mind is tying NIS/LDAP + other naming services together in one startup, but I'm sure there are others) a naming convention could be used: startup_script_id.daemon_id.pid, thus the monitoring process would have the connection between the startup script name, the specific daemon service, and the pid for that service. If it needed to be restarted, then the script (which is easier to modify than the service) could be invoked with restart parameters pointing to the specific one to do (or it could just look in the /run directory for the pid file that should have been removed when the monitored process exited).

It would seem to eliminate the need for modifications to the service.

2 members found this post helpful.

Those are not "scripts" - they are Microsoft® .ini format configuration files.

My goodness! Who would have ever believed that Microsoft® ".ini" format would be chosen for configuring GNU/Linux systems?

Guess what format use, from ages, the ol'good configuration files like /etc/httpd/php.ini or /etc/samba/smb.conf?

The fact that you are incredible amazed by "that so shocking discovery" tell very much about your (Slackware) Linux knowledge level...

To be perfectly fair, that type of configuration file (and yes, I would agree it's not a script) has been used in other UNIX/Linux applications, the first example that springs to mind being Samba.

Yes. Now you know that I don't run a server or samba.

But it doesn't change the substance of my comment - and why do php.ini and samba.conf use the Microsoft® ini format?

An odd, but revealing, choice.

.ini is actually fairly universal like .conf is. It's all a matter if what file format you wish to choose from. Yes .ini is more commonly used on Microsoft systems like MSDOS and Windows, and Microsoft-like systems like Wine and ReactOS, but .conf is equally used by projects on those systems as well.

There are various initialization and configuration formats in existence in usage with UNIX and UNIX-like systems, so you're bound to come across most of them at any given time.

However, it is intriguing that .ini stylization was chosen for systemd. I wonder why?