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.) |
6 |
|
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: |
12 |
|
13 |
virtz # eselect profile list |
14 |
Available profile symlink targets: |
15 |
[1] default/linux/amd64/13.0 * |
16 |
|
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 |
20 |
|
21 |
I've seen two reasons for the current kludgy init script: |
22 |
|
23 |
* boot delays |
24 |
* openrc likes pid files |
25 |
|
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. |
29 |
|
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. |
32 |
|
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. |
37 |
|
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. |
41 |
|
42 |
I saw a message from him early in the thread, but haven't seen any |
43 |
reproducible configuration resulting in an extended delay. |