News for hackers. Stuff that matters.
Re:Troubleshooting Systemd with SystemTap by znpy on Thursday April 30, 2020 @08:23AM (#23030065)
I have. My machines boot reliabily, my unit files work almost unmodified across my centos machines and my Ubuntu laptops.

I no longer have to learn a three-dimensional grid of init systems (init system, distro, distro release).

If this isn't a positive experience...

Systemd requires a small initial study effort in order to be understood.

If you're unwilling to do that kind of things (is: reading the fine manual), you might as well go buy a macbook.

Re:Troubleshooting Systemd with SystemTap by pmlnr on Thursday April 30, 2020 @08:34AM (#23030121)
Story from yesterday: I foolishly modified fstab, like I did for over a decade, to swap a mountpoint from a local drive to NFS. What happened: `mount -a` ran fine. No errors. Except... the mountpoint was empty, there was no match in `mount` output to the line.

After poking the internet:

    After altering fstab one should either run systemctl 
    daemon-reload (this makes systemd to reparse /etc/fstab 
    and pick up the changes) or reboot[^1].
So, the summary with systemd: it will break something for everyone sooner or later. It hopefully won't be something you can't fix, but it will make you very angry and in immediate need of a tea break.

BTW, this is not the first one for me, but certainly one of the most frustrating ones, and not because of the behaviour: because of the lack of error messages on stderr or at least in syslog. The messages in ~~syslog~~ journald were casual.

[^1]: https://unix.stackexchange.com/questions/169909/systemd-keep...

Re:Troubleshooting Systemd with SystemTap by znpy on Thursday April 30, 2020 @10:37AM (#23031248)
Actually it's been like that for a long time, and for a good reason.

/etc/fstab is parsed by systemd and converted int .mount unit files, so that they can be mounted when a) asked for it (auto/noauto) and b) as soon as possible.

think of the _netdev flag: it signals systemd that a mountpoint is network-based, and thus it will attempt to mount it only after the networking target (instead of waiting for it to timeout at boot time, fail , and possibly letting processes start reading and writing from/to an empty directory).

Running daemon-reload is generally system(d)-wide though: whenever systemd configuration is altered (think adding/removing/updating an unit file) you should let systemd know about that by running systemd daemon-reload (think of apachectl reload).

Re:Troubleshooting Systemd with SystemTap by mcdee on Thursday April 30, 2020 @01:52PM (#23033780)
It's non-obvious, though. Change something in /etc/systemd you can expect to have to tell systemd about it. Outside of that directory, there's no indicator you should do so.

"Long time" is also relative. I've been updating /etc/fstab directly for over 25 years.

Re:Troubleshooting Systemd with SystemTap by pmlnr on Thursday April 30, 2020 @12:12PM (#23032485)
> and for a good reason

Yeah... there's always a "good reason" with systemd, isn't there?

Still doesn't account for the lack of error message.

Re:Troubleshooting Systemd with SystemTap by qplex on Thursday April 30, 2020 @02:19PM (#23034172)
It's kind of funny how systemd breaks often when old farts (like us) tinker with something in a way we shouldnt.
Re:Troubleshooting Systemd with SystemTap by michaelmrose on Thursday April 30, 2020 @08:35PM (#23037950)
Why doesn't it reparse fstab before executing mount commands?
Re:Troubleshooting Systemd with SystemTap by znpy on Friday May 01, 2020 @05:37AM (#23040471)
the mount command is not part of systemd
Re:Troubleshooting Systemd with SystemTap by michaelmrose on Saturday May 02, 2020 @04:03PM (#23054479)
mount the command DOES read /etc/fstab I believe the discussion was a systemd mount unit