Hi Russ, Am 02.06.2013 18:59, schrieb Russ Allbery: > For example, here's the complete systemd file for rsyncd: > > [Unit] > Description=fast remote file copy program daemon > ConditionPathExists=/etc/rsyncd.conf > > [Service] > ExecStart=/usr/bin/rsync --daemon --no-detach > > [Install] > WantedBy=multi-user.target > > There's really no reason to have something like an /etc/default setting > for that, the way there is for the rsyncd init script. You can just edit > that directly (well, it's systemd, so you have to copy it into /etc and > make a new version and then won't know if anything about the default > changes -- a truly awful design, but that's another argument). You do not necessarily have to copy the whole file. You can override/amend the .service file by using a foo.service.d/*.conf snippet. Say you just want to change the ExecStart line, you can do the following: echo "ExecStart=/usr/bin/rsync --daemon --my-funky-param" > /etc/systemd/system/rsync.service.d/my-override.conf This mechanism is not yet in v44, but a newer version of systemd will be uploaded to unstable soonish having this feature. As for noticing upstream default changes: There is a tool called systemd-delta, which can notify you about such differences. That all said, I think one has to treat .service files more like application ressource files. Having to change them should be the exception rather then the norm. E.g., I see the need being able to modify /etc/rsyslog.conf, but /etc/init.d/rsyslog (and therefore rsyslog.service) not so much. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature