systemd according to Luke Smith

[Head_on_a_Stick]

If you can cite URLs for one or more known-broken "guides" within the wiki pages (perhaps well-intended, but now outdated?), I will followup by removing them or at least editing and placing warning::outdated disclaimers.

Specifically: the advice for pinning systemd to -1 will break most desktops completely because they all depend on a working login session, which is provided by systemd-logind and this requires the systemd package.

Links:

http://without-systemd.org/wiki/index.p ... ge_Systemd

http://without-systemd.org/wiki/index.p ... variant.29

And the steps listed on the Debian buster page will result in a desktop with no access to input devices, thus forcing a hard shutdown that may corrupt the filesystem:

http://without-systemd.org/wiki/index.p ... stallation

Thanks in advance for correcting those pages, they've been bugging me for a while now

we must now distrust anything posted by Head_On_A_Stick, eh?

Absolutely.

I would always advise people to only ever trust one person: themselves.

still awaiting cleanup of your reduntantly posted misinformation here: http://forum.mxlinux.org/viewtopic.php? ... bunsenlabs

Ah, thanks for reminding me, I forgot about that.

That was rather embarrassing for me, I haven't been involved in BunsenLabs for quite a while now and my memory clearly isn't what it used to be.

[Richard]

Oops. UUID of the swap partition has changed. Fullstop.
^---- arguably the correct behavior on a server, but painful (and ridiculously, infuriatingly opaque) when a casual user encounters inability to boot on a desktop PC

I filed a bug on this at systemd in early 2014, when my Manjaro hung up after installing a second distro and the stated instructions failed.
They said it was user error but no clue as to why.

[Head_on_a_Stick]

I think the point is that the idea of binary logs in this position is retarded at best.

The binary format allows messages from such sources as ATA SMART blobs, SCSI sense data, coredumps & firmware dumps to be included directly (which is not possible with syslogd) and also makes direct export in, for example, JSON format possible.

The journal data is also authenticated, which makes undetected manipulation impossible (unlike with syslogd).

makes log file corruption much more difficult to recover from

If the journal entry is corrupted then it is rotated out and stored, the functionality of the logging mechanism is not compromised further.

If you really want to save space, compress the logs upon rotation (points to syslogd).

The rotation that occurs under syslogd is time-based whereas the systemd journal can be configured to limit disk usage to specific amounts.

There are many problems with syslogd and the systemd journal was designed to overcome the limitations, here is an explanation for those who are interested:

https://docs.google.com/document/pub?id ... UEHIX3MSTs

And anyway on my Debian systems the journal and syslogd both run together so either can be used.

Oops. UUID of the swap partition has changed. Fullstop.
^---- arguably the correct behavior on a server, but painful (and ridiculously, infuriatingly opaque) when a casual user encounters inability to boot on a desktop PC

I filed a bug on this at systemd in early 2014, when my Manjaro hung up after installing a second distro and the stated instructions failed.
They said it was user error but no clue as to why.

There is no "fullstop", the boot continues after a 90 second delay. Nice FUD attempt though, well done.

I think it is correct for the init system to alert the user to failed mountpoints and the fix is to edit /etc/fstab with the correct swap UUID.

[kc1di]

One thing we miss here is the average op doesn't really care if it is SysV or systemd as long as the machine boots and works for what he/she has to accomplish. I have no hate for systemd, Just stating the fact that it was forced upon folks in many distros and is more complicated for the average person to understand, not because it's of itself more complicated but because it not the way it was always done. One of the wonderful things about linux has always been choice. MX gives that choice right not something Debian and other distro do not do easily when it comes to boot systems. Which ever one you like use it and be glad you have a choice.

[Artim]

Yup. First it was PulseAudio foisted on everyone, now systemd. I wonder what's next. All these big new "improvements" that take away the users' choice seem to be multiplying in Linux. Mine works fine now (I use Linux Lite on the laptop, and MX with sysinit on the desktop), but when they were first forced on me they were buggy and resource-hungry pains in the arse. And both are becoming impossible for most users to avoid. Nothing was broken to begin with before these monsters arrived, so why was it "fixed?" Because devs of certain DEs and apps insisted on making it necessary.

[malspa]

Linux is still all about choice, isn't it? Nothing is being "forced on" anyone. I've chosen to use Linux, and I could choose to use something else instead. And it's clear that not everyone agrees that systemd is as awful as some make it out to be.

[AK-47]

I would always advise people to only ever trust one person: themselves.

So presumably then you don't run MX Linux or antiX Linux, but rather a custom hand-crafted OS on custom hand-crafted hardware with custom hand-crafted components such as a custom hand-crafted CPU, that you made from beach sand.

The binary format allows messages from such sources as ATA SMART blobs, SCSI sense data, coredumps & firmware dumps to be included directly (which is not possible with syslogd) and also makes direct export in, for example, JSON format possible.

Although a log is meant to be a diagnostic tool, not the diagnosis itself. I don't see why a log should be in a binary format unless there's primarily binary data associated with it.

The journal data is also authenticated, which makes undetected manipulation impossible (unlike with syslogd).

I admit that is a bit of a problem, where processes can claim to be another program. However that doesn't mean the journal is immune, if you're in root you can just write some gibberish to the log file and corrupt it. No different to good ol' syslogd.

If the journal entry is corrupted then it is rotated out and stored, the functionality of the logging mechanism is not compromised further.

I didn't say logging would be compromised, only it would be harder to get a glimpse of existing log entries. Although having thought about this a bit further I'll gladly retract my statements about the binary logging format, since it is possible to have a binary log format that's quite resistant to corruption (eg. one which is ammend-only and doesn't try to be a database with indices etc), and in fact I can see a benefit to it in some ways.

The rotation that occurs under syslogd is time-based whereas the systemd journal can be configured to limit disk usage to specific amounts.

It is possible to set this up with a shell script that deletes old archives, although I agree there should be an easier way to do it with logrotate.

There are many problems with syslogd and the systemd journal was designed to overcome the limitations, here is an explanation for those who are interested:

https://docs.google.com/document/pub?id ... UEHIX3MSTs

And anyway on my Debian systems the journal and syslogd both run together so either can be used.

Fantastic, now there are two entirely different logging systems to look at when something goes wrong. Credit where credit is due though, I can see why they would want to make these design decisions, although it appears overengineered (eg. totally random UUIDs for log entries). They like to throw around the "syslogs are not indexed" argument a bit, but I don't see why this is even necessary. It hasn't been necessary for the last 30 years and is probably not going to be necessary in the future. They are log files, after all, and not databases. If your logs become so large that they can't be managed without the log system doing the indexing, perhaps you should read them.

There is no "fullstop", the boot continues after a 90 second delay. Nice FUD attempt though, well done.

Which is still a waste of 90 seconds. It's not FUD, it's a genuine issue that a genuine user faced, reported, and got told to get stuffed.
The developers' attitudes are a bit concerning too. Here's an example of where a systemd developer tried to make the developer of tmux add systemd-specific code to their program: https://github.com/tmux/tmux/issues/428

Yup. First it was PulseAudio foisted on everyone, now systemd. I wonder what's next.

Pardon my ignorance, but what was wrong with PulseAudio? Was there something that was better than PulseAudio that was in use before?

[Head_on_a_Stick]

So presumably then you don't run MX Linux or antiX Linux

No, I'm testing Debian buster at the moment but my main operating system is OpenBSD, which doesn't include systemd at all (but can run the GNOME desktop, interestingly).

I don't really like pre-configured distributions, I prefer a tabula rasa which I can configure myself.

if you're in root you can just write some gibberish to the log file and corrupt it.

My point was that it is not possible to tamper with the systemd journal without alerting the administrator.

Anybody who manages to compromise a system will want to doctor the logs to conceal their malfeasance — this is possible with syslogd but not possible with the journal, which is a major advantage of the binary format.

Fantastic, now there are two entirely different logging systems to look at when something goes wrong.

Not on my system:

Code: Select all

shinken:~$ systemctl is-enabled rsyslog
disabled
shinken:~1$

The systemd journal records everything, syslogd doesn't record everything and requires several other logging services to provide full coverage.

They like to throw around the "syslogs are not indexed" argument a bit, but I don't see why this is even necessary. It hasn't been necessary for the last 30 years and is probably not going to be necessary in the future. They are log files, after all, and not databases. If your logs become so large that they can't be managed without the log system doing the indexing, perhaps you should read them.

The systemd journal collates all the logs and offers an interface by which to filter the results with a variety of methods.

For example, syslogd lacks monotonic or timezone-based timestamps whereas with systemd I can do this:

Code: Select all

shinken:~$ journalctl -u systemd-networkd --since "3 hours ago" --no-p
-- Logs begin at Sun 2019-05-12 08:34:31 BST, end at Sun 2019-05-12 14:26:05 BST. --
May 12 12:20:08 shinken systemd-networkd[355]: wlp2s0: Lost carrier
May 12 12:20:08 shinken systemd-networkd[355]: wlp2s0: DHCP lease lost
May 12 12:20:11 shinken systemd-networkd[355]: wlp2s0: Gained carrier
May 12 12:20:11 shinken systemd-networkd[355]: wlp2s0: DHCPv4 address 192.168.1.212/24 via 192.168.1.254
May 12 12:20:11 shinken systemd-networkd[355]: wlp2s0: Configured
shinken:~$

Neat, eh?

Which is still a waste of 90 seconds. It's not FUD, it's a genuine issue that a genuine user faced, reported, and got told to get stuffed.

I was responding to the allegation of a "fullstop" and the suggestion that the system could not boot, which are both nonsense.

And the timeout can be reduced by editing DefaultTimeout{Start,Stop}Sec in /etc/systemd/system.conf

The developers' attitudes are a bit concerning too. Here's an example of where a systemd developer tried to make the developer of tmux add systemd-specific code to their program:

Well I have actually submitted an issue to the systemd team myself I was very pleased with how Lennart dealt with it:

https://github.com/systemd/systemd/issues/6684

[Richard]

@HOAS,

There is no "fullstop", the boot continues after a 90 second delay. Nice FUD attempt though, well done.

I respectfully submit that you might be correct that there is no longer a fullstop; however, I may be wrong about the year, might have been earlier.
The point is, I waited over 5 minutes, applied the suggested commands but systemd remained adamant and unyielding.
I am relieved if that particular gotcha has been corrected. At the time I filed the bug report it had not.
Thanks for your comment.

[Head_on_a_Stick]

Sorry Richard, my FUD accusation was directed at skidoo rather than your good self, I should have made that more clear.

And yes, the default timeout for a swap failure is now 90 seconds.