[syslog-ng] [Bug 126] [systemd] Add installation of systemd unit file via build-sys
bugzilla at bugzilla.balabit.com
bugzilla at bugzilla.balabit.com
Sun Jun 26 17:02:43 CEST 2011
https://bugzilla.balabit.com/show_bug.cgi?id=126
--- Comment #5 from Dave Reisner <dreisner at 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.
More information about the syslog-ng
mailing list