[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