5 ms·

> systemctl edit foo.service That seems like an unnecessary foot-gun. Needing a special command to safely edit what appears to be an ordinary config file indic

> systemctl edit foo.service That seems like an unnecessary foot-gun. Needing a special command to safely edit what appears to be an ordinary config file indicates some other part of the system is trying to be too clever. In this case, I think it's a combination of filling /etc with symlinks to stuff in /usr, and package managers casually overwriting stuff in /usr without the careful handling that stuff in /etc deserves.

godelski 1y ago
You can always edit the service directly. There's nothing stopping you from doing that, and most people probably do it this way. Doing that would make it just like any other application with a config file. BUT have you ever had configs overwritten by an update? Have you ever found an update to break your config? These are really quite annoying problems to deal with. Having the override file basically means you can keep the maintainer's config as your "gold standard" and then edit it without worrying of fucking things up. This is the difference to me: systemctl edit: It is clearly defined what you changed. Your changes will not be overwritten by an update. directly editing config: File may change with update. You won't be notified of said change. If you didn't write down what you're changes were, you need to redo that work and figure it out all over again. The pros outweigh the cons IMO. I had to get myself into the habit of doing `systemctl edit foo` instead of `sudo vim /etc/systemd/system/foo.service`, but that's provided more benefits than the annoyance of building this habit.
- wtallis 1y ago
  I think you missed the point entirely. I'm not complaining at all that there's a way to make override files. I'm pointing out that the need for making override files (even with the affordance of a special command to handle editing them) is itself a symptom of a bad system design and a deeper problem that deserves a broader solution than what systemd offers. I run gentoo on most of my linux machines. I don't have a problem with files in /etc being silently overwritten by the package manager. Gentoo's solution isn't perfect, but at least it gets at the heart of the real problem. I think perhaps systemd should use its clout to demand a sane solution to this problem, instead of just developing their own workaround that requires users to learn another unnecessary custom way to edit a plain text file.
  - ac29 1y ago
    > just developing their own workaround that requires users to learn another unnecessary custom way to edit a plain text file. There's no need to use systemctl edit to make or edit an override file, its just a convenience shortcut
    - wtallis 1y ago
      > There's no need to use systemctl edit to make or edit an override file, its just a convenience shortcut Do you think anyone who's reached this point in the thread has missed out on that? Yes, obviously those steps can be done manually. But that's not what's being recommended here, and it's more steps to learn and remember, and it doesn't really matter whether accomplishing this task requires one extra command or several when it either shouldn't need to be done at all, or should work the same for any config file that needs to be protected, not just systemd service definitions. It's almost like one of the systemd developers looked at visudo and forgot that sudo should probably never be used as an example of the right way to do things.
      - godelski 1y ago
        Are you okay dude? I'm serious. This is obviously not about systemd, so what's up?
        wtallis 1y ago
        > This is obviously not about systemd, so what's up? It absolutely is about systemd. It's a project that's famous for having almost no limits to its scope, and is highly willing to break existing conventions in order to achieve a more sensible overall system architecture. Having a specialized (and relatively undiscoverable) procedure for safely editing config files is the kind of ugly hack I'd expect systemd to be strongly against. As far as I can tell, the hack in systemd's case seems to be motivated entirely by wanting to avoid problems caused by poorly-behaved package managers. It would be entirely in-character for systemd devs to just tell people to fix their package managers, and that would be the better outcome in the long run. So I'm puzzled why any systemd proponent wouldn't regard this status quo as a wart that needs to be on their roadmap to fix properly.
em-bee 1y ago
haven't debian and other systems been doing that long before systemd? i mean system config files that are controlled by the package manager and not supposed to be edited, but overridden by other files which are to be edited?
- godelski 1y ago
  Yes. All systemctl edit does is provide a shortcut. It calls your $EDITOR variable (as you'd expect).
- wtallis 1y ago
  Yeah, it's a problem that's not new with systemd. But that never stops systemd from tackling a problem. It's weird to see that they went with a narrow, ugly-hack kind of workaround. And it's weird to see anyone talk about it like a minor but unavoidable nuisance that newbies need to learn to live with, instead of as a problem in need of a cleaner solution.
egorfine 1y ago
While there is nothing wrong with "systemctl edit" and it's a nice addition, one should bear in mind that the main goal of the whole systemd umbrella is to embrace and extinguish. The less you learn to do without systemd the better. This is why systemctl edit is recommended, sudo is being replaced and systemd-resolved is soon to be sort of mandatory.

godelski 1y ago

You can always edit the service directly. There's nothing stopping you from doing that, and most people probably do it this way. Doing that would make it just like any other application with a config file. BUT have you ever had configs overwritten by an update? Have you ever found an update to break your config? These are really quite annoying problems to deal with. Having the override file basically means you can keep the maintainer's config as your "gold standard" and then edit it without worrying of fucking things up. This is the difference to me: systemctl edit: It is clearly defined what you changed. Your changes will not be overwritten by an update. directly editing config: File may change with update. You won't be notified of said change. If you didn't write down what you're changes were, you need to redo that work and figure it out all over again. The pros outweigh the cons IMO. I had to get myself into the habit of doing `systemctl edit foo` instead of `sudo vim /etc/systemd/system/foo.service`, but that's provided more benefits than the annoyance of building this habit.

wtallis 1y ago
I think you missed the point entirely. I'm not complaining at all that there's a way to make override files. I'm pointing out that the need for making override files (even with the affordance of a special command to handle editing them) is itself a symptom of a bad system design and a deeper problem that deserves a broader solution than what systemd offers. I run gentoo on most of my linux machines. I don't have a problem with files in /etc being silently overwritten by the package manager. Gentoo's solution isn't perfect, but at least it gets at the heart of the real problem. I think perhaps systemd should use its clout to demand a sane solution to this problem, instead of just developing their own workaround that requires users to learn another unnecessary custom way to edit a plain text file.
- ac29 1y ago
  > just developing their own workaround that requires users to learn another unnecessary custom way to edit a plain text file. There's no need to use systemctl edit to make or edit an override file, its just a convenience shortcut
  - wtallis 1y ago
    > There's no need to use systemctl edit to make or edit an override file, its just a convenience shortcut Do you think anyone who's reached this point in the thread has missed out on that? Yes, obviously those steps can be done manually. But that's not what's being recommended here, and it's more steps to learn and remember, and it doesn't really matter whether accomplishing this task requires one extra command or several when it either shouldn't need to be done at all, or should work the same for any config file that needs to be protected, not just systemd service definitions. It's almost like one of the systemd developers looked at visudo and forgot that sudo should probably never be used as an example of the right way to do things.
    - godelski 1y ago
      Are you okay dude? I'm serious. This is obviously not about systemd, so what's up?
      - wtallis 1y ago
        > This is obviously not about systemd, so what's up? It absolutely is about systemd. It's a project that's famous for having almost no limits to its scope, and is highly willing to break existing conventions in order to achieve a more sensible overall system architecture. Having a specialized (and relatively undiscoverable) procedure for safely editing config files is the kind of ugly hack I'd expect systemd to be strongly against. As far as I can tell, the hack in systemd's case seems to be motivated entirely by wanting to avoid problems caused by poorly-behaved package managers. It would be entirely in-character for systemd devs to just tell people to fix their package managers, and that would be the better outcome in the long run. So I'm puzzled why any systemd proponent wouldn't regard this status quo as a wart that needs to be on their roadmap to fix properly.

em-bee 1y ago

haven't debian and other systems been doing that long before systemd? i mean system config files that are controlled by the package manager and not supposed to be edited, but overridden by other files which are to be edited?

godelski 1y ago
Yes. All systemctl edit does is provide a shortcut. It calls your $EDITOR variable (as you'd expect).
wtallis 1y ago
Yeah, it's a problem that's not new with systemd. But that never stops systemd from tackling a problem. It's weird to see that they went with a narrow, ugly-hack kind of workaround. And it's weird to see anyone talk about it like a minor but unavoidable nuisance that newbies need to learn to live with, instead of as a problem in need of a cleaner solution.

egorfine 1y ago

While there is nothing wrong with "systemctl edit" and it's a nice addition, one should bear in mind that the main goal of the whole systemd umbrella is to embrace and extinguish. The less you learn to do without systemd the better. This is why systemctl edit is recommended, sudo is being replaced and systemd-resolved is soon to be sort of mandatory.