In bug #477714, it seems that logging for openntpd has been switched from the standard syslog mechanism to running the daemon in the foreground with stderr expressly directed to a log file. For people with a syslog-ng configuration directing ntpd output to a specific log file, this results in broken logging and logs not appearing where they are expected. It also hard codes the log location/name in the init script with no mechanism to place it someplace else. There is no way to rotate the log without restarting ntpd, which seems undesirable. For that matter, as opposed to the previous configuration, where logrotate would automatically take care of the messages file in a typical deployment, this implementation results in an endlessly growing file that is never rotated without some local customization. Logging with -d generates considerably more noise in the logs than the standard syslog output. Based on the mentioned bug, it seems this was done to try and resolve some issue with ntpd delaying boot? I can't say I've ever seen that problem myself, but if it needs to be fixed, I believe it would be preferable to do so without kludging logging. Running in the foreground with debug logging rather than using standard syslog is broken, potentially impacts existing deployments, and results in a reduced potential logging feature set. Reproducible: Always Steps to Reproduce: Update to openntpd-20080406-r4 Actual Results: Logs show up in /var/log/ntpd.log and are not rotated. Expected Results: Logs show up where syslog is configured to put them and rotated per local policy.
Oh, yeah, I forgot to add a logrotate file, that was on my todo list, but I must have overlook it.
Presumably if you add a logrotate file with the existing configuration, you're going to have to restart ntpd to rotate the log? That seems less than desirable. It also does not resolve the issue of people who are using syslog to redirect output to some other log file of their choice, or for that matter transferring it over the network to a central logging server. It seems a poor choice to disable a standardized logging mechanism in favor of an ad hoc stderr redirection. At least, it seems there should be a choice between the standard logging mechanism and this ad hoc mechanism? I still don't really see the benefit of bypassing the built-in logging, but that would allow someone to do so while allowing others to continue to enjoy the feature set and flexibility of syslog. Thanks...
Stuff under /etc is config protected, so if you want the old behavior just do delete the updates of /etc/{conf,init}.d/ntpd, or comment out lines 8-12 in /etc/init.d/ntpd and delete future updates. As long as the delaying of the boot is not fixed, I prefer using a logrotate file like: $ cat /etc/logrotate.d/ntpd /var/log/ntpd.log { compress rotate 4 daily missingok notifempty postrotate /etc/init.d/ntpd restart endscript }
It doesn't really seem reasonable to have to avoid updating init files or mangle them just to continue to avail of a standardized logging system. In a server environment, reliable and standardized logging is far more important than any minor delay in boot on the off chance your network is broken (which would actually be a problem in need of immediate fixing anyway). Why are we biasing this package toward somebody running it on a notebook or an intermittently connected desktop? Maybe rather than breaking logging people with such an unreliable connection should be directed towards a package like chrony instead? You understand -d isn't just "run in foreground", it is "enable debugging"? It definitely makes the log output much more chatty, who's to say it doesn't make the process less efficient or less accurate due to doing extra work? What kind of delay are we talking about here, anyway? I just temporarily updated my config to point to a server that doesn't exist, and it took all of 15 seconds to start up anyway? And it looks like that delay only occurs if you specify -s, otherwise there is no delay. And if you want ntpd to set the time at startup, perhaps that's because something that starts after it needs accurate time? So in addition to breaking logging, this change would result in a service that needs an accurate time potentially being started before ntpd actually sets the time. This change is very detrimental to an enterprise server environment. At the very least, there should be a simple and easy to use config option to maintain the previous behavior of using syslog and not starting other services until the time is actually set.
Ok, I think you have a point with the two use cases. Can you have a look at openntpd-20080406-r5 in cj-overlay? I added a syslog useflag to allow both cases.
+*openntpd-20080406-r5 (19 Nov 2013) + + 19 Nov 2013; Christoph Junghans <ottxor@gentoo.org> + +files/openntpd.logrotate-20080406-r5, +openntpd-20080406-r5.ebuild: + bring back syslog support (bug #491134) +
Sorry, I got caught up at work and didn't have a chance to get back to this. As far as running openntpd, this new ebuild looks ok. However, the install of the logrotate config file doesn't seem dependent on the syslog use flag? It shouldn't be installed if you're using syslog, or it will restart ntpd unnecessarily and potentially conflict with syslog rotation (as I actually dump logs in /var/log/ntpd.log via syslog). Thanks...
Yes, but I want to have the log from -r4 rotated regardless, once the log is empty, it will never not be rotated again (notifempty). A single restart seems an acceptable price for that. If you have a special syslog rotation file, you can just disable the one coming with openntpd by editing.
So it's ok for somebody who was using syslog, temporarily ran with your debug logging, and then went back to syslog to have an orphaned /var/log/ntpd.1.gz and orphaned empty /var/log/ntpd.log, but not to just have an orphaned /var/log/ntpd.log? You shouldn't install a logrotate config for a log file the package isn't generating. Someone shouldn't have to delete it every time the package is installed or manually edit a file to disable functionality that shouldn't be there. Why don't you just add an ewarn if syslog is enabled and they're updating from the version which forced debug logging telling the user to clean up the orphaned log if they want to?
USE=-syslog can used to prevent the boot delay, in this case there is a ntpd.log. With USE=syslog there is no ntpd.log and logrotate is ok with that (missingok). A problem only appears, if you have non-default syslog.conf, which generates a ntpd.log, but then you might as well have a non-default logrotate file for ntpd.log. You don't even need to delete it, just change ntpd.log to something non-existing.
I get the feeling you don't work on enterprise systems. So basically, somebody has a perfectly well configured system doing exactly what they want. Here comes what appears to be a minor update, and suddenly, without even an ewarning, things are broken. That's just something you want to try to avoid. Even if you conditionally installed the logrotate file based on the syslog use flag, that use flag would still basically control whether or not the time was set before other services get started, which doesn't really make sense. I still say just go back to the way it was to begin with, if you don't have the -s flag set, there's absolutely no delay, and if you do, you are explicitly instructing the software to set the time when it starts *before* backgrounding, so it's ridiculous to complain that it actually tries to do that. Your "fix" for the "boot delay" problem subverts the intention of the -s option. I give up, I'll just fix my boxes to work right and let other people worry about their own.
