The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or click here to continue anyway

The systemd fallacy | monolight

Even to server start up time can make a difference to how many +1 servers have to be running. Due to the speed a +1 server can be started.

systemd gets quite a few things right.

“collecting information on daemon crashes” this is not just logs but can be like core dumps. Information that will not be in the normal error logs. So what systemd is doing here is an enhancement. Basically there is more information that could be collected in case of daemon crashes that sys v init and upstart lets slip threw fingers. Kernel generated stuff. Items you don’t need deamon coders to play ball with. Yep it crashed what did the kernel tell me about it record done.

“delayed/on-demand service startup.” Of course you miss that systemd style of this is expanded from inetd. /var/run/mysqld/mysqld.sock Can be hooked under systemd that inetd does not handle. Next is inetd does not handle services that should be left running after they have been started on demand. So in this regard systemd is more enhanced than inetd is. So at worst it should remain as the replacement to inetd.

cgroup features have been disregarded by init systems. So its nice to see one that has bothered to integrate it.

Of course you have presumed coder is insane. “dependency based service management” Please read before and after features of systemd. Yes their is a dependency based system in systemd you can choose to use

Systemd throws away the ideas of the numbered dependency based system. If I made everything I was running set as after=”thediskmounts” Then everything would only start after the disks were all mounted. Now if you want speed you can disregard this. Goes over to a direct assigned dependency system. Ie I depend on X don’t start me before it. Big issue with system v init was if you got your magic numbers wrong. No magic numbers nice improvement.

“systemd creates autofs mount points” optional due to the the dependency system you missed in systemd design.

“listening to hardware changes” Something has to. Also this segment of systemd can be disabled if you don’t want systemd responding to it. So secuirty concerns can be addressed.

“communication via D-Bus” Of course you miss that systemd is its own dbus server. When you are running a dbus server for desktop users you might has well talk by that IPC as use another one.

“restarting processes” I left this one to last because I do have a issue here. systemd has a method that attempts to hide the fact that a service did crash and has been restarted. By caching the communication. This is something I do see as a possible source of problems. Of course their is an option to disable this feature.

Sorry to say out of your 8 points not one stacks up really all are addressable. Yes systemd is different. Done different. Lot of systemd should be taken onboard.

system V needs to die just because of the idea of S1 to what ever and K1 to what ever instead of appache had to its config file added after mysql so when apache comes up everything php website needs inside is their. This is a far saner way of handling dependencies.

Now a more detailed run through of the systemd dependency system.

Nice is that the after=mysql instruction if you just directly say start apache mysql will not be forced started as well. But if both are starting at the same time. apache will be started after mysql. There are options in systemd to cause it to be force started as well.

Now apache with systemd is configured. Requires=mysql after=mysql You try to manually start apache if mysql is not running. mysql will be started first. If mysql cannot be started apache is not attempted to be started. Once mysql is up then apache starts.

Now of course Requires can be too strict. Since this setup if mysql dies apache will be taken down as well.

RequiresOverridable=mysql instead of Requires=mysql will attempt to start mysql if it fails still start apache and will not shut apache down if mysql fails.

Requisite=, RequisiteOverridable= Now this is even more evilish. If Requisite=mysql or RequisiteOverridable=mysql is used instead of Requires. apache will not even attempt to start at all if mysql is not already running. The start will be aborted.

Nice simple tight dependency system with many dependency defines that suit what a system admin should need to happen. Ok what happened with good old system V. with a S lower than apache on mysql. mysql crashed on startup. system v keeps on going along starts apache now website does not work right.

Hang on what is not a dependency based system. In fact system V init is not a dependancy based. Systemd has a well designed dependency based system. If you choose not to use it. Systemd will try to sort out your errors for you. Yes systemd is many time simpler to get the init system to make the correct selection starting stuff up.

Shutting the system down on the other hand that could use some work.

So will you not join me calling for system V init death as fast as we can.

Also your ftpd example is counted by ConditionPathExists=/home/ftp So that while /home/ftp does not appear as a existing path. ftpd will not be started.

Systemd allows giving very exact instructions. Lets say 1 drive fails to start up. Everything without a dependency on that drive will get started.

Yes systemd requires to work perfectly more exact information about what stuff requires. Advantage if everything is provided their is no reason not to run.

Continue reading on