Hi Francesco, On Mon, Feb 25, 2019 at 10:07:28PM +0100, Francesco Poli wrote:
On Mon, 25 Feb 2019 01:22:40 +0100 Vincent Blut wrote:On Sun, Feb 24, 2019 at 08:19:02PM +0100, Francesco Poli wrote: >On Sun, 24 Feb 2019 17:52:46 +0100 Vincent Blut wrote: > >> Please use `ps ax | grep chrony' (or ps -ef). `ps a' only lists >> processes with a tty. > >You are right, sorry: I wanted to simplify the command output, but I >overplayed... ;-) >Anyway, chronyd really fails to start: > > # ps ax | grep chrony > 12035 pts/0 S+ 0:00 grep chrony Interesting. Does `grep -i chrony /var/log/messages' report something suspect?Nothing is added to /var/log/messages when chrony fails to start.
Ok so I think I can reproduce this issue on a Debian Buster i386 virtual machine. However, to double check that I’m facing the same issue as yours, I’d like you to:
- stop the chronyd daemon # service chrony stop - install strace # apt install strace- use the log directive in chrony.conf (“log measurements” alone suffices to trigger the issue)
- execute strace on chronyd # strace -o chronyd_debug.txt chronyd -d -F -1 - don’t forget to attach the chronyd_debug.txt file when you answer ;-)
Hmm, that’s fairly strange. I failed to reproduce this issue on some of my systems. Would you please share your chrony.conf file (privately if you prefer)?I think there's nothing really special in it. I've attached it.
Indeed, nothing unusual here.
There's another important thing that I should mention. Today I have upgraded chrony on another box and the system call filter works fine there (with mailonchange disabled, but with log *enabled*). So I tried to think about the differences between the box where it fails, and the box where it works. The first difference is the architecture: • the box where it fails is i386
Indeed, this is due to a missing syscall needed for this architecture (and probably some other 32-bit plateforms) in the seccomp filter.
• the box where it works is amd64 However, I suspect that chrony level of abstraction is high enough to make this difference immaterial... Or am I wrong?
See Above.
The second difference is the init system and might be more relevant: • the box where it fails runs with sysvinit as PID 1 • the box where it works runs with systemd as PID 1
I think it is safe to exclude PID 1 as the cause of this issue. Thanks for yout time, Vincent
signature.asc
Description: PGP signature
