That newfangled Journal thing

Posted Nov 25, 2011 10:00 UTC (Fri) by anselm (subscriber, #2796)
In reply to: That newfangled Journal thing by dlang
Parent article: That newfangled Journal thing

one key thing is that the developers of upstart are not nearly as condescending towards people who disagree with them (they don't get dismissed as "people opposed to all change" instantly)

Maybe this is because at least some of them do seem to give the impression of being »opposed to all change«? It is interesting (or even amusing) to watch the contortions some people are going through in this ongoing discussion just because, according to them, the syslog mechanism may apparently never be changed.

Lennart Poettering has gone to the trouble of posting a large number of blog articles to inform people about systemd in a very factual manner. This does not particularly strike me as something a person as condescending as you claim Lennart is would bother doing.

BSD init to SysV init are both variations of shell scripts. the difference is just in how the scripts are organized.

Well, SysV init did add the whole business of run levels, a jungle of symbolic links, etc., when before there was basically one script that was run during boot. A trivial difference, to be sure :^) At the time SysV init was about as revolutionary compared to the prior approach as systemd is today compared to SysV init. Today's systemd haters would probably have railed against it with the same vituperation.

I haven't done much with upstart, but from what little I've seen of it, it's also based on shell scripts.

With that logic, it would make sense to claim that an air mattress is similar in use and performance to an aircraft carrier since they are both based on the physical principle of flotation.

systemd strongly encourages (if not outright requires) that the logic be implemented in C code

It is true that many of the boot-up tasks that systemd performs, which were traditionally implemented as shell scripts, are provided in the shape of C-based executables. I don't think this is an actual requirement; I seem to recall that the basic idea is to speed up the proceedings. As far as I know there would be no problem with adding things that are implemented in shell code, or replacing some of the C-based tools with shell-based implementations if that proved necessary.

As far as service management is concerned, systemd does implement most of the required logic itself and only relies on non-executable configuration files for the details. This is actually a good thing in my book since, among other benefits, it potentially leads to increased standardisation, where right now the shell-based init scripts are different from one distribution to the next. Again, systemd makes it possible to use traditional SysV-init style init scripts if the administrator so desires. I don't see it as a big problem.

I'm sorry but I don't really see what the rest of your comment has to do with anything.

to post comments

this is exactly what drives people up the wall...

Posted Nov 25, 2011 10:32 UTC (Fri) by khim (subscriber, #9252) [Link] (6 responses)

As far as service management is concerned, systemd does implement most of the required logic itself and only relies on non-executable configuration files for the details.

And this exactly what driver most people up the wall. You see, sysadmins always relied on the power to alter system configuration in twisted, non-standard way. For some it's requirement to fit in twisted, non-standard pre-existing configuration, for some just a source of pride, but they were content in their knowledge that they have power to do anything by changing these shell scripts.

Systemd throws all that away: you can not just "add tiny nodge here and small delay there". You need to either contact upstream (to add configuration knob) or turn the automatic off and write complex and often convoluted script from scratch. This is what irritates people the most in systemd design.

This is actually a good thing in my book since, among other benefits, it potentially leads to increased standardisation, where right now the shell-based init scripts are different from one distribution to the next.

Right. And application developers will probably welcome that. But system administrators will not: they've lost some of their power and are forced to think about real solutions instead of trying to apply chewing gum on the mix of bailing wire. Of course this irritates them.

And, as usual, people who benefit don't have too much energy to fight for systemd (they are there: you can find them in all flamefests about Lennart's creations), but people who are burned fan them hoping against hope that they will be able to keep chaotic nature of Linux where their ability to skillfully manipulate duct tape will be appreciated forever more.

Well, Linux today certainly fulfills the second part of the mantra ("complex things should be possible") but what about first ("easy things should be easy")? The counteroffer (let's add layers upon layers of bandaids on the existing solution) does not help much here so Lennart's way looks like the only viable alternative. Yes, it means that some complex things will not be possible anymore. If they will still be actually needed they can be reintroduced later...

this is exactly what drives people up the wall...

Posted Nov 25, 2011 11:25 UTC (Fri) by anselm (subscriber, #2796) [Link]

Systemd throws all that away: you can not just "add tiny nodge here and small delay there".

Guess what systemd service definition files do allow you to specify individual shell commands that will be invoked at various points of a service's life cycle. Those system administrators who today need to tweak convoluted, distribution-specific SysV init files will likely find it a lot easier to deal with this interface.

Also, SysV init gives you no real way to override a distribution-provided init script with one that you modified, such that your version will take precedence over the one in the distribution and your configuration will not be overwritten once the next version of the distribution package comes around. Systemd does. (And this is after this issue has had 25 years to be straightened out in SysV init. Give systemd 25 years to mature and see what it looks like then.)

All of these things should be painfully obvious to anyone who actually takes the trouble to read the systemd documentation and descriptive blog posts. But of course it is much easier and more convenient to misrepresent the package (and the intentions of its authors) out of a position of ignorance.

this is exactly what drives people up the wall...

Posted Nov 25, 2011 11:41 UTC (Fri) by michich (guest, #17902) [Link] (2 responses)

Can you give any example where systemd forces you to write a complex and convoluted script from scratch? I've seen cases where instead of running a program directly from the systemd unit file it made some sense to call a shell wrapper, but why would it have to be complex and convoluted?

Because you talk about legacy code?

Posted Nov 25, 2011 12:58 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

One recent example: connection to Corbina.Net (I've helped my friend with that). You need start igmpproxy first (because otherwise it'll crash when L2TP disconnects), then you need to check L2TP server (some of them don't work and then you need to try again), then you connect to L2TP server and wait till everything stabilizes - and only after that you can start IPSec to connect to your real VPN network.

With SysV init you can just order all services in proper (tested and working) order while with systemd you either need to properly describe dependencies or run the whole thing as one service.

In first case you need much, much deeper understanding of the problem then "if I run igmpproxy before L2TP client then everything works, if I do it in opposite order then igmpproxy crashes when L2TP client auto-reconnects" in second case you need to write the whole script from scratch.

Because you talk about legacy code?

Posted Nov 25, 2011 13:26 UTC (Fri) by anselm (subscriber, #2796) [Link]

Yes, but which SysV init are you talking about the traditional one where you get to set all the symbolic links yourself, or the one most distributions are using these days, where the symbolic links are set automatically from dependencies in the LSB headers of the init scripts?

In the former case, any ordering you can explicitly impose on SysV init scripts through numbers in symbolic links can trivially be replicated through explicit »Before=« and »After=« dependencies in systemd. This most emphatically does not require a deeper understanding of the problem than you would need to come up with a suitable ordering for SysV init in the first place.

In the latter case, you need to specify all the dependencies in the LSB script headers for the benefit of your SysV init, and the LSB script header doesn't let you do anything that systemd dependencies don't let you do too. If anything, the systemd dependencies are a lot more expressive than the LSB script-header ones, so your job should be that much easier.

Finally, if you need to wait for something to »stabilise« after you have started a service in systemd, you can write a shell wrapper around that service which does the check, and that shell wrapper will be vastly simpler than a full SysV init script.

this is exactly what drives people up the wall...

Posted Nov 25, 2011 12:24 UTC (Fri) by dgm (subscriber, #49227) [Link] (1 responses)

> Yes, it means that some complex things will not be possible anymore. If they will still be actually needed they can be reintroduced later...

So they will still be possible after all...
Honest question: is systemd really so inflexible that I _cannot_ do "interesting" stuff? I thought that ability to run current init scripts preserved that flexibility for when it's needed...

this is exactly what drives people up the wall...

Posted Nov 25, 2011 12:38 UTC (Fri) by anselm (subscriber, #2796) [Link]

No.

(Check the systemd page to find out for sure.)