2 ms·

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

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.
      - godelski 1y ago
        You're not being consistent and you keep slightly updating to using minor things I say that aren't even part of systemd's scope. An alias isn't a hack it's an... alias. You can edit the config directly as well as you can edit an override directly. Overrides aren't even a necessary thing. But all we've done is gone in a circle. So I'm not sure if I'm talking to an llm or if you're not okay. Because you're clearly not reading responses so which is it?
godelski 1y ago
> 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 >> You can always edit the service directly. There's nothing stopping you from doing that, and most people probably do it this way. I'm lost. You're complaining that you'd be happy if you could do the thing I said you could do in my opening sentence as well as my closing? Sorry, but I think it is you who have > I think you missed the point entirely.
- wtallis 1y ago
  > I'm lost. You're complaining that you'd be happy if you could do the thing I said you could do in my opening sentence as well as my closing? Sorry, but I think it is you who have No, please put a little more thought into this. I can't tell if you don't recognize the problem with the status quo, or just can't imagine that the problem is solvable. Your proposed choices are: 1. Learn to use `systemctl edit` to safely edit a certain class of config files 2. Manually take the extra steps of making an override file that you can safely edit with normal file-editing procedures or 3. Directly edit the systemd config files, and have your edits silently reverted at some point in the future by software updates The problem with this situation is that #3 is the simple and obvious way to interact with config files, but it's the wrong way. And even though systemctl will detect when you've edited one of those files and warn you to run `systemctl daemon-reload`, I can't recall ever seeing that warning mention the possibility that you may have edited your config files the unsafe way and that the edits you made are at risk of being reverted. What I'm asking for is an option 4: directly edit the config files, and not need to worry about them being silently overwritten or reverted. I hope you can understand that this is not one of the options you've offered, but that it would provide a superior user experience to any of the other three options. And since I've already named one Linux distro that's solved at least part of this problem, we know that it's not intractable.
  - godelski 1y ago
    #3 happens to config files that aren't part of systemd, so I'm not sure what you're on about. Having an optional override provides a benefit to avoid this common pitfall. You do understand the word "optional", right? Option 4 doesn't exist. There is no system that allows you to edit system config files where you don't risk them being overwritten in an update. Perhaps you're thinking of rc files or user configs like you'd have in vim or something? But those are equivalent to overrides in this case where editing the main config would be equivalent to editing the vim default configs. I think that's where you're confused? Thinking there's only a single config? But we're working with system level applications, not user. So the override is what I'm guessing you're thinking a config is. Again, systemctl edit is an alias

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.
    - godelski 1y ago
      You're not being consistent and you keep slightly updating to using minor things I say that aren't even part of systemd's scope. An alias isn't a hack it's an... alias. You can edit the config directly as well as you can edit an override directly. Overrides aren't even a necessary thing. But all we've done is gone in a circle. So I'm not sure if I'm talking to an llm or if you're not okay. Because you're clearly not reading responses so which is it?

godelski 1y ago

> 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 >> You can always edit the service directly. There's nothing stopping you from doing that, and most people probably do it this way. I'm lost. You're complaining that you'd be happy if you could do the thing I said you could do in my opening sentence as well as my closing? Sorry, but I think it is you who have > I think you missed the point entirely.

wtallis 1y ago
> I'm lost. You're complaining that you'd be happy if you could do the thing I said you could do in my opening sentence as well as my closing? Sorry, but I think it is you who have No, please put a little more thought into this. I can't tell if you don't recognize the problem with the status quo, or just can't imagine that the problem is solvable. Your proposed choices are: 1. Learn to use `systemctl edit` to safely edit a certain class of config files 2. Manually take the extra steps of making an override file that you can safely edit with normal file-editing procedures or 3. Directly edit the systemd config files, and have your edits silently reverted at some point in the future by software updates The problem with this situation is that #3 is the simple and obvious way to interact with config files, but it's the wrong way. And even though systemctl will detect when you've edited one of those files and warn you to run `systemctl daemon-reload`, I can't recall ever seeing that warning mention the possibility that you may have edited your config files the unsafe way and that the edits you made are at risk of being reverted. What I'm asking for is an option 4: directly edit the config files, and not need to worry about them being silently overwritten or reverted. I hope you can understand that this is not one of the options you've offered, but that it would provide a superior user experience to any of the other three options. And since I've already named one Linux distro that's solved at least part of this problem, we know that it's not intractable.
- godelski 1y ago
  #3 happens to config files that aren't part of systemd, so I'm not sure what you're on about. Having an optional override provides a benefit to avoid this common pitfall. You do understand the word "optional", right? Option 4 doesn't exist. There is no system that allows you to edit system config files where you don't risk them being overwritten in an update. Perhaps you're thinking of rc files or user configs like you'd have in vim or something? But those are equivalent to overrides in this case where editing the main config would be equivalent to editing the vim default configs. I think that's where you're confused? Thinking there's only a single config? But we're working with system level applications, not user. So the override is what I'm guessing you're thinking a config is. Again, systemctl edit is an alias