systemd Or Poettering, Name Your Poison

I’ve been using Debian for many years and rarely had any problem. Since systemd reared its ugly head and Debian “So, summary:
– the world is not perfect
– there are many places where the time can be switched, not only through NTP.
– the hwclock mechanism was perhaps a workaround, but it worked for all of us for many years
– so make sure that something works for all of us is put in place before removing it”
decided to make it the default init, all Hell has broken loose.
e.g. Bug filed in July 2014, and still release-critical today… #755722 – systemd must sync systemclock to RTC on shutdown – Debian Bug report logs.

The issue is the same as I have with the boot-times for my desktop PC, systemd makes assumptions that break Debian systems. In my case, systemd insists on every other service starting and running before attempting to start X, the thing I want up ASAP. In the case of the bug reported above, how the system time was handled over a reboot is changed with systemd. The old behaviour was that the clock was stored and retrieved so things survived reboots nicely. No more. Poettering et al have decided that time should be set by NTP or other means and systemd should not have anything to do with that although systemd is replacing the old init that did… BREAKAGE!!! Now I know why Linus swears so much! If a change to systemd breaks user’s systems, it’s a bug in systemd, not that the world needs to change to be the way Poettering wants. Putting folks who break things in charge of millions of systems is a tragedy of huge proportions. People should not have to rewrite init scripts to switch to systemd. Otherwise, systemd should get the Hell out of our way… or go away…

Fork systemd. Get it away from those fools.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , , , . Bookmark the permalink.

54 Responses to systemd Or Poettering, Name Your Poison

  1. DrLoser says:

    I’ve just noticed this very interesting plaint, Robert:

    Fork systemd. Get it away from those fools.

    This implies that:
    1) You see some value in systemd. (A topic worth exploring, I feel.)
    2) You think somebody else, other than Poettering, Red Hat et al, could do a better job. (Another topic worth exploring.)
    3) You are firmly convinced that an Uber-Fork of systemd would be accepted into the mainstream (Debian, etc) in due course.
    4) You see a benefit in the fork, possibly personal. Might just be juggling the dependencies around so that X comes up 20 seconds faster on Beast, might be something far more trivial.

    I can’t help harbouring the suspicion that you don’t really believe in either of those four propositions.

    You didn’t really mean to say that at all, did you?

  2. oiaohm says:

    Modular Sunfish first you have to accept facts. Upstart is officially declared to be ended nothing is going to change this. Upstart was based on the wrong tech. To avoid cgroups upstart developers uses ptrace to track services resulting in interfering with service debugging.

    Every person who says hey Upstart is an option basically shows they are not up on the topic.

    OpenRC is still cgroup based and is dracut compatible.
    https://dracut.wiki.kernel.org/index.php/Main_Page
    Yes dracut is part of shell scripting removal.

    Modular Sunfish yes dracut is another redhat thing. But if we be real here using shell script based has been a huge mistake from a security point view.

    Only two major parties at play are gentoo and redhat. There are minorities behind consolekit2 and so on.

    Modular Sunfish no matter how this plays out the way of the past will disappear. Even the BSD world is looking into ways to remove shell scripts from their init systems.

    The big picture is that the init system will be replaced. Redhat may win with systemd but even if Redhat does not win sysvinit is dead man walking.

    Basically Modular Sunfish someone had to bite the bullet to fix the security issues of the Linux world. Redhat and Gentoo have both shown their willingness todo this. Ubuntu has chosen to follow the systemd path at this stage.

  3. Modular Sunfish says:

    The problem is systemd is part of a very much larger picture. The problem is to support the larger picture sysvinit has to die.
    It’s a false dichotomy to pretend that the choice is either sysvinit or else systemd. openrc and upstart both replacemens for sysvinit because, unlike systemd, they are init systems. And they are fine ones at that. systemd looks to be nothing more than an attempt by Red Hat to wrest control of the Linux kernel away from Linus by smothering it in a layer of poo. Though I more strongly share the opinion that it aims to be an eventual vehicle for DRM once it gains control over all IO. Either way it is unwanted.

  4. oiaohm says:

    The problem is systemd is part of a very much larger picture. The problem is to support the larger picture sysvinit has to die.

    https://wiki.gnome.org/OSTree is designed with the idea of applications having own cgroup.

    https://people.gnome.org/~walters/ostree/doc/booting.html

    Also brings some serous interesting things. Like that the root file system directory of the OS could be placed at many different locations inside a partition. So a multi distribution Linux install using ostree might be just 1 partition.

    I know is late for Linux world to develop something like SXS that Microsoft has had for years. Cgroups answer a large percentage of the problem of the security arguement about old libraries and old applications.

    Linux world has cease following the path of Posix and is now starting to build its own path forwards. This is going to lead to fights and arguments.

    Ostree packaging of applications is a different form.

    Yes Ostree is a sign that the graphical environments of Linux are taking it serous-ally to be integrated into the OS from top to bottom.

    Next few years are going to be rough.

  5. DrLoser wrote, “systemd, which you can’t yet make work on your system”.

    systemd now works, or at least, stays out of my way, thanks to some ideas expressed by commentators here. To whit, disabling a service in sysvinit allows one to properly control it with systemd, delaying until after X runs, in my case.

    DrLoser also wrote, “you’re obviously the sort of person that a Debian stable release is aimed at.
    So what’s your problem here?”

    I don’t have to go back to Wheezy to be happy but I could. I load other kernels, other browsers and the latest LibreOffice because I like some of the newest features not found in Jessie. I could do that for Wheezy too.

    I think eventually the rough edges will be ground off systemd or something bad might happen to its purveyors but I have two years or more to decide what flavour of Debian GNU/Linux or other distro I will run in the future. Oh, what fun… I’m still not convinced there is any merit in systemd at all but many are. I hope the package gets forked or otherwise taken over by sane developers. The crew in charge now are idiots, not in the sense of being poor programmers, but in dealing with users. They don’t have a clue what users want but are forcing the software on them in any case.

  6. DrLoser says:

    A quick question for you, Robert. You have the choice of Debian Wheezy (the current stable release: latest update, January 10th 2015) or Debian Jessie (the current test distribution).

    You appear to be very happy with Debian Wheezy. Which is a Good Thing.

    You appear to have serious issues with Debian Jessie, mostly to do with systemd, which you can’t yet make work on your system.

    So, here’s my question. You’re obviously not the sort of person that a Debian test release is aimed at. And you’re obviously the sort of person that a Debian stable release is aimed at.

    So what’s your problem here?

  7. oiaohm says:

    DrLoser really I have to explain this.

    Isolation is the key word. Session 0 isolates services from users. Ok what is problem. What is the attack surface. Lot of services provide network functionality right. Since every one of those services is an attack point they really should be in their own sessions.

    In which case, why bring up Vista in the first place?
    Because sessions may have been build into NT design but for years Microsoft never took any advantage of them. This is fairly much the same story with cgroup on Linux. Problem is Vista start of usage of session is far from complete.

    Session 0 Isolation certainly persists, but you have yet to explain why this is a problem and not a benefit of the architecture.
    Yes its an improvement but its not where near the benefit the NT design offers.

    Like a denial of service attack again network enabled services in session 0 can still result cpu starvation for the other services that can possibly result in server crashing. Now if each service is in it own session the possibility of being able to pull of this form of attack would be greatly mitigated.

    There are a stack of other limitations that session do.
    2) cgroup file system name space limitation so reducing attacks at file system level that can happen between services and users. NT sessions can also do this. So if each service was in it own session under Windows it would be possible just like under systemd for them to have like unique /temp directory paths.

    Why systemd feels so restrictive is the all the extra options to stop attackers from being effective. Openrc is also gaining these features.

    DrLoser if you understand what systemd isolation system is doing when you look at windows you see a half assed attempt at the same thing that is no where near providing the benefits it should.

  8. DrLoser says:

    So you don’t know that cpu allocation under NT is directly linked to session. CPU time is shared kinda evenly between sessions.

    No, it isn’t. Not even “kinda.”

  9. DrLoser says:

    Incidentally, Fifi, if you are truly determined to dredge up ancient history — even more ancient than Debian Woody — then you appear to be missing your target. Session 0 existed in Windows XP.

    As a matter of fact, I believe that Session 0 existed in Windows NT 3.51 (1995). It’s sorta a Dave Cutler thing, as far as I can tell.

  10. DrLoser says:

    So you don’t know that cpu allocation under NT is directly linked to session. CPU time is shared kinda evenly between sessions. Windows Vista introduction of Session 0 applies to current day Windows 10 as well.

    In which case, why bring up Vista in the first place?

    Session 0 Isolation certainly persists, but you have yet to explain why this is a problem and not a benefit of the architecture.

    Go ahead, oiaohm: be my guest. Explain.

  11. oiaohm says:

    Why are you addressing this comment to me, oiaohm? I’m practically a fan of system, for goodness’ sake. And almost anything is preferable to sysvinit.

    DrLoser if you are a fan you should really know the advantages. If you don’t you are just a uninformed moron taking a side to attempt to be a pest. Prove yourself.

    1) cgroup cpu resource management to prevent starvation events.

    Why is that one of four reasons for Windows Vista to have Session 0 (whatever that is supposed to mean: I assume you refer to RPC via Session 0), oiaohm?

    So you don’t know that cpu allocation under NT is directly linked to session. CPU time is shared kinda evenly between sessions. Windows Vista introduction of Session 0 applies to current day Windows 10 as well.

    RPC vs Session 0 is not related to this. DrLoser you argued that Windows init system is so great and you don’t know something this basic.

  12. DrLoser says:

    1) cgroup cpu resource management to prevent starvation events.

    Why is that one of four reasons for Windows Vista to have Session 0 (whatever that is supposed to mean: I assume you refer to RPC via Session 0), oiaohm?

    And is there a good reason why we are discussion Windows Vista? It has nothing to do with anything on this thread, does it?

    And if you think I’m going to contribute to your campaign to spend thirty nine separate posts on nonsensical discussions about cgroups and the like, then I’m afraid you’re going to be sorely disappointed.

    DrLoser there are 40+ individual issues systemd deals with that sysvinit lacks the proper controls for leading to kernel level hacks that basically work in some cases and completely fail in others.

    Why are you addressing this comment to me, oiaohm? I’m practically a fan of system, for goodness’ sake. And almost anything is preferable to sysvinit.

  13. oiaohm says:

    DrLoser I have provided 1 of the reasons. Why moving to something other than sysvinit is required.

    1) cgroup cpu resource management to prevent starvation events.

    Its now your turn to provide 2. We will repeat until we get to 40. At that point I will give the remaining. Mind you it should be easy for the first 10.

  14. oiaohm says:

    DrLoser so you don’t have answer so you just have to-do insulting posts.

  15. DrLoser says:

    Kolivas BFS arguements mostly work because sysvinit was crap and cgroup were not being configured by the system correctly. BFS has no where near the same advantages in a systemd system.

    Drivel.

    DrLoser the 40+ reasons are fairly much why Windows Vista has session 0. Also explain why using only session 0 is completely the wrong thing.

    Ancient, pointless, futile, drivel.

  16. oiaohm says:

    robert you did not fully read this did you.
    http://lists.freedesktop.org/archives/systemd-devel/2011-May/002526.html
    No more. Poettering et al have decided that time should be set by NTP or other means and systemd should not have anything to do with that although systemd is replacing the old init that did
    Ok did the old method calculate for clock drift.

    Here is a fun little bug I have in fact suffered from. I had a system with a dead RTC. Attempting to set RTC locked the system up. I do agree by default setting RTC should be off. After confirmation that RTC is in fact alive then setting of RTC should be done from then on if it confirmed dead then it should not.

    So if RTC is set or not it really should be a .service file the administrator chooses to turn on or off. Not something that just automatically happens.

    So the RTC thing is something that should be changed from sysvinit where its in the always run file.

  17. oiaohm says:

    Please note the 40 issue can be partly dealt with by using openrc instead of sysvinit as well. When openrc is complete it will most likely deal with all the issues as well. Simply the kernel requires information to be able to make correct and informed selections. Sysvinit does not provide the information the kernel requires.

  18. oiaohm says:

    In fact, it sounds more like a catastrophic failure of the kernel scheduler to me. Nothing to do with server daemons, either way.
    Its not not exactly catastrophic failure of the Linux kernel schedulers.

    Nt has a per session cpu usage limit. So session 0 cannot stave out Session 1…. out of CPU time no matter how you set the application priority levels. Same with session 1 cannot stave session 0 out of cpu time completely either.

    Linux has cgroups and nice levels. Posix only has nice levels. Cgroups act like NT sessions. Windows vista does not place service in session 0 and users in session 1 and greater for no reason. sysvinit basically is equal to placing everything in session 0.

    A majority of linux kernel schedulers have all the required controls. Starvation can be like a fork bomb. A fork bomb inside a cgroup cpu limiting is many times less effecting to the system.

    Grouping/zoning/sessioning of applications is required for performance stability. Ok annoys the hell out of Kolivas because this does contain some overhead.

    A kernel scheduler only works as effectively as the system configuration allows. Using something like sysvinit that does not configure the information the kernel scheduler requires to operate correctly.
    http://marc.info/?l=linux-kernel&m=128978361700898&w=2
    So you end up having todo a hack like above. That does not work with all services because having there service parts in individual groups and their nice levels basically being nuked means now nothing is getting ready for the service at the right time.

    DrLoser there are 40+ individual issues systemd deals with that sysvinit lacks the proper controls for leading to kernel level hacks that basically work in some cases and completely fail in others.

    sysvinit was design for sysv. Linux is not sysv even sysv was crappy. Remember sysv was very commonly brought to a stop by fork bombs.

    Kolivas BFS arguements mostly work because sysvinit was crap and cgroup were not being configured by the system correctly. BFS has no where near the same advantages in a systemd system.

    DrLoser the 40+ reasons are fairly much why Windows Vista has session 0. Also explain why using only session 0 is completely the wrong thing.

  19. DrLoser says:

    Well, that’s progress but I had to break Debian to do it… Literally, after these changes, aptitude caused Segmentation Fault… Chalk up another epic failure for systemd.

    Or, alternatively, yet another epic failure for the Debian packagers? Those people have history, you know.

    I’m hesitant to cast blame, but what I can say is that anybody who implements stuff at this low a level has an abhorrence of segfaults and will typically work like a maniac to guard against them (or at least fail fast and hard with a decent error message). Why? Because I have spent 20 years of my life working on servers.

    Now, maybe it’s the fault of Poettering et al. Actually, this should be easy to test: run up a VM of Fedora and try the same thing. Or maybe it’s the fault of the Debian maintainers.

    Either way, you need to use the Four Freedoms here, Robert. Consider the plight of your less technically able neighbours, who will soon be inflicted with systemd against their will!

    You owe it to them, I think. In the pure spirit of Community.

  20. DrLoser says:

    I do like the concept of “interactive parts of cpu time,” however.

    It’s awfully sweet, in an anthropomorphising sort of way.

  21. DrLoser says:

    I doubt I’ll get an answer to that one. Ever. So, on to more technical stuff:

    Of course some people have not worked out some of the freezes in Linux are also because items in background can chew up too much cpu time so staving the interactive parts of cpu time.

    Never seen it myself on a Linux (or indeed *nix) server, oiaohm. I can’t quite imagine what a system freeze would have to do with either sysvinit or systemd.

    In fact, it sounds more like a catastrophic failure of the kernel scheduler to me. Nothing to do with server daemons, either way.

    So there are a long list of problems systemd solved.

    Granted your entirely unsubstantiated premise of resource starvation caused purely by sysvinit, oiaohm, that would be “a long list” of how many problems?

    I’ve counted up to one, so far. Care to extend that list?

  22. DrLoser says:

    Yes I have build servers for different things. Yes build servers can bring true misery.

    I must say, I sympathise, oiaohm. It’s an awfully tough, dreary, time-consuming and thankless life, isn’t it, building servers for a living. Hardly any time at all to look up a plethora of completely useless cites and, reluctantly, put those cites to use in several paragraphs of elegant yet idiotic (in the true sense of the Greek source term: I will always admire a man who goes his own way) prose.

    Now, about that IT job of yours. Any clues you care to sprinkle upon those of us who are less worthy?

  23. oiaohm says:

    Robert Pogson Kolivas BFS does not help you when you truly need bias using more than nice levels.

    I have a times many things in background some not so important other than running test case events. Some are nasty setting own nice levels. Yes BFS come apart when you have processes setting insane nice levels. Cgroup cpu limitations override what ever nice levels contained processes set. Yes I have build servers for different things. Yes build servers can bring true misery.

  24. oiaohm wrote, ” some people have not worked out some of the freases in Linux are also because items in background can chew up too much cpu time so staving the interactive parts of cpu time. So there are a long list of problems systemd solved.”

    Weren’t scheduling tweaks fixing that? Kolivas has had a million visits to his site.

  25. oiaohm says:

    Robert Pogson sysvinit has given me huge numbers of problems over the years. Some of it is the applications I am running. Some is just not sysvinit friendly. Yes services that don’t keep same process id numbers. Yes it secure close connection flush all records of the connection but they are just completely evil inside sysvinit so you end up hacking up cgroups and other things around them to attempt to keep them under control.

    Lack of cpu usage control in sysvinit has had me with case of resource starvation due to heavy program in background taking all cpu time.

    There are in fact a long list of behaviors that track to issues with cpu resource allocations.

    It’s not crappy. In the last 6 months, systemd has cost me days of trouble trying to work around it.

    Sysvinit has cost me months of time working around it issues. For me systemd solves way more problems than it causes. Yes systemd is new different and strange requiring different methods to past but at least when I want to say this service can only have 4 percent of cpu time I can be sure of it or be on only a particular cpu core I can be sure of it.

    Robert Pogson basically I hate sysvinit completely due to the trouble it has caused me. Of course some people have not worked out some of the freases in Linux are also because items in background can chew up too much cpu time so staving the interactive parts of cpu time. So there are a long list of problems systemd solved.

    If systemd sysvinit to systemd generator worked correctly and allowed suitable controls you would have been happy and gained a lot of fixes to performance issues.

  26. oiaohm wrote, “If we stick to the sysvinit path in another 20 years the init system will be just as crappy as it has been for the past 20 years.”

    sysvinit has never given me a minute of trouble in 15 years. It’s not crappy. In the last 6 months, systemd has cost me days of trouble trying to work around it.

  27. oiaohm says:

    Robert Pogson systemd is in fact a collection of small programs. But using a very limited set of files to provide their configuration information.

    Fix those problems individually instead of throwing all of them into the bowl and mixing.
    Test casing is one of the major reasons for grouping all the parts in one area.

    With systemd, the odds that systemd will be compromised are increased a dozen times so GNU/Linux will be as insecure as that other OS.
    This backwards.

    Sysvinit are not really that well tested. You don’t have a proper testsuite to give sysvinit based systems a proper work out. It far more likely that someone hacking in a feature into sysvinit will introduce a security problem.

    http://www.freedesktop.org/software/systemd/man/systemd.exec.html
    Just have a good read of this list of options Robert Pogson . Remember each of those options can be used inside any .service file.

    Yes systemd is more complex. But systemd provides many features that would take a very complex sysvinit script to implement and then be highly not dependable.

    Init + all of cgroup control features is a pure nightmare in its own right. Add on network access restrictions and other things.

    Problem here implment each of the part individually trying to join them up latter is just no-go. Remember there is no formal standard for Init system to use OS provided security features in a OS neutral way.

    Do you really want to trust the security of the world’s IT to Poettering’s vision? I don’t.
    Problem here is someone has to build the first one and make it work correctly.

    Openrc is way ahead of old sysvinit. I do see there will be competition to Poettering’s vision in time. Problem is getting items like kdbus and other core parts implemented. Once they are implemented and work correctly other Init systems will be able to use them.

    Remember at first BSD guys hate the idea of logind but after they had a while to think about it they end up agreeing with Poettering.

    A secure IPC is something I am expect in time the BSD guys will accept. Same with need for sandboxing. Generic API to-do features like this always come after the first version is made and is accepted.

    Robert Pogson my point of view is that we have a rough road we have to go down. Ok systemd if it does not sort out all its issues will be replaced in time. But systemd for now is required so the API and other frameworks future init systems will require will exist.

    If we stick to the sysvinit path in another 20 years the init system will be just as crappy as it has been for the past 20 years.

  28. oiaohm wrote, “This is the problem. Most of the time when you look at what he has merged it has turned out to be fairly critical.”

    I don’t think one needed to create systemd to do all that. Fix those problems individually instead of throwing all of them into the bowl and mixing. With systemd, the odds that systemd will be compromised are increased a dozen times so GNU/Linux will be as insecure as that other OS. I’ve never seen a compromised GNU/Linux system. I don’t think I need to worry like that about security. Let those who are paranoid use systemd. Leave the rest of us alone. Do you really want to trust the security of the world’s IT to Poettering’s vision? I don’t.

  29. oiaohm says:

    Robert Pogson problem here is the Debian’s technical committee had to make a selection. If a selection was not made package maintainers would not have any reason to support a fixed up init system. Problem is package maintainers are still skipping out of providing .service files. If the Debian technical committee need todo anything now is make a rule that a package containing only sysvinit files without matching .service files will be rejected and possible vice verser.

    Poettering for throwing everything but the kitchen sink into it.
    Problem here is I don’t see how init system that is secure can be done correctly without following Poettering path.

    1) we need a IPC that is user aware. Yes smart enough that non administration applications and users cannot mess with server settings. That is kdbus and dbus.
    2) we need a logging simple that application cannot enter lies into. That is journald. The old syslog solution is possible for application to write data into other applications log files by lieing about who they are.
    3) logind is session management. The new consolekit2 provides it own api compatible version of logind. Yes upto date consolekit with sysvinit provides logind. So the logind bit really is just a better protocol.
    4) cgroup management that is kinda required to making sure services terminate correctly.
    5) networking integration this is again required for securing services to make sure that a service can only connect to the correctly allowed networks and ports.

    This is the problem. Most of the time when you look at what he has merged it has turned out to be fairly critical.

    Even merging the bootloader recently seams strange. Until you work out that to get security information from the TPM chip to validate boot required working with boot-loader so you have to understand how the bootloader is going to provide up that information and how to make the userspace be able to use it correctly.

    So you need a fairly large team with quite a diversity in knowledge to successfully build a secure modern designed init system. Why such a large team is no one has really done it before.

    Once we know how to make a secure init system breaking it up into bite size pieces becomes possible. Systemd build system seams to mark out how these parts could be broken apart in future.

    Somethings are just unpleasant. Fixing the init system is unpleasant. It takes someone with a fairly tough skin to do it since no matter what he did to attempt to fix it he was going to be called wrong.

    Also something else key to remember most projects that systemd has taken into there main branch has been suffering from lack of maintainers to repair security faults. If people are not going to step forwards to take care of these projects having another project absorb them is the best thing that can happen.

    Apparently a lot of people are not getting the hint. You want to stop systemd taking in project don’t have under-maintained project sitting around that happen to be core parts.

  30. oiaohm wrote, “Most of the issue is shock of change and lack of change by package maintainers who are determined to stick with sysvinit only solutions.”

    Yes, there is plenty of blame to go around: Debian’s technical committee for making systemd the default for the next release before all the issues were settled, the packagers for letting systemd change system behaviour against the users’ wishes, and Poettering for throwing everything but the kitchen sink into it. They are all wrong. Our only hope is that these folks learn from their mistakes instead of leaving everything broken. I am not optimistic on that. I think Debian is resilient and open to intelligent discussion, but Poettering is something else. Let him keep his work in the lab where it belongs, and not in the world’s IT. We don’t need to repeat M$’s mistakes in OS-development.

  31. oiaohm says:

    Robert Pogson it is in “systemd for Administrators” series on Poettering blog.

    Basically everyone got that annoyed with systemd. Like you end up blame a lot of sysvinit faults on systemd because in attempts to hack around issues you find all kinds of sysvinit issues. Not understanding that lot are solved by either disabling the sysvinit part or migrating the sysvinit part.
    http://0pointer.de/blog/projects/systemd-for-admins-3.html

    Systemd is in fact design to sit next on a system that can boot systemd or sysvinit. But configuration of both init systems need to be done independently due to a software bug. Yes there is a bug in sysvinit to systemd generator if this did not have a bug systemd would not need a independent set of configuration files. Please note having proper .service files also reduces systemd ram usage. Yes generated get stored in a ram drive. Yes some of the complains that systemd is ram hungry is also sysvinit to systemd generator.

    Lot of problems with systemd is people have not read the manual or missed key points in the manual. This include me at times.

    I don’t find systemd that bad. Most of the issue is shock of change and lack of change by package maintainers who are determined to stick with sysvinit only solutions.

  32. oiaohm wrote, “if all packages include a systemd .service file and a sysvinit start up script named correctly there would be no problem either.”

    It would have been helpful if that were widely known. Instead all we got was that it made booting faster and a bunch of other advantages that were no advantage to me at all… At least, I will have a “workaround” in my bug report.

  33. oiaohm says:

    Robert Pogson sysvinit and systemd both have their yuck points.

    Disabling the services get away from systemd sysvinit auto-generator. The one problem with the systemd .d directories is no way to remove/replace a line in the master .service file. So this is a bug systemd could fix to make life a lot more friendly.

    systemd provides a unified across distribution way to mark services enabled/disabled.

    Perhaps systemd will sort it out and leave me alone if it thinks I don’t want to run apache2 and databases.
    The problem is those parts don’t have proper service files in the first place. So you need to tell the sysvinit to systemd generator that sysvinit does not want to run them so you then can use a proper .service file. In fact it possible to put in a proper service file.

    http://wiki.linuxquestions.org/wiki/Update-rc.d

    Just to be fun update-rc.d is debian related distributions only.

    If you do lookup the generator you will find a few interesting things.

    If /lib/systemd/system/ contains a file [name].* and the /etc/init.d/[name] happen to exist the generator for systemd does not make a .service file.

    So if all packages include a systemd .service file and a sysvinit start up script named correctly there would be no problem either.

    Yes it a case of A + B equals ouch.

  34. oiaohm wrote, “All I did on my system is update-rc.d [service] disable on the old sysvinit services then placed in systemd service files I configured to start the services when I wanted to. “

    Didn’t work here. systemd complained of a loop with the service enabled. I didn’t think to try disabling a service that I wanted to run until today… It’s not exactly intuitive… 😉 Perhaps systemd will sort it out and leave me alone if it thinks I don’t want to run apache2 and databases. It’s kind of like a slave figuring out how to please the slave-owner. Yuck…

  35. oiaohm says:

    http://positon.org/disable-a-service-with-update-rcd-under-debian-update-resistant

    Robert Pogson the reason why aptitude is broken is due to the borked interface with sysvinit and you incorrect method for debian for taking out services out of sysvinit.

    You are meant to use the command update-rc.d to disable services. Failure to-do so will cause aptitude to malfunction. This is just one of the many bugs about sysvinit I want to see dead. The idea that you can magically alter the bash scripts in sysvinit directories and not have bad things happen is so wrong its not funny.

    What is the difference between C binaries and most of the bash files in the rcx.d and init.d directories in most to a system administrator not much.

    Really personally I don’t think deleting files should under any case result in package management being not able to run unless it key files to package management. Noting in /etc/init.d should be a key file. Yes you can destroy aptitude operation on a non systemd system by deleting files out of /etc/init.d as well.

    All I did on my system is update-rc.d [service] disable on the old sysvinit services then placed in systemd service files I configured to start the services when I wanted to.

    This is a very stiff reality. What you deleted /etc/init.d will be put back when the package updates. Any modification to files from packages in /etc/init.d will also be undone. This really ruins the arguement that sysvinit provide magically control to administrator.

    Systemd provided .d directories for administrators to put away their alterations in locations not effected by packages.

    DrLoser really keep you nose out of this topic you really don’t know init systems. You had no clue what Robert had in fact done wrong. And the fact it going to fail on him in future because he as done it wrong.

    Or the fact the package management system that is meant to be init system neutral is in fact init system dependent so a breach of idea of init system neutrality.

    Most people who claim a stack of things are possible really don’t understand what limitation distributions place to modifying the init processes.

  36. DrLoser says:

    Frying pan or fire… I’m old. I don’t want to fight anymore.

    Say it ain’t so, Robert:

    I have shown GNU/Linux to thousands of students and hundreds of teachers over the years and will continue in some way doing that until I die in spite of the opposition.

    Respectable fighting words, is those.

    Fight on, (fellow) old man!

  37. DrLoser says:

    I was thinking I could delete my init scripts for apache2, mysql and postgresql… Would systemd leave me alone then? I can always start them up with a signal from the desktop after my session started. What would APT do with missing init scripts?

    Good thinking, Robert. Why don’t you do just that? (I’d take a little more care than you did in Easterville, and make sure you can restore them.)

    Try it. If it works, good. If not, restore the status quo ante bellum.

    It is the Professional IT Way. Welcome to my world!

    As an ultimate solution, this is of course fatuous. But as an intermediate solution, and since your Precious Bodily Essences seem to depend upon shaving 30 seconds off the boot time, it’s a darned good start.

    Wrap up all the bits and pieces you need to sustain your rather sad illusion that you are in charge of any Debian boot process whatsoever, stick ’em in a single shell script, run it once system boots up, and yer done.

    Done like a raw prawn on a barbeque, but many of my best friends are raw prawns.

    Go to it! This could be the solution to systemd that will make all the other whiners sit up and take notice!

    Alternatively it’s a useful diagnostic tool to work out where you mucked up on the dependencies. But I don’t want to load your creaking back with too many Professional Dependencies here.

  38. jeremy anderson wrote, “to this day it still doesnt respect /etc/init.d scripts”.

    I was thinking I could delete my init scripts for apache2, mysql and postgresql… Would systemd leave me alone then? I can always start them up with a signal from the desktop after my session started. What would APT do with missing init scripts? It’s a mess, making work for innocent people just wanting to control their systems. The huge advantage of Debian for system administrators was that Debian had reasonable defaults and APT maintained the whole system. Now systemd has corrupted the process to wreck users’ systems.

    UPDATE This gave me an idea. On a system running Jessie without systemd, I removed /etc/init.d/mysql and rebooted. OK, MariaDB did not start. Then I installed systemd and rebooted. Again, MariaDB did not start. Fine. I created the appropriate servers.service file and systemd did start MariaDB. I made it with After=display-manager.service and Voila! it worked. OK, but what’s APT going to do with that???

    systemctl --after list-dependencies servers.service
    servers.service
    ● ├─lightdm.service
    ● ├─system.slice
    ● ├─systemd-journald.socket

    Well, that’s progress but I had to break Debian to do it… Literally, after these changes, aptitude caused Segmentation Fault… Chalk up another epic failure for systemd.

  39. kurkosdr wrote, “Are you going to keep using a systemd-taint distro, switch to some small untaint distro, or switch OSes altogether and go to some Unix?”

    I don’t know. I can use Jessie for the next few years I guess. By then I may be dead or sanity will prevail. Here, I have a couple of systems without systemd and a few with. I may survive by putting the software on Beast in a virtual machine with an old release or Heaven forbid, building stuff from source code or finding another distro for Beast. We shall see. I am a deer hunter. I believe if I wait long enough the right opportunity will arise. I will file a “wishlist” bug report when Jessie is released. Perhaps the Debian developers can fix my problem and I can live with systemd but I doubt it because the cancer is growing. If they do fix this problem, next year there will be others even closer to home. I’m hoping eventually Debian will fix itself. Right now it looks like a train-wreck is imminent but it’s still on the rails and has brakes.

  40. Modular Sunfish wrote, “your last and only hope is Devuan”.

    Frying pan or fire… I’m old. I don’t want to fight anymore. I just want to enjoy software and computers until I die. I hope I die before systemd and Poettering terrorize my neighbourhood. I doubt Devuan can compete with Debian while depending on it. systemd can keep spreading and make it almost impossible to have a full-featured distro without. We already have many user-level packages sucking up to systemd. This is driving a wedge between users and developers as bad or worse than the FLOSS/OSS debate ever was. At least then we could tell what software was OK to use. Does anyone know the roadmap for all the thousands of packages we use? Will APT eventually be unable to build a system without systemd? The OS is supposed to be layered. systemd is like a volcanic mountain range piling stuff on top of stuff with great violence. I don’t see any good outcome in the near term. My only hope is that sanity prevails by Jessie+1. It’s just so silly to scrap everything and start over just to be farther behind. LTS is a Band-Aid. The work in maintaining a distro not using systemd will only grow if Poettering has his way for another year.

  41. lpbbear wrote, “Many distros made the jump to the new version of KDE far too early, at a point when the newer version was not even close to being ready for prime time.”

    Exactly. There may have been good reason to put systemd into experimental or even testing but it was a huge blunder to make it the default init-system for the next release. That was wrong and absolutely premature. It’s almost certainly to delay Jessie for nearly a year and make Jessie unusable in many use-cases. There won’t be anyone with a smooth upgrade-path to Jessie+1. Of course we’re not locked in but it is a time-waster to have to adapt to systemd or to move to another distro for no particular benefit. I think the best thing might be to fork systemd. A new thing has to be created which has the advantages of systemd but leaves the carcinogen behind.

  42. Hussam Al-Tayeb wrote, “Linux has reached a point where it needs to provide something to compete with its forks.”

    There’s nothing at all wrong with improvement but systemd isn’t improvement as far as I can tell. There is absolutely no benefit to users of systemd taking over everything in GNU/Linux. An init-system should be a fairly low-level thing known only to system-administrators. Consider a user installing mate-desktop-environment because he likes the look/features/etc. He has to install systemd. It also insists on pulseaudio. Why is that? Has the world gone mad? Why should a GUI require a particular init-system and sound system? This is a problem of too many dependencies. What’s next? A particular kernel? A particular package-manager? Why can’t my distro be my distro and not Poettering’s?

  43. i am conflicted on this issue

    yes they are cramming way to much into systemd, but at the same time the overall goal is respectable. and that apears to be to help administrators maintain a single standard. yes and no so far. its broken more then i’ts fixed. its ruined my day many times. to this day it still doesnt respect /etc/init.d scripts. if i change one of those to non executable it would be nice if systemd respected that..

    instead it came in doing everything on its own ignoring what existed and in my opinion its a show of power.

    there are many types of programmers out there, those that understand gracefull fallback and those that simply want to control everything. i think we know which one backed this project…

    am i willing to give systemd a chance, well givin that every distro under the sun (well most major distro’s) already switched we are forced. but its not a big deal for us debian lovers. just reinstall sysvinit-core and it will conflict with systemd and auto remove. (then reboot)

    now this is not the end of it, it is really bad programming standard and against the GNU/Linux philosophy to have hard depends on other projects. which is what alot of things have now on systemd, can we even install certain programs without it now? gnome for example? most people use GNU/Linux because they liked choice. since systemd steped in choice is harder to do, but reality is this is seperating the real admins from the frauds, the real programmers from the posers and the students from the profesionals.

    well i’m done ranting and raving. i hope this helps others understand whats been going on. again, i’m only conflicted. i hate that it ignores /etc/init.d scripts but i also respect the cgroup goals. with that said i also dislike console-kit and policy-kit. they have a purpose, but not for a home users pc.

  44. Robert Pogson, you are already running udev. Apart from the slower booting, the only user visible thing systemd did to your system is replace the init binary and add logind instead of consolekit. You can even still pipe logging to syslog-ng.
    No one complained when everything dropped support for fam and used linux’s inotify instead eventhough we lost network based watches. This is basically the same thing…moving to a more linux-ish solution.

    Systemd doesn’t have a native cron daemon. It does however support running services at scheduled times. I still use crond.

    Again, I understand your sentiments. There is not much room for ‘debianism’ in systemd.
    Look at this from a different view. What is the biggest use of Linux kernels right now? The answer is android. Android has its own userspace system.
    Tizen maintains a copy of systemd in its git tree. Linux has reached a point where it needs to provide something to compete with its forks.

  45. lpbbear says:

    I have no experience with systemd. I don’t care for Ubuntu. I have used RedHat in the past, when it was free, but not since it became commercial. My current distro is PCLinuxOS and apparently at this time they are not using systemd but I have not looked into that.
    I remember a few years ago during the transition from the KDE 3.x series to the 4.x series. Many distros made the jump to the new version of KDE far too early, at a point when the newer version was not even close to being ready for prime time. That irresponsible decision by distro maintainers caused a huge amount of problems for users. Its taken a while but KDE 4.x has finally become a useable desktop manager.
    That being said I’m sure that the dev for systemd means well but its likely his effort is not at this time where he really intends it to be. Like the early KDE 4.x versions its a work in progress.
    If that is the case then the real blame for the problems being caused by its inclusion in current distros lies with the distro maintainers and not the dev of systemd for including what might be a half baked version into their mainline distro versions.
    Rather than dumping it (and KDE in my earlier example) into a functioning production distro it should be first tested in numerous experimental distro versions released separately from functioning main versions.
    I don’t blame users for being irate when distro maintainers take this kind of action without first going through a looooong and proper testing period.
    Unfortunately many distros do not take this approach. This kind of thing plus the inclusion of many non functioning or barely functioning software packages happens way too often in many distros.
    If its inclusion is causing users problems blame the distro maintainers who choose to include it….not the dev who created it. It is after all still a choice.

  46. Modular Sunfish says:

    Wheezy does not have much systemd and will have an LTS version for x86 The only way to avoid the crime that is systemd and stay with a current Debian is to move to either Debian GNU/kFreeBSD or Debian GNU/Hurd. GNU/Hurd is only i386 and both might be better on servers than on home or work desktops. However, both are worth taking a look at and running through your key use-cases.

    If your heart is set on GNU/Linux then your last and only hope is Devuan. Hopefully it will not be too long in coming. It’s a lot of work to start a new distro on short order but an alpha version will arrive sooner or later.

    For those that can’t wait and must plan now for years of use, they are moving to FreeBSD or its derivatibe PC-BSD. FreeBSD just moved its support cycle to a 5-year model and that beats even Debian’s which has been about 3 years in practice.

    Just *don’t* use systemd. The fundamental design is broken and so is the support model.

  47. kurkosdr says:

    “If GNU/Linux with systemd were simpler,”

    Dear Pogson, I don’t think he meant Systemd is simpler. I think he said it makes the whole “Desktop Linux” ecosystem seem simpler by reducing fragmentation. A dubious advantage if you ask me, since there are only 2 distros most of the 1% of computer users that are Linux users care about: Ubuntu/Mint and RHEL/CentOS. Okay, maybe Debian too.

    Everything else, Gentoo, Slackware or whatever is literally the 1% of the 1%.

    Fragmentation is not a problem for Linux. The problem of Linux is that most distros are not compatible with themselves (aka previous versions of themselves, aka not backwards compatible).

    Anyway. I want to ask Pogson: What’s next? Are you going to keep using a systemd-taint distro, switch to some small untaint distro, or switch OSes altogether and go to some Unix?

  48. Hussam Al-Tayeb wrote, “Debian get hit bad because it had its own very different way of doing everything. And I understand that. Debian was never just a distribution. It is a whole operating system. Debian already had it’s own little version of everything (kind of like systemd does) and they worked hard at establishing “debianism” and the Debian system. It won’t be easy for them to move to a new way of doing things. But they need to make sacrifices for the sake of bridging the gap between technologies.”

    This is the key. systemd is out to destroy independent distros like Debian rather than improving GNU/Linux. That’s wrong. That’s anticompetitive. I want choice. I want to control my system rather than having it control me.

  49. Hussam Al-Tayeb wrote, “I don’t claim systemd reduces boot times.”

    Poettering does. In his list of optimizations a user can make to boot faster with systemd is, “Add socket activation to X. Due to the special socket allocation semantics of X this is useful only for display :0. This should allow parallelization of X startup with its clients.” My particular problem was that systemd does not allow parallelization of X with things that are not its clients…

    He also wants us to get rid of Cron, local consoles, and a whole bunch of other stuff. He wants to redefine what a GNU/Linux distro is.

  50. Robert Pogson, then that sounds like a Debian issue. ArchLinux’s initscripts never had parallel daemon starting.

    Systemd uses targets. That means X starts after the networking things and the multi-user target. This is what eventually allows rootless X.

    I really feel that most distributions were able to adjust with little changes apart from the syntax of enabling/disabling services, apart from Debian.
    Debian get hit bad because it had its own very different way of doing everything. And I understand that. Debian was never just a distribution. It is a whole operating system. Debian already had it’s own little version of everything (kind of like systemd does) and they worked hard at establishing “debianism” and the Debian system. It won’t be easy for them to move to a new way of doing things. But they need to make sacrifices for the sake of bridging the gap between technologies.

    I don’t claim systemd reduces boot times. But I think those technologies (cgroups, socket activation, etc…) systemd, wayland, Qt5, etc… are necessary for building a foundation that will eventually allow Linux to be taken seriously. We must not keep Linux in the basement where it is only used by people who think Linux is some religion or fan club.

  51. Agent_Smith wrote, “It’s very disturbing when the guys at FreeBSD see systemd for what it is”.

    “The goal is clear, the systemd developers want it to be the gatekeeper of userspace. The problem with it is that it’s nothing more than an undocumented, standardless, hackjob with the backing of one of the biggest players in the Linux world (RedHat) which will only benefit them, with the added long-term goal of creating vendor lock-in. How long until they decide it’s going to handle package management and require RPM? How long until they start signing services and packages and locking you out from using your own unless it’s signed by them? How long until they start implementing ways of preventing Oracle from basing their Linux distribution off it, and everybody else for that matter? How long until the Linux kernel itself becomes so hardwired to it that the two will be indistinguishable and we’ll just have RedHat systemd/Linux and that’s it, for which the motto will be “you can have any Linux you want as long as it’s systemd.” The possibilities they now have is scary to think about and what they’ll end up doing with it, especially once more and more distributions give up trying to fight it, effectively giving RedHat even more control.”

    That does disturb me. Potentially, moving to another distro will not help escape some problem nor approach some solution to real problems. It’s like the prison of that other OS. It horrifies me that Debian is crossing users off their list of duties in the Debian Social Contract: “We will be guided by the needs of our users and the free software community.” Users don’t need systemd. They need an init system that works for them instead of enslaving them. There’s nothing wrong with systemd replacing sysvinit, but there definitely are some things wrong with it replacing a lot of other things at the same time. systemd, as Poettering imagines it, is a cancer taking hold of GNU/Linux.

  52. Hussam Al-Tayeb wrote, “are you honestly going to tell me that a few extra seconds of boot time are going to ruin your day”.

    Of course not, but are you honestly going to tell me that systemd reduces boot-times when I offer a simple case where it nearly doubles boot-times? Simply, why does systemd delay X until after apache2, postgresql and mysql have finished their start-ups? Does that make any sense? Those services, while important are a far lower priority to me than Gmail or Fab 94.3 or MrPogson.com which are already up on the web and to which systemd denies access through my web-browser. Why can’t there be a simple way for me to start them after X is up? Why? There was, before systemd arrived as the default init in Debian.

    I want Jessie to be released ASAP. If I ask for this “wishlist” item, Jessie might be delayed even more. systemd looks like it has caused nearly 1 year delay so far and counting…

    He also wrote, “it is bringing back the KISS concept into Linux because it is reducing the vast amount of fragmentation between Linux distributions.”

    If GNU/Linux with systemd were simpler, why is it impossible to start X before my local web-server and databases? Why? I’ve tried and systemd complains that I can’t do that. X has no package-dependency on systemd so it should be able to start ASAP.

  53. I have been using Linux since the 90s and I happen to like systemd. I feel it is bringing back the KISS concept into Linux because it is reducing the vast amount of fragmentation between Linux distributions. We no longer have a million initscript implementations. Instead we have one init system (systemd) which does the job well enough. Sure there are bugs but instead of ranting, ask your distribution to contribute fixes.
    Regarding boot time, are you honestly going to tell me that a few extra seconds of boot time are going to ruin your day? It’s not as if we all reboot our computers every 20 minutes and compete over boot times.

  54. Agent_Smith says:

    It’s very disturbing when the guys at FreeBSD see systemd for what it is, while guys in the GNU/Linux “community” hail it as a Godsend…
    https://forums.freebsd.org/threads/how-is-freebsd-coping-with-a-systemd-future.46667/page-3#post-266974

    Regards,

Leave a Reply