3 ms·

Yeah, I dislike systemd but I'm not going to abandon the Debian Foundation over it.

stephenr 11y ago
This is the real point. I have my issues with systemd. For example, I just had an interesting discussion on GH with Varnish packers about changing a daemon arg (in that case, the bind address/port). The way systemd "recommends" to change the arguments passed to a daemon is to write a drop-in file (i.e. /etc/systemd/system/service-name.service.d/something.conf) that overwrites the ExecStart line. To do so, you have to do: [Service] ExecStart= ExecStart=<original ExecStart line with wanted changes> For Varnish, this isn't the end of the world - it only needs a few arguments - but it's still a lot less simple than the pre-systemd "standard" for Debian, which is to use a /etc/defaults/<service> file to allow changing daemon args via variables. This method can be still used (via either EnvironmentFile, or via built-in systemd "Environment=" statements) but the former is specifically mentioned as "not recommended" by Lennart, and the use of Environment= in service files seems very much like a feature that no one is keen to acknowledge or make use of, and it has it's own issues, as the way variables, white space, escaping etc are handled is specific to systemd and not immediately intuitive for someone used to a shell environment. But as you said - those issues, are not enough to give up on the benefits of Debian stable. In theory, all packages in Debian stable that need an init script are supposed to still supply a sysvinit script (I was actually quite surprised by how many packages rely on systemd's ability to load sysvinit scripts and don't ship their own systemd service file) so you could choose to use sysvinit instead of systemd, for now at least. I do appreciate the theoretical goal - you describe how your daemon should be started, and let pid1 handle the specifics of actually starting it - to me that makes it much easier for a lot more people to create reliable daemon packages. I just wish the project wasn't taking such a "everything plus the kitchen sink" approach.
- chris_wot 11y ago
  That's interesting... Does Lennart explain why he doesn't recommend the environment file/directive?
  - stephenr 11y ago
    He explains about EnvironmentFile in https://github.com/systemd/systemd/issues/1082#issuecomment-136452207 https://github.com/systemd/systemd/issues/1082#issuecomment-... The Environment= thing I haven't seen any official comment about its recommended-ness but it has some quirks in syntax so it needs pretty rigorous testing before being used for anything that might have values that need to be quoted/escaped.

This is the real point. I have my issues with systemd. For example, I just had an interesting discussion on GH with Varnish packers about changing a daemon arg (in that case, the bind address/port). The way systemd "recommends" to change the arguments passed to a daemon is to write a drop-in file (i.e. /etc/systemd/system/service-name.service.d/something.conf) that overwrites the ExecStart line. To do so, you have to do: [Service] ExecStart= ExecStart=<original ExecStart line with wanted changes> For Varnish, this isn't the end of the world - it only needs a few arguments - but it's still a lot less simple than the pre-systemd "standard" for Debian, which is to use a /etc/defaults/<service> file to allow changing daemon args via variables. This method can be still used (via either EnvironmentFile, or via built-in systemd "Environment=" statements) but the former is specifically mentioned as "not recommended" by Lennart, and the use of Environment= in service files seems very much like a feature that no one is keen to acknowledge or make use of, and it has it's own issues, as the way variables, white space, escaping etc are handled is specific to systemd and not immediately intuitive for someone used to a shell environment. But as you said - those issues, are not enough to give up on the benefits of Debian stable. In theory, all packages in Debian stable that need an init script are supposed to still supply a sysvinit script (I was actually quite surprised by how many packages rely on systemd's ability to load sysvinit scripts and don't ship their own systemd service file) so you could choose to use sysvinit instead of systemd, for now at least. I do appreciate the theoretical goal - you describe how your daemon should be started, and let pid1 handle the specifics of actually starting it - to me that makes it much easier for a lot more people to create reliable daemon packages. I just wish the project wasn't taking such a "everything plus the kitchen sink" approach.

chris_wot 11y ago
That's interesting... Does Lennart explain why he doesn't recommend the environment file/directive?
- stephenr 11y ago
  He explains about EnvironmentFile in https://github.com/systemd/systemd/issues/1082#issuecomment-136452207 https://github.com/systemd/systemd/issues/1082#issuecomment-... The Environment= thing I haven't seen any official comment about its recommended-ness but it has some quirks in syntax so it needs pretty rigorous testing before being used for anything that might have values that need to be quoted/escaped.