3 ms·

My understanding is that default unit files provided by the systemd packages are in /usr/lib where they can be read-only, whereas users can add/override them by

My understanding is that default unit files provided by the systemd packages are in /usr/lib where they can be read-only, whereas users can add/override them by dropping their own unit files into /etc (which is more likely to be read-write). This provides a clean separation between the default configuration and the user configuration. Can you explain why this is a bad thing? A counter-example that comes to mind is when a package upgrade requires manual intervention due to file conflicts in /etc. That's what happens when the packager's default configuration interferes with the user's custom configuration.

axaxs 5y ago
Not going to really argue here, but I have to use mlocate every single time I want to find a unit file, because there's no telling where it would be. Perhaps blame lays on the distro packager, but still, it ends up to a user being strange.
- mgbmtl 5y ago
  For what it's worth: systemctl | grep ssh systemctl cat sshd I find it useful to find the unit name, and 'cat' displays the location.
  - axaxs 5y ago
    thanks, I had no idea that existed.
  - rcxdude 5y ago
    You can also do 'systemctl edit <service>' which will open up an editor in which you can see the existing configuration and edit the overrides in /etc/
RunningDroid 5y ago
> My understanding is that default unit files provided by the systemd packages are in /usr/lib where they can be read-only, whereas users can add/override them by dropping their own unit files into /etc (which is more likely to be read-write). > This provides a clean separation between the default configuration and the user configuration. > Can you explain why this is a bad thing? The normal way to do this is to put the default configuration in /usr/share/.
knorker 5y ago
> Can you explain why this is a bad thing? It's not. That's my point. systemd does ask some good questions. E.g. I think the logfile situation needed a major shake-up in unix. Too many log file formats, in text, often completely unparsable (if you're lucky then a regex will work for 99.99% of log lines, but not all), and all unique. And the same mistakes being made over and over again. E.g. "oh, we don't log timezone", or even "meh, it's up to the user to parse the time with timezone correctly, even though things like 'MST' is not even unique". But did systemd fix that? No. It's just that now I have logs in journalctl AND nginx, AND a bunch of other files. Thanks, standard number 15 that was supposed to unify it all. If you build it, they won't just come. Especially when the implementation is bad. Believe it or not, the above is actually the pro-systemd argument. Now, for what you describe: Yes. Exactly. I'm saying systemd DOESN'T do this. I'm saying this is a large successful part of Unix, that systemd ignored. > A counter-example that comes to mind is when a package upgrade requires manual intervention due to file conflicts in /etc. That's what happens when the packager's default configuration interferes with the user's custom configuration. Is that actually a problem? Maybe I've been spoiled by Debian, but with the combination of the upgrader showing the diff, and `foo.d` config directories, I've never had this problem in about 25 years of running Debian. But I believe you if you say that others have this problem, and believe you when you say it's real. But how exactly is systemd fixing it? It doesn't resolve the conflict, if it works like you say where it's a per-file override. That sounds like breaking the system (usually in subtle ways) instead of hilighting the newly arrived inconsistency. That's just sweeping problems under the rug. It's not enough to say vaguely that "this is different, so probably solves some problem, somehow. And it didn't cause me personally a problem, so fuck everyone else".

axaxs 5y ago

Not going to really argue here, but I have to use mlocate every single time I want to find a unit file, because there's no telling where it would be. Perhaps blame lays on the distro packager, but still, it ends up to a user being strange.

mgbmtl 5y ago
For what it's worth: systemctl | grep ssh systemctl cat sshd I find it useful to find the unit name, and 'cat' displays the location.
- axaxs 5y ago
  thanks, I had no idea that existed.
- rcxdude 5y ago
  You can also do 'systemctl edit <service>' which will open up an editor in which you can see the existing configuration and edit the overrides in /etc/

RunningDroid 5y ago

> My understanding is that default unit files provided by the systemd packages are in /usr/lib where they can be read-only, whereas users can add/override them by dropping their own unit files into /etc (which is more likely to be read-write). > This provides a clean separation between the default configuration and the user configuration. > Can you explain why this is a bad thing? The normal way to do this is to put the default configuration in /usr/share/.

knorker 5y ago

> Can you explain why this is a bad thing? It's not. That's my point. systemd does ask some good questions. E.g. I think the logfile situation needed a major shake-up in unix. Too many log file formats, in text, often completely unparsable (if you're lucky then a regex will work for 99.99% of log lines, but not all), and all unique. And the same mistakes being made over and over again. E.g. "oh, we don't log timezone", or even "meh, it's up to the user to parse the time with timezone correctly, even though things like 'MST' is not even unique". But did systemd fix that? No. It's just that now I have logs in journalctl AND nginx, AND a bunch of other files. Thanks, standard number 15 that was supposed to unify it all. If you build it, they won't just come. Especially when the implementation is bad. Believe it or not, the above is actually the pro-systemd argument. Now, for what you describe: Yes. Exactly. I'm saying systemd DOESN'T do this. I'm saying this is a large successful part of Unix, that systemd ignored. > A counter-example that comes to mind is when a package upgrade requires manual intervention due to file conflicts in /etc. That's what happens when the packager's default configuration interferes with the user's custom configuration. Is that actually a problem? Maybe I've been spoiled by Debian, but with the combination of the upgrader showing the diff, and `foo.d` config directories, I've never had this problem in about 25 years of running Debian. But I believe you if you say that others have this problem, and believe you when you say it's real. But how exactly is systemd fixing it? It doesn't resolve the conflict, if it works like you say where it's a per-file override. That sounds like breaking the system (usually in subtle ways) instead of hilighting the newly arrived inconsistency. That's just sweeping problems under the rug. It's not enough to say vaguely that "this is different, so probably solves some problem, somehow. And it didn't cause me personally a problem, so fuck everyone else".