On 24/11/2015 17:24, Peter Humphrey wrote: > On Saturday 21 November 2015 09:59:18 I wrote: > >> I think I'll follow Alan's suggestion and head upstream. > > After some discussion with Miroslav Lichvar I've found a chrony.conf that > works for me on my 32-bit 2-core Atom. This is it: > > pool pool.ntp.org iburst > server ntp0.zen.co.uk iburst > server ntp1.zen.co.uk iburst > driftfile /var/lib/chrony/drift > makestep 1.0 3 > allow 192.168.1/24 > mailonchange prh@serv.prhnet 0.5 > rtcfile /var/lib/chrony/rtc > rtconutc > > The installation-default file causes the start-stop-daemon to catch an > unexpected interrupt and report an error, even though the chronyd process > continues to run. > > Any time I run 'strace -ff -o/tmp/chronyd.strace /etc/init.d/chronyd start' > the init process runs normally and I'm left with scores of trace files, none > of which help because the stray interrupt wasn't detected. > > So I'm left with a setup that works for me but leaves what looks (to me) > like a timing problem unsolved. > > I'll report back if I hear any more. >
Ugh, don't you just hate issues like that? The problem with "solutions" like start-stop-daemon is they have to deal with whatever the daemon feels like returning (an infinite number of permutations), so support for daemon is never complete. Regardless of what one thinks of systemd, this is one of the things it set out to deal with. There's only one way to start something, and it behaves one way, making behaviour considerably more predictable. [ A bit of a rant I know, but I'm still smarting from years of rancid and Cisco logins - basically the same kind of problem you are having on a much larger scale...] -- Alan McKinnon alan.mckin...@gmail.com
