On Thu, Dec 5, 2013 at 6:02 AM, Paul B. Henson wrote:
> Bug 493358 has a patch to fix this. With the patch, openntpd will
> background within approximately 15 seconds plus however long your
> resolver is configured to take to timeout a dns query.
>
> Perhaps now we can just ditch the syslog use fl
On Fri, Nov 22, 2013 at 03:44:42PM -0800, Paul B. Henson wrote:
> I've tested a variety of scenarios, from the network interface being
> down/unplugged, providing invalid NTP servers, etc., and I haven't
> seen a delay longer than 15 seconds.
I tracked down the failure mode where openntpd will tak
On Sun, Dec 01, 2013 at 11:28:25PM +0100, Michał Górny wrote:
> For current OpenRC -- maybe. For systemd and hopefully future OpenRC
> capable of service supervision, PID file is just useless cruft
> and foreground option is much more fun.
Dunno about the future of openrc, but as far as systemd I
On Sun, Dec 01, 2013 at 02:17:18PM -0800, Paul B. Henson wrote:
> Bug 493082 contains a patch to openntpd adding a pid file option, along
> with an updated ebuild that uses it...
Someone had asked me offlist about using SIGUSR1 instead of SIGINFO for
dumping peer status, and as long as I had my f
Dnia 2013-11-30, o godz. 21:13:58
"Paul B. Henson" napisał(a):
> On Sat, Nov 30, 2013 at 09:14:30AM +0100, Michał Górny wrote:
>
> > You know, usually it's enough to ping upstream. AFAIR there was
> > a similar problem in irqbalance, and they have added plain
> > '--foreground' for us.
>
> I th
On Sat, Nov 30, 2013 at 09:21:32PM -0800, Paul B. Henson wrote:
> and logs to syslog, I'll put together a patch that adds a -p argument to
> optionally create a pid file after daemonizing...
Bug 493082 contains a patch to openntpd adding a pid file option, along
with an updated ebuild that uses i
On Sun, Dec 01, 2013 at 09:59:37AM -0700, Christoph Junghans wrote:
> > back to the original mechanism where openntpd runs normally as a daemon
> > and logs to syslog
> This is exactly what the syslog use flag in openntpd-20080406-r5 does.
> (And syslog is enabled by default in most profiles.)
The
On Sat, Nov 30, 2013 at 04:20:09PM +, Diego Elio Pettenò wrote:
> If you really don't want PID files (and it probably means you have
> never had to deal with medium-scale deployments, but never mind), you
> can make it so that `-p` is an optional parameter, and if not passed
> no pidfile is cr
On Sat, Nov 30, 2013 at 09:14:30AM +0100, Michał Górny wrote:
> You know, usually it's enough to ping upstream. AFAIR there was
> a similar problem in irqbalance, and they have added plain
> '--foreground' for us.
I don't know there really is an upstream for portable openntpd right
now, there's b
On Sat, Nov 30, 2013 at 1:31 PM, Peter Stuge wrote:
> Or maybe yes. :) The condition I refered to is that the system is
> using openrc. Sorry if my weak language skills caused confusion!
>
What I mean is that it would be stupid to have USE=openrc to apply such a
patch. Either the patch is done c
Peter Stuge wrote:
> Diego Elio Pettenò wrote:
> > > Conditionally patching openntpd in the ebuild if a system is using
> > > openrc is certainly the way to go.
> >
> > You mean unconditionally here, right?
>
> No.
Or maybe yes. :) The condition I refered to is that the system is
using openrc. S
Diego Elio Pettenò wrote:
> > Conditionally patching openntpd in the ebuild if a system is using
> > openrc is certainly the way to go.
>
> You mean unconditionally here, right?
No.
> Because pid files should be there, full stop.
With openrc sure but neither want nor need them with service sup
Dnia 2013-11-29, o godz. 17:33:18
"Paul B. Henson" napisał(a):
> On Fri, Nov 29, 2013 at 09:49:03AM +0100, Lars Wendler wrote:
>
> > I think there's some confusion on what the -d option actually does, so
> > let me cite the relevant parts from "man 8 ntpd":
> [...]
> > Now let's discuss if this
On Sat, Nov 30, 2013 at 1:55 AM, Peter Stuge wrote:
> Conditionally patching openntpd in the ebuild if a system is using
> openrc is certainly the way to go.
>
You mean unconditionally here, right? Because pid files should be there,
full stop.
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.
Paul B. Henson wrote:
> If openrc has issues managing services that don't drop pid files, maybe
> that should be looked into, or maybe openntpd could be patched to drop
> a pid file.
Conditionally patching openntpd in the ebuild if a system is using
openrc is certainly the way to go.
> But runni
On Fri, Nov 29, 2013 at 09:49:03AM +0100, Lars Wendler wrote:
> I think there's some confusion on what the -d option actually does, so
> let me cite the relevant parts from "man 8 ntpd":
[...]
> Now let's discuss if this can be considered as "debug mode" or not.
Let me cite the relevant code ;) :
Am Thu, 28 Nov 2013 08:55:56 -0700
schrieb Christoph Junghans :
> 2013/11/28 Rich Freeman :
> > On Wed, Nov 27, 2013 at 10:56 PM, Paul B. Henson
> > wrote:
> >> On Fri, Nov 22, 2013 at 09:36:38PM +0100, Peter Stuge wrote:
> >>> Paul B. Henson wrote:
> >>> > In openntpd ebuilds starting with versi
If you pip stdout/stderr to a file, how does that interact with log rotation?
-A
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On Thu, Nov 28, 2013 at 06:48:30AM -0500, Rich Freeman wrote:
> Having 47 devs agree with you doesn't really accomplish
> much if none of them care to maintain the package in question.
Well, I would kinda hope that if 47 devs told 1 dev they were making a
poor design decision, that 1 dev would re
On Thu, Nov 28, 2013 at 08:55:56AM -0700, Christoph Junghans wrote:
> run openntpd with two different ways of logging, via syslog (like Paul
> wants) and with a separate log file to avoid boot delays (like djc
> wants). We could easily make syslog logging the default, like
My point is that runnin
2013/11/28 Rich Freeman :
> On Wed, Nov 27, 2013 at 10:56 PM, Paul B. Henson wrote:
>> On Fri, Nov 22, 2013 at 09:36:38PM +0100, Peter Stuge wrote:
>>> Paul B. Henson wrote:
>>> > In openntpd ebuilds starting with version 20080406-r3, logging was
>>> > changed
>>> > from using the default standa
On Wed, Nov 27, 2013 at 10:56 PM, Paul B. Henson wrote:
> On Fri, Nov 22, 2013 at 09:36:38PM +0100, Peter Stuge wrote:
>> Paul B. Henson wrote:
>> > In openntpd ebuilds starting with version 20080406-r3, logging was changed
>> > from using the default standard syslog to running the daemon in debu
On Fri, Nov 22, 2013 at 09:36:38PM +0100, Peter Stuge wrote:
> Paul B. Henson wrote:
> > In openntpd ebuilds starting with version 20080406-r3, logging was changed
> > from using the default standard syslog to running the daemon in debug mode,
> > logging to stderr, and having start_stop_daemon ba
> From: Dirkjan Ochtman [mailto:d...@gentoo.org]
> Sent: Friday, November 22, 2013 12:30 PM
>
> - Without -s, it can take a *very* long time to get close to an
> acceptable time error, whereas my initial expectation was that
> "starting my ntpd should fix the time error fairly quickly". But for
> m
Dirkjan Ochtman wrote:
> for my use case, it is not all that important that the time error is
> minimized before resuming the boot process, but I really wanted to
> minimize boot delays.
Most servers really do need accurate time. But your servers, your call.
NTP always takes a long time to adjust
Paul B. Henson wrote:
> In openntpd ebuilds starting with version 20080406-r3, logging was changed
> from using the default standard syslog to running the daemon in debug mode,
> logging to stderr, and having start_stop_daemon background the process
> itself and redirect the output to a log file.
On Fri, Nov 22, 2013 at 9:15 PM, Paul B. Henson wrote:
> I was unable to come to an agreement with the current maintainer of the
> ebuild on this design, and would like some general feedback from the larger
> community of developers on this topic.
Thank you for your explanation of the issues here
In openntpd ebuilds starting with version 20080406-r3, logging was changed
from using the default standard syslog to running the daemon in debug mode,
logging to stderr, and having start_stop_daemon background the process
itself and redirect the output to a log file.
I think this is broken.
Firs
28 matches
Mail list logo
