https://bugzilla.balabit.com/show_bug.cgi?id=126 --- Comment #5 from Dave Reisner <dreisner@archlinux.org> 2011-06-26 17:02:44 --- (In reply to comment #4)
hmm... I was wondering what the proper default for this option would be. Certainly for packages unit files would need to go to /lib/systemd/system, but when the admin is compiling his own package, the proper place would rather be /etc/systemd/system, ain't that right?
Do packages specify this option explicitly on the configure command line, or should configure prefer the package location over the user location?
Right. For distribution, /lib/systemd/system should be used, allowing /etc/systemd/system to be used as an override, or for configuration by a system administrator. For example, I have a bunch of my own units that I keep in /etc/systemd/system (that are specific to my own machine). In the arch ecosystem, systemd is not our default init, so any package that provides a service file will be ./configure'd with this option defined as /lib/systemd/system. If you're configuring and compiling outside the confines of a package manager, I'd say /etc/systemd is probably the right place to drop the service file. You wouldn't want this suddenly overwritten by a package providing the same service file.
I guess in the case of the ExecReload it does seem slightly different from Lighttpd because the same process continues. That said, systemd upstream had the same response to the ExecReload in rsyslog (which has similar behavior to syslog-ng on HUP) and asked for it to be removed, which it subsequently was.
syslog-ng 3.4 does have an option to initiate reload with a unix domain socket, but that still isn't synchronous (yet).
How should a user initiate HUP based reloads using systemd then?
The purist would tell you to avoid the reload entirely and instead do a full restart. A high volume logging server is probably not going to be happy about doing a restart instead of a simple reload.
I understand that this is not a perfect solution, but was good enough for quite some time. I wouldn't want to add synchronous reloads to syslog-ng 3.2 (which is not where development happens), though it might be viable for 3.4
So for the interim I'd leave ExecReload and change it to the alternative when we get there.
What do you think?
So I guess, personally, I agree. Leave it in, and let administrators decide whether to use it or not. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.