Gentoo Archives: gentoo-dev

From: "Paul B. Henson" <henson@×××.org>
To: Christoph Junghans <ottxor@g.o>, gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] logging in openntpd 20080406-r3+
Date: Sun, 01 Dec 2013 20:23:59
1 On Sun, Dec 01, 2013 at 09:59:37AM -0700, Christoph Junghans wrote:
2 > > back to the original mechanism where openntpd runs normally as a daemon
3 > > and logs to syslog
4 > This is exactly what the syslog use flag in openntpd-20080406-r5 does.
5 > (And syslog is enabled by default in most profiles.)
7 The syslog use flag is a bit of a kludge, it makes the ebuild delete a
8 hardcoded chunk of the init script when it installs it, plus the
9 logrotate file is still installed unconditionally and could conflict
10 with syslog logging, so I don't really think that's a good solution. And
11 syslog isn't enabled in the default profile:
13 virtz # eselect profile list
14 Available profile symlink targets:
15 [1] default/linux/amd64/13.0 *
17 virtz # ACCEPT_KEYWORDS=~amd64 emerge -pv =net-misc/openntpd-20080406-r5
18 Calculating dependencies... done!
19 [ebuild U ] net-misc/openntpd-20080406-r5 [20080406] USE="ssl (-selinux) -syslog%" 12 kB
21 I've seen two reasons for the current kludgy init script:
23 * boot delays
24 * openrc likes pid files
26 Boot delays are avoided by not passing the -s option; and if the -s
27 option causes a delay longer than 15 seconds that's a bug that should be
28 fixed, not kludged around.
30 It's far cleaner to just add pid file support directly to the daemon
31 rather than try to kludge around it in an init script.
33 There's really no valid reason not to just put the ebuild back to its
34 original state, there's no need for a syslog use flag, and running in
35 debug mode with hardcoded stderr logging isn't exactly a reasonably
36 alternate logging mode.
38 > > My offer to debug boot delays in excess of 15 seconds upon supply of a
39 > > reproducible configuration that causes them still stands too...
40 > I hope djc, as the original person concerned, can comment on that.
42 I saw a message from him early in the thread, but haven't seen any
43 reproducible configuration resulting in an extended delay.