[John Hasler]
Would it be unacceptable for Chrony to step the clock (particularly
back) during boot?
If you are going to do this, it might be a good idea to try to do it
before the syslog collector starts, as most daemons depend on $syslog
and would thus start after the clock is correct.
Happy
On Tue, 3 Aug 2010, John Hasler wrote:
I wrote:
Well, it's a reason. But note that such backward stepping would only
happen when your clock is really screwed up.
brian writes:
It actually used to happen every reboot of my server, which is why I'm
aware of the dovecot problem. When ntp (or
[Edward Allcutt]
You could append +chrony to the $time line in /etc/insserv.conf as a local
fix. You might be able to ship a /etc/insserv.conf.d/chrony that to that
effect but I'm unsure whether that would replace or add to the existing
line. I couldn't find documentation on exactly how the
Jaldhar H. Vyas writes:
I haven't really looked into the new dependency-based stuff so this
might be a naive question but wouldn't X-Starts-After: chrony in
dovecots init script be a better idea?
There is no such thing as far as I know (and I should have written
X-Start-Before: no s). A
Edward Allcutt writes:
You could append +chrony to the $time line in /etc/insserv.conf as a
local fix. You might be able to ship a /etc/insserv.conf.d/chrony that
to that effect but I'm unsure whether that would replace or add to the
existing line.
As Peter says, it would add it to the
Petter Reinholdtsen writes:
If you are going to do this, it might be a good idea to try to do it
before the syslog collector starts, as most daemons depend on $syslog
and would thus start after the clock is correct.
Unfortunately, chrony also wants $syslog.
--
John Hasler
--
To
[John Hasler]
As Peter says, it would add it to the existing line. That wouldn't
really help as hwclock is always present and would satisfy the $time
requirements before chrony started.
Actually, it would help, because all the parts making up $time need to
be satisfied before those depending
Petter Reinholdtsen writes:
Actually, [a chrony file in insserv.conf.d] would help, because all
the parts making up $time need to be satisfied before those depending
on $time will start.
Then that solves my problem (should apply to ntp too) if adding a file to
insserv.conf.d containing
$time
[John Hasler]
No, wait. Chrony depends on things that depend indirectly on $time
(so does ntp, IIRC).
Yes, such change need to be done very carefully and in stages, to
avoid dependency loops. See #542602 for a discussion on the ntp order
relative to $syslog. :)
Happy hacking,
--
Petter
Petter Reinholdtsen writes:
Yes, such change need to be done very carefully and in stages, to
avoid dependency loops. See #542602 for a discussion on the ntp order
relative to $syslog.
After some research I'm tending to think that many (if not most) of the
scripts that require $time,
I wrote:
After some research I'm tending to think that many (if not most) of
the scripts that require $time, shouldn't (or at least should only
require hwclockfirst). I also don't see that we still need two
hwclock scripts.
BTW hwclockfirst.sh and hwclock.sh add about a 1.5 second delay.
--
Would it be unacceptable for Chrony to step the clock (particularly
back) during boot? This would only happen when the clock was at least
30 seconds off but I'm concerned that it might screw some of the daemons
that might already have started. If Chrony can't step the clock it
would have to slew
On Mon, Aug 02, 2010 at 04:24:52PM -0500, John Hasler wrote:
Would it be unacceptable for Chrony to step the clock (particularly
back) during boot? This would only happen when the clock was at least
30 seconds off but I'm concerned that it might screw some of the daemons
that might already
On Mon, Aug 02, 2010 at 04:24:52PM -0500, John Hasler wrote:
Would it be unacceptable for Chrony to step the clock (particularly
back) during boot? This would only happen when the clock was at least
30 seconds off but I'm concerned that it might screw some of the daemons
that might already
brian m. carlson writes:
I don't think it would be okay unless you can either make sure that
dovecot handles this gracefully (and that involves not needing to be
restarted or disconnecting users)...
I don't see how I can do that.
...or change the time only before normal (non-time-related)
On Mon, Aug 02, 2010 at 06:29:21PM -0500, John Hasler wrote:
Well, it's a reason. But note that such backward stepping would only
happen when your clock is really screwed up.
It actually used to happen every reboot of my server, which is why I'm
aware of the dovecot problem. When ntp (or
I wrote:
Well, it's a reason. But note that such backward stepping would only
happen when your clock is really screwed up.
brian writes:
It actually used to happen every reboot of my server, which is why I'm
aware of the dovecot problem. When ntp (or ntpdate, I'm not sure
which) would
John Hasler jhasler at debian.org writes:
I wrote:
Well, it's a reason. But note that such backward stepping would only
happen when your clock is really screwed up.
brian writes:
It actually used to happen every reboot of my server, which is why I'm
aware of the dovecot problem.
18 matches
Mail list logo
