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 bu
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.
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: (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 bu
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?