Welcome!

The kernel problem with recent updates has been solved. Find the solution here

Important information
-- Required MX 15/16 Repository Changes
-- Information on torrent hosting changes
-- Information on MX15/16 GPG Keys
-- Spectre and Meltdown vulnerabilities

News
-- Introducing our new Website
-- MX Linux on social media: here

Current releases
-- MX-18.3 Point Release release info here
-- Migration Information to MX-18 here
-- antiX-17.4.1 release info here

New users
-- Please read this first, and don't forget to add system and hardware information to posts!
-- Here are the Forum Rules

systemd according to Luke Smith

User avatar
Head_on_a_Stick
Forum Regular
Forum Regular
Posts: 421
Joined: Sun Mar 17, 2019 3:37 pm

Re: systemd according to Luke Smith

#31

Post by Head_on_a_Stick » Sun May 12, 2019 5:37 am

skidoo wrote:
Sun May 12, 2019 3:29 am
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 :happy:
skidoo wrote:
Sun May 12, 2019 3:29 am
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.
skidoo wrote:
Sun May 12, 2019 3:29 am
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.
"Individual appropriation is neither just nor serviceable. All belongs to all." — Peter Kropotkin

User avatar
Richard
Posts: 2738
Joined: Fri Dec 12, 2008 10:31 am

Re: systemd according to Luke Smith

#32

Post by Richard » Sun May 12, 2019 5:41 am

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.
LT: MX18.3: Thinkpad T430: DualCore, Intel i5-3320M, Ivy Bridge; 8GB RAM; 4.19.0-5-amd64; 119GB SSD 840PRO, Intel Graphics-Audio-Network
NB: MX18.1, antiX17.4: AsusTek EeePC 1005HA: Intel DualCore Atom N270, 1GB RAM, 4.19.0-1-686, 150GB HDD

User avatar
Head_on_a_Stick
Forum Regular
Forum Regular
Posts: 421
Joined: Sun Mar 17, 2019 3:37 pm

Re: systemd according to Luke Smith

#33

Post by Head_on_a_Stick » Sun May 12, 2019 6:03 am

AK-47 wrote:
Sat May 11, 2019 11:58 pm
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).
AK-47 wrote:
Sat May 11, 2019 11:58 pm
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.
AK-47 wrote:
Sat May 11, 2019 11:58 pm
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.
Richard wrote:
Sun May 12, 2019 5:41 am
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.
"Individual appropriation is neither just nor serviceable. All belongs to all." — Peter Kropotkin

User avatar
kc1di
Forum Novice
Forum  Novice
Posts: 93
Joined: Sun Sep 28, 2008 8:47 am

Re: systemd according to Luke Smith

#34

Post by kc1di » Sun May 12, 2019 6:39 am

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.

User avatar
Artim
Forum Regular
Forum Regular
Posts: 226
Joined: Sun Apr 01, 2018 9:04 am

Re: systemd according to Luke Smith

#35

Post by Artim » Sun May 12, 2019 8:14 am

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.

User avatar
malspa
Forum Guide
Forum Guide
Posts: 2006
Joined: Thu Jul 13, 2006 7:21 am

Re: systemd according to Luke Smith

#36

Post by malspa » Sun May 12, 2019 8:58 am

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.

User avatar
AK-47
Forum Regular
Forum Regular
Posts: 240
Joined: Sun Mar 24, 2019 7:04 pm

Re: systemd according to Luke Smith

#37

Post by AK-47 » Sun May 12, 2019 9:10 am

Head_on_a_Stick wrote:
Sun May 12, 2019 5:37 am
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.
Head_on_a_Stick wrote:
Sun May 12, 2019 6:03 am
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.
Head_on_a_Stick wrote:
Sun May 12, 2019 6:03 am
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.
Head_on_a_Stick wrote:
Sun May 12, 2019 6:03 am
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.
Head_on_a_Stick wrote:
Sun May 12, 2019 6:03 am
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.
Head_on_a_Stick wrote:
Sun May 12, 2019 6:03 am
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.
Head_on_a_Stick wrote:
Sun May 12, 2019 6:03 am
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
Artim wrote:
Sun May 12, 2019 8:14 am
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?
MX Linux 18.3 - Panasonic CF-30 - 3GB RAM - 160GB HDD - Core 2 Duo

User avatar
Head_on_a_Stick
Forum Regular
Forum Regular
Posts: 421
Joined: Sun Mar 17, 2019 3:37 pm

Re: systemd according to Luke Smith

#38

Post by Head_on_a_Stick » Sun May 12, 2019 9:42 am

AK-47 wrote:
Sun May 12, 2019 9:10 am
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.
AK-47 wrote:
Sun May 12, 2019 9:10 am
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.
AK-47 wrote:
Sun May 12, 2019 9:10 am
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$
:happy:

The systemd journal records everything, syslogd doesn't record everything and requires several other logging services to provide full coverage.
AK-47 wrote:
Sun May 12, 2019 9:10 am
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?
AK-47 wrote:
Sun May 12, 2019 9:10 am
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
AK-47 wrote:
Sun May 12, 2019 9:10 am
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
"Individual appropriation is neither just nor serviceable. All belongs to all." — Peter Kropotkin

User avatar
Richard
Posts: 2738
Joined: Fri Dec 12, 2008 10:31 am

Re: systemd according to Luke Smith

#39

Post by Richard » Sun May 12, 2019 11:13 am

@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.
LT: MX18.3: Thinkpad T430: DualCore, Intel i5-3320M, Ivy Bridge; 8GB RAM; 4.19.0-5-amd64; 119GB SSD 840PRO, Intel Graphics-Audio-Network
NB: MX18.1, antiX17.4: AsusTek EeePC 1005HA: Intel DualCore Atom N270, 1GB RAM, 4.19.0-1-686, 150GB HDD

User avatar
Head_on_a_Stick
Forum Regular
Forum Regular
Posts: 421
Joined: Sun Mar 17, 2019 3:37 pm

Re: systemd according to Luke Smith

#40

Post by Head_on_a_Stick » Sun May 12, 2019 11:39 am

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.
"Individual appropriation is neither just nor serviceable. All belongs to all." — Peter Kropotkin

Post Reply

Return to “General”