[SOLVED] Is 2019 Still Too Soon For Intelligent Assessment of SystemD?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Time to jump into a thread about systemd and inevitably make roughly half of everyone on the internet angry.
My company ran into major issues with terrible clock disciple at the hands of systemd-timesyncd when attempting to introduce a few new appliances. Unchecked drift that seeped through the cracks and hosed a good chunk of data. That was fun. That day, the shadowy board of "yes-men" upstairs learned what Patrick Wayne Swayze meant when he said, "Nobody puts ntpd in the corner."
Is their mistake in not properly vetting the new stuff in anyway systemd's fault? Of course not. However, I do like a clock to be trustworthy.
Quality absolutely has to be maintained. More places you go on the internet now are replete with bad language, poor grammar and spelling, childish arguments and attention-seeking. Other communities, even in the Linux world, have had one or two forum members who desperately battled over time to keep the quality up, but as soon as they left, their absence was very noticeable and the community[ies] turned into a playgroup.
Fortunately bass is just one of many forum members here who do their utmost to keep the level of debate, thought, advice and English, high. It's not hyperbole when I say that the Slackware LQ forum is one of the last bastions of quality advice and debate that I know on the internet and that's because of the consistent efforts of such members.
My I used systemd briefly on Arch and for rather longer on Debian. One of my LFS builds was the systemd version, because I wanted to say I had done it. But I still prefer not to use it.
I did like the fast boot, not so important now, but it was on some of my older machines. I liked the .ini style configuration files, which I found easier to write than shell scripts. In a way, those files are not unlike the "name=value" files that are part of most sysvinit systems nowadays, with the names being script variables for the sysadmin to set. This is a kind of silent admission that the hand-editing of shell scripts on modern systems is becoming impractical for most of us; they are just too complicated.
But I hate the binary journal, and I do not like the underlying complexity of the way systemd works. Above all, I am deeply unhappy about the way it seems to put out tentacles into more and more parts of the OS. Linux has never been a fully integrated system like OSX or BSD. It used to be a modular system, and I like it that way.
dmesg does not provide everything you see while booting. It does provide most of it, but there have been things I've searched for (I saw something specific come up during booting and then went to look for it in the dmesg output and it didn't exist).
That's because at a certain point it hands over to syslog. Whatever was missing from the output of dmesg will be in /var/log/messages provided that your /etc/rc.d/rc.syslog file is executable.
Just a heads up: Slackware comes with a default cron job which rotates the logs generated by syslog every day at 4:40am.
This is a kind of silent admission that the hand-editing of shell scripts on modern systems is becoming impractical for most of us; they are just too complicated.
That the scripting language that is used to start the system up is the exact same language and syntax that the user uses on the command line has always struck me as genius. As the presenter of that talk said -- though I don't think it's an original quote: I've heard Brian Kernighan use it before -- "UNIX is simple; brutally so." The problem is that because shell script is so powerful, people over engineered the startup scripts. What do I mean by that? Take a look at the first bits of rc.S on slackware:
Code:
# Mount sysfs next, if the kernel supports it:
if [ -d /sys ]; then
if grep -wq sysfs /proc/filesystems ; then
if ! grep -wq sysfs /proc/mounts ; then
/sbin/mount -v sysfs /sys -n -t sysfs
fi
fi
fi
why not just:
Code:
/sbin/mount -v sysfs /sys -n -t sysfs
It's not a particularly good example, but it sort of makes the point. Do we really need all those 'if's checking on stuff that we damn well know will be true?
Similarly why have hundreds of lines of rc.inet1 when what it essentially boils down to is running a couple of 'ifconfig's and a 'route' command.
The system startup scripts were intended to be brutally simple, and that's been forgotten over the years.
So when systemd proponents point at rc scripts and say "ewwww, look how complicated this mess is", that was never the intention for them. People just got carried away.
As for systemd. My thoughts are inline with the first paragraph of what Jeebizz posted
Is 2019 Still Too Soon For Intelligent Assessment of Vim and Emacs?
In my small handful of use-cases, systemd doesn't really give me any benefit over sysvinit or rc scripts, but it did have a bug in how it handles LUKS and mdraid that made my home server fail to boot more often than it booted successfully. The strange thing is that when it would drop to shell, just exiting the shell without entering any commands would allow it to finish booting. Eventually I changed the configuration to just restart on fail instead of dropping to shell and shortened the timers, but it still took forever to boot most days since it only had a 1 in 5 chance of working on each boot. Others had this bug as well, and it went unsolved for over a year before I got tired of waiting 20 minutes for my server to boot. Switched it over to Devuan with sysvinit and haven't had an issue since. I'll probably switch it to Slackware when 15 comes out, or when the franken-apt house of cards I've built finally collapses...
I still use systemd on some ARM SoCs and on spare machines with generic hardware and disk configurations that I don't intend on tinkering with, but only because in some situations it's more hassle to remove/avoid than it is to just deal with it. I doubt I'll be using it on my main machine or server again until it either can't be avoided anymore or if the ratio of features to bugs improves dramatically.
If people like it and want to use it that's fine, I don't think it's right how hard it's being pushed though. It's irritating how often I've seen developers drop support for non-systemd init systems, then when i try using the new version of the software with an unmodified init script from an older version it works perfectly. Why would you drop support and inconvenience users like that when it still worked and dropping the support took more effort than keeping it?
Beyond what is mentioned in that post, systemd continues to be problematic. My Ubuntu-using friends still complain about it hanging on system shutdown. At work we use CentOS7 and systemd frequently poses problems our sysadmins have to spend hours or days working around. "Dammit systemd" is something I hear around the office a lot. Since its behavior is hard-coded, you can't just tweak a shell script when it's doing something stupid.
It doesn't help, either, that the dev team refuses to admit that bugs are bugs, and will lock a bug report if too many people comment that something is indeed a problem. Developers should fix bugs, not stick their fingers in their ears and pretend bugs don't exist.
We have seen a steady march of security vulnerabilities reported for systemd, while vulnerabilities in sysvinit are few and far between. That right there should tell you systemd is a non-starter.
It's 2019, and I am more convinced than ever that systemd is a technology to avoid. Every year brings more evidence supporting that conviction.
Thank you, ttk. This is some of the kind of experience I was hoping for.
Time to jump into a thread about systemd and inevitably make roughly half of everyone on the internet angry.
My company ran into major issues with terrible clock disciple at the hands of systemd-timesyncd when attempting to introduce a few new appliances. Unchecked drift that seeped through the cracks and hosed a good chunk of data. That was fun. That day, the shadowy board of "yes-men" upstairs learned what Patrick Wayne Swayze meant when he said, "Nobody puts ntpd in the corner."
Is their mistake in not properly vetting the new stuff in anyway systemd's fault? Of course not. However, I do like a clock to be trustworthy.
Thanks, cowpoke. I was hoping for actual experiences. I've tried some distros that have it but have not worked with them enough to accumulate as much experience as what occurs on an intranet.
My I used systemd briefly on Arch and for rather longer on Debian. One of my LFS builds was the systemd version, because I wanted to say I had done it. But I still prefer not to use it.
I did like the fast boot, not so important now, but it was on some of my older machines. I liked the .ini style configuration files, which I found easier to write than shell scripts. In a way, those files are not unlike the "name=value" files that are part of most sysvinit systems nowadays, with the names being script variables for the sysadmin to set. This is a kind of silent admission that the hand-editing of shell scripts on modern systems is becoming impractical for most of us; they are just too complicated.
But I hate the binary journal, and I do not like the underlying complexity of the way systemd works. Above all, I am deeply unhappy about the way it seems to put out tentacles into more and more parts of the OS. Linux has never been a fully integrated system like OSX or BSD. It used to be a modular system, and I like it that way.
'
There ya go. It seems to me that any restructuring to adopt a parallel structure implies "tentacles". I am very aware of how bad that can be and it was even mentioned in the video as just one well-known characteristic problem, "Dll Hell". However what Bassmadrigal said was essentially true, in that 4 years later I don't know much more than I did then about what benefits might be involved in such a far-reaching alteration. Like you I prefer modular and still see none of the benefits that others, including the speaker in the video I linked, to come anywhere near offsetting the problems and downsides.
@ Bassmadrigal - Since I have many times thanked you publicly and personally for your excellent help over the years, I certainly do not want an impression of any animosity to exist between you and I. Much of what you pointed out in your posts in this thread is very accurate. One, with which I disagree however, is that this thread would be of little or no benefit here in the Slackware sub-forum.
I can't speak for anyone else but I have already learned a few new things and for that I am grateful. I still do not prefer it and still see it's cost as greater than it's benefit(s) which may well have been expected here for good reasons but now I have some specifics from people who have used it more than I and/or work in environments where it is forced on them but have many user experiences to relate.
Quality absolutely has to be maintained. More places you go on the internet now are replete with bad language, poor grammar and spelling, childish arguments and attention-seeking. Other communities, even in the Linux world, have had one or two forum members who desperately battled over time to keep the quality up, but as soon as they left, their absence was very noticeable and the community[ies] turned into a playgroup.
Fortunately bass is just one of many forum members here who do their utmost to keep the level of debate, thought, advice and English, high. It's not hyperbole when I say that the Slackware LQ forum is one of the last bastions of quality advice and debate that I know on the internet and that's because of the consistent efforts of such members.
maybe theres couple quality mods in one of the other forums with a sense a humor who could jump in here as necessary to sort things out
my -v comment was intended as clever slackware cli joke, apparently not
these forums are accessed by thousands of people from around the world with varying perspectives about everything, that's what makes and keeps things interesting
Slackware's boot scripts are not "too complicated". That's one of the advantages of linear boot scripts, they are easy to follow and I can understand every line of it. I edit them, remove everything I don't want including condition checks, and it initializes faster than any SystemD based distro I've ever used.
I don't like SystemD and I don't want to see it in Slackware. I grudgingly use it on other distros... I can work with it, but I practically have to sabotage it to get it to stop doing things I don't like.
Another thing that royally burns my ass about SystemD... that they don't want to implement localtime properly. I use it anyway, but it cripples NTP adjustments (I just use ntpdate manually if I want to correct anyway, though) and daylight savings time changes. I'm not switching my other OSes to UTC just because Poettering has decided localtime shouldn't exist.
Also, that SystemD does things it has no business doing, has resulted in non-booting systems for a lot of people. For example, forcing the use of a random number generator. Sure, it's the CPU's logic at fault in advertising a feature that doesn't work, but the point is that SystemD shouldn't have been going there in the first place.
As for binary logs, they can go ride the baloney pony... I disable the utterly ridiculous journals and use syslogd.
systemD goes against the simplicity of the UNIX philosophy, and i am glad there are some distros refusing to include systemD in to their distros
systemD is too much of a single point of failure, and is like an Achilles heel, which will either be used to break and crash a running Linux, or to root and control it, i dont trust systemD
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.