Yeah, yeah I know the history of its development and how log files are binary and the whole debug kernel flag fiasco. And I don't care. By the time I used systemd, that had already long passed.
I switched from Squeeze to Jessie a couple years ago, had some growing pains as I learned how to use systemd... but that was it. No stability issues, no bugs. Can't say whether things run better, but they definitely don't run worse.
I had only really been using Linux for a few years before the onset of systemd, and hon
Perhaps you have had no problems with systemd because you aren't trying to use it to do much.
Lots of people, myself included, have had issues trying to get things which are trivial in pre-systemd or on other OSes to work properly and consistently on systemd. There are many, many, many examples of issues. If someone asked me for examples, I'd have a hard time deciding where to start because so many things have been gratuitously changed. If you really think there aren't examples, just read this thread.
Don't let the perfect be the enemy of the good. If you have so many examples that you "don't know where to start", then start anywhere. You don't have to come at me with the best, most perfect example. Any example will do! I'm actually very interested. And I have, out of curiosity, looked a bit. But like you looking for why systemd is better, I came across a similar problem.
Your reply just continues the cycle I spoke of, where people who potentially know better than me, like you, claim there are problems but expect me to go looking for them myself. I don't have the expertise about OS development to make an informed decision about these issues that go way over my head. All I can do is look at my experience as a user, which has been perfectly fine.
I do agree, in principle, that the onus is on the devs of systemd to justify its existence. But Debian switched over to systemd and since I use Debian, so did I. That's it. Who am I to argue with the Debian devs about what's best for their distro? Why would I switch to a less supported distro when I have no reason to? You're probably right in that I'm not using systemd to do much, so I haven't come across the major issues other people have. But that's exactly why you have to tell me what they are.
That's why I made the argument that "the market has spoken". It is about marketing, and the anti-systemd cohort has failed to market its arguments towards people like me. And the fact that major distros who switched to systemd have not seen their usage plummet in favor of ones that didn't proves it. If you're not going to make an effort for people like me to understand your position, then neither should I.
systemd fails silently if something is wrong in/etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged/etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying. Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
The problem is that one camp won't admit that old init is a pile of shit from the 80's whose only virtue is that the stench has faded over time, and the other camp won't admit that their new shiny toy needs to be understandable and debuggable.
A proper init system needs dependencies and service monitoring. init + monit does not cut it today. Systemd does that bit rather impressively well. It's just terrible at actually booting the system, all the early boot stuff that you could depend on old init to get right every time, or at least spit out aggressive messages about why it failed.
Meanwhile here I am, running Gentoo, with init scripts that have had real dependencies for over 15 years (as well as a bash-based but much nicer scaffolding to write them), with simple to use admin tools and fully based on text files, with cgroup-based process monitoring (these days), and I'm wondering why everyone else didn't get the memo and suddenly decided to switch to systemd instead and bring along all the other baggage it comes with. Debian and Ubuntu had garbage init systems, and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half. You can also use systemd with Gentoo if you want, because user choice is a good thing.
and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half.
Gentoo does everything right except exist. On alternate days you can follow the install instructions identically and get totally different results. Gentoo is its own worst enemy.
With that said, lots of people have screamed often and loudly in many locations that Gentoo proves that this stuff is possible without systemd, and that there are at least two init systems which were already in relatively common use when systemd was shat out which support parallel init. This has simply been resoundingly ignored by t
I ran Linux on the desktop (and LOTS of servers) for 19 years, but finally got Mac religion about 4 years ago. As I had used Gentoo for about 5 years over this time, I was wondering how they had handled this. Found this: https://wiki.gentoo.org/wiki/G... [gentoo.org]. Looks like it's just as straightforward as I would have hoped, and the documentation was just a clear as usual for the project. It actually makes me want to emerge a new desktop system, just for old time's sake.
At one point I did have exactly the problem addressed in the article; I followed the steps therein, and the problem went away, and hasn't recurred since. I won't pretend I've never had issues with Gentoo; I have, although probably 80% turned out to have been self-inflicted. Nonetheless I find that it has bought me valuable time to not have to deal with all the systemd nonsense so long as I don't try to run Gnome, which I wouldn't anyway (I prefer XFCE). I've no doubt that sooner or later I will be forced
systemd fails silently if something is wrong in/etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged/etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
It retries for a bit, but it DOES eventually fail and kick you out to a recovery shell. It just doesn't do it immediately because it assumes that the device may just need some time to come up.
Thanks to the binary log files you cannot even boot something random and read the logs,
What do you mean "boot something random"? I don't see why a generic recovery disk can't have journalctl installed. How about a Debian install disk?
but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
Not true at all. If you don't know how to use journalctl, that's on you.
Nothing pertinent to the error was logged. Feel free to not believe it.
I don't believe it. Feel free to provide details on how you were looking through the logs.
It did not fail to a recovery shell after being left overnight.
There is a way to boot into an emergency shell when this happens.
Your attitude is part of why systemd is so reviled.
I could say the same about yours. I mean, the parsing of fstab by the local-fs.target is VERY well documented. And so are the early boot debugging features. Why would you upgrade a system before at least taking a cursory look at the documentation? I successfully migrated a moderately complex system dependent on an external ZFS disk array, several NFS expo
There is a way to boot into an emergency shell when this happens.
Yet you don't seem to be willing to share that information. That's probably the attitude he's talking about, if I had to guess. I remember a time when a member of the Linux community would have responded with something helpful along the lines of:
You can add break to your kernel line to get a shell on your initram, you can even decide to get it before or after mounting...
Possibly even elaborating on just how to go about doing that but, at the very least, pointing the user in the right direction.
There was a time when ignorance was met with information, rather than ridicule. If you want people to embrace your beloved systemd, perhap
Which is moderately annoying if you have access to the system console and you can guess that an unchanged/etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
As far as I know, this (correct according to documentation/intent) behaviour has been the same since any stable distribution shipped systemd as the default init.
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying.
And should teach you to always 'mount -a' when you have made a change to your/etc/fstab.
Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
In most of the cases I have seen this, it is when someone wrote a service unit file without even bothering to read systemd.service(5) and didn't put a Ty
Here we go again with all the insinuations and accusations. The/etc/fstab was correct with the old init. It was incorrect with systemd. Therefore no amount of mount -a would have helped.
"So, you were relying on bugs to boot your systems?"
Have you stopped beating your mother when she tells you to come out of your basement?
Well, I have never seen this myself, or seen valid bug report about. Yes, if your fstab entry was correct and that caused systemd to not boot, you should file a bug report.
However, I have also seen soooo many invalid complaints about systemd where the systemd beaviour was correct but other implementations were wrong (conflicted with the sgstem documentation).
systemd's approach is to boot correctly, or if a required resource is not available to not boot into a partial state.
Here's a few. It has no concept of imperative (Just do what I said), or best effort (everything must be perfect or it won't even try to continue). It hard codes things that should be configurable or external. For example, it has it's own idea of what makes a device ready for a filesystem to mount and it can't be told otherwise.
All of that is why soft RAID must be assembled in the initrd before systemd has a chance to screw it up. Otherwise, there is simply no way to tell systemd to complete the boot process
And once again a systemd opponent proves to be an idiot or a liar. Handling a degraded array and making it bootable has always been the job of the initramfs. See this Debian bug dealing with this issue [debian.org], for example, where the maintainer himself admits so.
Funny thing is, you were so desperate to deny the systemd bug that you pulled up the wrong issue entirely.
The initramfs HAS to handle the RAID for the root filesystem, naturally. Non-root RAID is supposed to be handled after transferring control to the actual init.
Same for non-root btrfs.
If there's an idiot or liar in this thread, it isn't me.
The initramfs has to handle all degraded arrays, otherwise they will be marked inactive, and not mounted. The right place to fix issues with degraded arrays being marked inactive (and thus umountable) is in the initramfs.
Which the Debian maintainer admitted; it was his change in the initramfs scripts that marked the arrays inactive and made them fail to mount.
Again, you are so bound up in your systemd hate that you fail to read.
I read just fine. The workaround is in initramfs, but that's just because systemd is incapable of handling it. Prior to that, the old sysV init handled it just fine.
Not that when I first tested systemd, it was on a working test dummy with a btrfs. It worked just fine before, including when I degraded btrfs. Then I 'upgraded' to systemd and it wouldn't boot. It wouldn't just fail to mount the btrfs (non-root), it just dropped to an emergency shell with no remote services running.
While I do have concerns about systemd, most dependency schemes have a way for a component to declare itself a prereq to an unwitting third party component. It's a valuable cabability in general when trying to enhance behaviors of existing systems without modifying components needlessly.
I'll grant the similarity, but at least the Debian scripts don't create hard dependencies. The boot won't stop as a result. That system might refuse to implement a new configuration if it detects that the advisory dependency cannot be met, but end of the day, the links in/etc/rcN.d will be control the boot and if one fails, it will move on.
The X- prefix provides some indication of knowledge that it's a dirty hack, but it is somewhat less problematic given the small number of init.d scripts all kept in one
There's many hours of reading the Debian CTTE and bug archives about the system init discussion if you have a bit of time and are that interested.
A short version, which is mostly still applicable and accurate for the large part from the past 2 years, is the Debian debate wiki pages with the arguments for and against various init systems to switch to. It's notable that *no-one* wanted to use sysvinit moving into Jessie, and the votes for upstart were heavily partisan being current and ex-canonical employee
The road to ruin is always in good repair, and the travellers pay the
expense of it.
-- Josh Billings
I have no problem with systemd (Score:4, Interesting)
Yeah, yeah I know the history of its development and how log files are binary and the whole debug kernel flag fiasco. And I don't care. By the time I used systemd, that had already long passed.
I switched from Squeeze to Jessie a couple years ago, had some growing pains as I learned how to use systemd... but that was it. No stability issues, no bugs. Can't say whether things run better, but they definitely don't run worse.
I had only really been using Linux for a few years before the onset of systemd, and hon
Re: (Score:5, Insightful)
Perhaps you have had no problems with systemd because you aren't trying to use it to do much.
Lots of people, myself included, have had issues trying to get things which are trivial in pre-systemd or on other OSes to work properly and consistently on systemd. There are many, many, many examples of issues. If someone asked me for examples, I'd have a hard time deciding where to start because so many things have been gratuitously changed. If you really think there aren't examples, just read this thread.
On the
Re:I have no problem with systemd (Score:3)
Don't let the perfect be the enemy of the good. If you have so many examples that you "don't know where to start", then start anywhere. You don't have to come at me with the best, most perfect example. Any example will do! I'm actually very interested. And I have, out of curiosity, looked a bit. But like you looking for why systemd is better, I came across a similar problem.
Your reply just continues the cycle I spoke of, where people who potentially know better than me, like you, claim there are problems but expect me to go looking for them myself. I don't have the expertise about OS development to make an informed decision about these issues that go way over my head. All I can do is look at my experience as a user, which has been perfectly fine.
I do agree, in principle, that the onus is on the devs of systemd to justify its existence. But Debian switched over to systemd and since I use Debian, so did I. That's it. Who am I to argue with the Debian devs about what's best for their distro? Why would I switch to a less supported distro when I have no reason to? You're probably right in that I'm not using systemd to do much, so I haven't come across the major issues other people have. But that's exactly why you have to tell me what they are.
That's why I made the argument that "the market has spoken". It is about marketing, and the anti-systemd cohort has failed to market its arguments towards people like me. And the fact that major distros who switched to systemd have not seen their usage plummet in favor of ones that didn't proves it. If you're not going to make an effort for people like me to understand your position, then neither should I.
Except I am, right here, right now.
Re:I have no problem with systemd (Score:5, Insightful)
systemd fails silently if something is wrong in /etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying. Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
The problem is that one camp won't admit that old init is a pile of shit from the 80's whose only virtue is that the stench has faded over time, and the other camp won't admit that their new shiny toy needs to be understandable and debuggable.
A proper init system needs dependencies and service monitoring. init + monit does not cut it today. Systemd does that bit rather impressively well. It's just terrible at actually booting the system, all the early boot stuff that you could depend on old init to get right every time, or at least spit out aggressive messages about why it failed.
Re:I have no problem with systemd (Score:4, Interesting)
Meanwhile here I am, running Gentoo, with init scripts that have had real dependencies for over 15 years (as well as a bash-based but much nicer scaffolding to write them), with simple to use admin tools and fully based on text files, with cgroup-based process monitoring (these days), and I'm wondering why everyone else didn't get the memo and suddenly decided to switch to systemd instead and bring along all the other baggage it comes with. Debian and Ubuntu had garbage init systems, and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half. You can also use systemd with Gentoo if you want, because user choice is a good thing.
Re: (Score:2)
and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half.
Gentoo does everything right except exist. On alternate days you can follow the install instructions identically and get totally different results. Gentoo is its own worst enemy.
With that said, lots of people have screamed often and loudly in many locations that Gentoo proves that this stuff is possible without systemd, and that there are at least two init systems which were already in relatively common use when systemd was shat out which support parallel init. This has simply been resoundingly ignored by t
Re: (Score:2)
I ran Linux on the desktop (and LOTS of servers) for 19 years, but finally got Mac religion about 4 years ago. As I had used Gentoo for about 5 years over this time, I was wondering how they had handled this. Found this: https://wiki.gentoo.org/wiki/G... [gentoo.org]. Looks like it's just as straightforward as I would have hoped, and the documentation was just a clear as usual for the project. It actually makes me want to emerge a new desktop system, just for old time's sake.
Re: (Score:2)
Re: (Score:2)
I must admit that I did not know about Gentoos init system. It seems very sensible.
Re: (Score:2)
systemd fails silently if something is wrong in /etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
It retries for a bit, but it DOES eventually fail and kick you out to a recovery shell. It just doesn't do it immediately because it assumes that the device may just need some time to come up.
Thanks to the binary log files you cannot even boot something random and read the logs,
What do you mean "boot something random"? I don't see why a generic recovery disk can't have journalctl installed. How about a Debian install disk?
but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
Not true at all. If you don't know how to use journalctl, that's on you.
Re: (Score:2)
It did not fail to a recovery shell after being left overnight.
And a generic recovery disk can obviously have journalctl installed. It just didn't. Which meant I had to mess with PXE and all that again.
Nothing pertinent to the error was logged. Feel free to not believe it.
Your attitude is part of why systemd is so reviled.
Re: (Score:2)
Nothing pertinent to the error was logged. Feel free to not believe it.
I don't believe it. Feel free to provide details on how you were looking through the logs.
It did not fail to a recovery shell after being left overnight.
There is a way to boot into an emergency shell when this happens.
Your attitude is part of why systemd is so reviled.
I could say the same about yours. I mean, the parsing of fstab by the local-fs.target is VERY well documented. And so are the early boot debugging features. Why would you upgrade a system before at least taking a cursory look at the documentation? I successfully migrated a moderately complex system dependent on an external ZFS disk array, several NFS expo
Re: (Score:3)
There is a way to boot into an emergency shell when this happens.
Yet you don't seem to be willing to share that information. That's probably the attitude he's talking about, if I had to guess. I remember a time when a member of the Linux community would have responded with something helpful along the lines of:
You can add break to your kernel line to get a shell on your initram, you can even decide to get it before or after mounting...
Possibly even elaborating on just how to go about doing that but, at the very least, pointing the user in the right direction.
There was a time when ignorance was met with information, rather than ridicule. If you want people to embrace your beloved systemd, perhap
Re: (Score:2)
systemd fails silently if something is wrong in /etc/fstab. It just doesn't finish booting.
So, it behaves correctly according to the fstab(5)man page from the release before they switched to systemd? [debian.org]
Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
As far as I know, this (correct according to documentation/intent) behaviour has been the same since any stable distribution shipped systemd as the default init.
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying.
And should teach you to always 'mount -a' when you have made a change to your /etc/fstab.
Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
In most of the cases I have seen this, it is when someone wrote a service unit file without even bothering to read systemd.service(5) and didn't put a Ty
Re: (Score:2)
Here we go again with all the insinuations and accusations. The /etc/fstab was correct with the old init. It was incorrect with systemd. Therefore no amount of mount -a would have helped.
"So, you were relying on bugs to boot your systems?"
Have you stopped beating your mother when she tells you to come out of your basement?
Re: I have no problem with systemd (Score:2)
Well, I have never seen this myself, or seen valid bug report about. Yes, if your fstab entry was correct and that caused systemd to not boot, you should file a bug report.
However, I have also seen soooo many invalid complaints about systemd where the systemd beaviour was correct but other implementations were wrong (conflicted with the sgstem documentation).
systemd's approach is to boot correctly, or if a required resource is not available to not boot into a partial state.
I have seen enough failure modes
Re: (Score:2)
If you think your feedback was constructive, I suggest you re-read it.
Re: (Score:2)
Did you upgrade Ubuntu and find out that /var/spool/mail is a symlink to /var/mail and you can't mount to a symlink in fstab?
Re: (Score:3)
Here's a few. It has no concept of imperative (Just do what I said), or best effort (everything must be perfect or it won't even try to continue). It hard codes things that should be configurable or external. For example, it has it's own idea of what makes a device ready for a filesystem to mount and it can't be told otherwise.
All of that is why soft RAID must be assembled in the initrd before systemd has a chance to screw it up. Otherwise, there is simply no way to tell systemd to complete the boot process
Re: (Score:2)
And once again a systemd opponent proves to be an idiot or a liar. Handling a degraded array and making it bootable has always been the job of the initramfs. See this Debian bug dealing with this issue [debian.org], for example, where the maintainer himself admits so.
Re: (Score:2)
Funny thing is, you were so desperate to deny the systemd bug that you pulled up the wrong issue entirely.
The initramfs HAS to handle the RAID for the root filesystem, naturally. Non-root RAID is supposed to be handled after transferring control to the actual init.
Same for non-root btrfs.
If there's an idiot or liar in this thread, it isn't me.
Re: (Score:2)
The initramfs has to handle all degraded arrays, otherwise they will be marked inactive, and not mounted. The right place to fix issues with degraded arrays being marked inactive (and thus umountable) is in the initramfs.
Which the Debian maintainer admitted; it was his change in the initramfs scripts that marked the arrays inactive and made them fail to mount.
Again, you are so bound up in your systemd hate that you fail to read.
Re: (Score:3)
I read just fine. The workaround is in initramfs, but that's just because systemd is incapable of handling it. Prior to that, the old sysV init handled it just fine.
Not that when I first tested systemd, it was on a working test dummy with a btrfs. It worked just fine before, including when I degraded btrfs. Then I 'upgraded' to systemd and it wouldn't boot. It wouldn't just fail to mount the btrfs (non-root), it just dropped to an emergency shell with no remote services running.
Note that at one time, system
Re: (Score:2)
While I do have concerns about systemd, most dependency schemes have a way for a component to declare itself a prereq to an unwitting third party component. It's a valuable cabability in general when trying to enhance behaviors of existing systems without modifying components needlessly.
Re: (Score:2)
I would be interested in knowing what one or more of those are.
Re: (Score:2)
For example, Debian's SysV init scripts:
https://wiki.debian.org/LSBIni... [debian.org]
X-Start-Before: boot_facility_1 [boot_facility_2...]
X-Stop-After: boot_facility_1 [boot_facility_2...]
provide reverse dependencies, that appear as if the listed facilities had should-start and should-stop on the package with these headers.
Re: (Score:2)
I'll grant the similarity, but at least the Debian scripts don't create hard dependencies. The boot won't stop as a result. That system might refuse to implement a new configuration if it detects that the advisory dependency cannot be met, but end of the day, the links in /etc/rcN.d will be control the boot and if one fails, it will move on.
The X- prefix provides some indication of knowledge that it's a dirty hack, but it is somewhat less problematic given the small number of init.d scripts all kept in one
Re: (Score:2)
There's many hours of reading the Debian CTTE and bug archives about the system init discussion if you have a bit of time and are that interested.
A short version, which is mostly still applicable and accurate for the large part from the past 2 years, is the Debian debate wiki pages with the arguments for and against various init systems to switch to. It's notable that *no-one* wanted to use sysvinit moving into Jessie, and the votes for upstart were heavily partisan being current and ex-canonical employee