Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log
Control: tags -1 pending On Thu, Feb 28, 2019 at 11:36:10PM +0100, Francesco Poli wrote: On Thu, 28 Feb 2019 21:11:48 +0100 Vincent Blut wrote: [...] On Wed, Feb 27, 2019 at 10:26:13PM +0100, Francesco Poli wrote: [...] >File chronyd_debug.txt is attached (gzipped). That correspond to what I’m seeing in my tests. Upstream have applied the patch I submitted to fix this so it should find its way in Debian in the next days. [...] That's great news! :-) I really appreciate everything you did to deal with this bug. Thanks for the kind words. :-) Cheers, Vincent signature.asc Description: PGP signature
Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log
On Thu, 28 Feb 2019 21:11:48 +0100 Vincent Blut wrote: [...] > On Wed, Feb 27, 2019 at 10:26:13PM +0100, Francesco Poli wrote: [...] > >File chronyd_debug.txt is attached (gzipped). > > That correspond to what I’m seeing in my tests. Upstream have applied > the patch I submitted to fix this so it should find its way in Debian in > the next days. [...] That's great news! :-) I really appreciate everything you did to deal with this bug. Looking forward to seeing the fixed version uploaded to unstable. Bye and thanks again. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpowmjxmIF6z.pgp Description: PGP signature
Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log
Control: tags -1 - moreinfo Control: found -1 3.0-4+deb9u1 On Wed, Feb 27, 2019 at 10:26:13PM +0100, Francesco Poli wrote: On Wed, 27 Feb 2019 14:05:03 +0100 Vincent Blut wrote: [...] On Mon, Feb 25, 2019 at 10:07:28PM +0100, Francesco Poli wrote: [...] >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 ;-) # strace -o /tmp/chronyd_debug.txt chronyd -d -F -1 2019-02-27T21:11:34Z chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG) 2019-02-27T21:11:34Z Frequency -63.045 +/- 0.023 ppm read from /var/lib/chrony/chrony.drift 2019-02-27T21:11:34Z Loaded seccomp filter Bad system call File chronyd_debug.txt is attached (gzipped). That correspond to what I’m seeing in my tests. Upstream have applied the patch I submitted to fix this so it should find its way in Debian in the next days. Thanks for yout time, Thanks to you, for your helpfulness and patience! You’re welcome! Cheers, Vincent signature.asc Description: PGP signature
Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log
On Wed, 27 Feb 2019 14:05:03 +0100 Vincent Blut wrote: [...] > On Mon, Feb 25, 2019 at 10:07:28PM +0100, Francesco Poli wrote: [...] > >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 ;-) # strace -o /tmp/chronyd_debug.txt chronyd -d -F -1 2019-02-27T21:11:34Z chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG) 2019-02-27T21:11:34Z Frequency -63.045 +/- 0.023 ppm read from /var/lib/chrony/chrony.drift 2019-02-27T21:11:34Z Loaded seccomp filter Bad system call File chronyd_debug.txt is attached (gzipped). [...] > >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. Ah, that's it (maybe). > > > • 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. OK, so I was wrong! ;-) > > >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. Funny that I was completely off-track in the search for the relevant difference... :p > > Thanks for yout time, Thanks to you, for your helpfulness and patience! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE chronyd_debug.txt.gz Description: application/gzip pgpVwiGGV5WSm.pgp Description: PGP signature
Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log
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/0S+ 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
Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log
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/0S+ 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. > > >> Also, the output of `chronyc tracking' would be useful to check > >> chronyd’s status and system time information. > > > >Do you mean, when the daemon is not running? > > Well, no. ;-) Obviously! ;-) > > > > # chronyc tracking > > 506 Cannot talk to daemon > > > >Or when the daemon is running with log disabled? > > Yes, when chronyd is running with the log directive disabled but the > syscall filter enabled. # ps ax | grep chrony 15534 ?S 0:00 /usr/sbin/chronyd -F -1 15535 ?S 0:00 /usr/sbin/chronyd -F -1 15557 pts/1S+ 0:00 grep chrony # chronyc tracking Reference ID: (.z.tld) Stratum : 4 Ref time (UTC) : Mon Feb 25 20:50:10 2019 System time : 0.3 seconds slow of NTP time Last offset : +0.52817 seconds RMS offset : 0.52817 seconds Frequency : 62.991 ppm slow Residual freq : +12.282 ppm Skew: 0.023 ppm Root delay : 0.047111727 seconds Root dispersion : 0.002364162 seconds Update interval : 2.0 seconds Leap status : Normal [...] > >The interesting thing is that chronyd seems to be started by > >"service chrony start" and then seems to die immediately after > >beginning to write some logs: > > > > [again, snip some information] > > 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. 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 • 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? 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 cannot think about other potentially relevant differences, but, of course, feel free to ask, in case you have any idea... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE chrony.conf.gz Description: application/gzip pgpVYLFirsBBY.pgp Description: PGP signature
Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log
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/0S+ 0:00 grep chrony Interesting. Does `grep -i chrony /var/log/messages' report something suspect? Also, the output of `chronyc tracking' would be useful to check chronyd’s status and system time information. Do you mean, when the daemon is not running? Well, no. ;-) # chronyc tracking 506 Cannot talk to daemon Or when the daemon is running with log disabled? Yes, when chronyd is running with the log directive disabled but the syscall filter enabled. [snip valuable information] It seems the daemon is not running and no logs are created or updated. With chronyd not running, this result is indeed expected. The interesting thing is that chronyd seems to be started by "service chrony start" and then seems to die immediately after beginning to write some logs: [again, snip some information] 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)? Cheers, Vincent signature.asc Description: PGP signature
Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log
On Sun, 24 Feb 2019 17:52:46 +0100 Vincent Blut wrote: > On Sun, Feb 24, 2019 at 05:05:58PM +0100, Francesco Poli wrote: > >On Sun, 24 Feb 2019 16:25:19 +0100 Vincent Blut wrote: > > > >[...] > >> On Sun, Feb 24, 2019 at 12:59:21PM +0100, Francesco Poli (wintermute) > >> wrote: > >[...] > >> >Everything seems to be fine, but: > >> > > >> > $ ps a | grep chrony > >> > 10686 pts/1S+ 0:00 grep chrony > >> > > >> >the daemon is not running! > >> > >> Could you please provide the output of `grep -i chrony /var/log/syslog'? > > > >The lines added when doing > > > > # service chrony start > > > >are: > > > > Feb 24 16:53:39 HOST chronyd[11063]: chronyd version 3.4 starting (+CMDMON > > +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 > > -DEBUG) > > Feb 24 16:53:39 HOST chronyd[11063]: Frequency -63.017 +/- 0.053 ppm read > > from /var/lib/chrony/chrony.drift > > Feb 24 16:53:39 HOST chronyd[11063]: Loaded seccomp filter > > > >But, once again, chrony is not running: > > > > # ps a | grep chrony > > 11086 pts/0S+ 0:00 grep chrony > > 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/0S+ 0:00 grep chrony > Also, the output of `chronyc tracking' would be useful to check > chronyd’s status and system time information. Do you mean, when the daemon is not running? # chronyc tracking 506 Cannot talk to daemon Or when the daemon is running with log disabled? Or when the daemon is running with system call filter disabled? [...] > >Needless to say, the logs were written by chronyd, when running with > >the '-F 0' option... > > Ok, so please reenable the syscall filter Done: # grep OPT /etc/default/chrony DAEMON_OPTS="-F 0" DAEMON_OPTS="-F -1" # grep 'mailonchange\|^log' /etc/chrony/chrony.conf log tracking measurements statistics logdir /var/log/chrony mailonchange root@localhost 4.0 > and run the following commands (as root): > > # mv /var/log/chrony/measurements.log /var/log/chrony/measurements1.log > # chronyc cyclelogs > > wait a few seconds and tell me if a new “measurements.log” file is > created. # ls -altrF /var/log/chrony/ total 76 drwxr-xr-x 2 _chrony _chrony 4096 Feb 24 10:31 ./ drwxr-xr-x 10 rootroot 4096 Feb 24 11:09 ../ -rw-r--r-- 1 _chrony _chrony 18720 Feb 24 19:57 statistics.log -rw-r--r-- 1 _chrony _chrony 25756 Feb 24 19:57 measurements.log -rw-r--r-- 1 _chrony _chrony 9768 Feb 24 20:00 tracking.log # mv /var/log/chrony/measurements.log /var/log/chrony/measurements1.log # ls -altrF /var/log/chrony/ total 76 drwxr-xr-x 10 rootroot 4096 Feb 24 11:09 ../ -rw-r--r-- 1 _chrony _chrony 18720 Feb 24 19:57 statistics.log -rw-r--r-- 1 _chrony _chrony 25756 Feb 24 19:57 measurements1.log -rw-r--r-- 1 _chrony _chrony 9768 Feb 24 20:00 tracking.log drwxr-xr-x 2 _chrony _chrony 4096 Feb 24 20:10 ./ # chronyc cyclelogs 506 Cannot talk to daemon # sleep 10 # ls -altrF /var/log/chrony/ total 76 drwxr-xr-x 10 rootroot 4096 Feb 24 11:09 ../ -rw-r--r-- 1 _chrony _chrony 18720 Feb 24 19:57 statistics.log -rw-r--r-- 1 _chrony _chrony 25756 Feb 24 19:57 measurements1.log -rw-r--r-- 1 _chrony _chrony 9768 Feb 24 20:00 tracking.log drwxr-xr-x 2 _chrony _chrony 4096 Feb 24 20:10 ./ It seems the daemon is not running and no logs are created or updated. The interesting thing is that chronyd seems to be started by "service chrony start" and then seems to die immediately after beginning to write some logs: # mv /var/log/chrony/* /root/ # ls -altrF /var/log/chrony/ total 8 drwxr-xr-x 10 rootroot4096 Feb 24 11:09 ../ drwxr-xr-x 2 _chrony _chrony 4096 Feb 24 20:14 ./ # ps ax | grep chrony 12097 pts/0S+ 0:00 grep chrony # service chrony restart [ ok ] Stopping time daemon: chronyd. [ ok ] Starting time daemon: chronyd. # ps ax | grep chrony 12166 pts/0S+ 0:00 grep chrony # chronyc tracking 506 Cannot talk to daemon # ls -altrF /var/log/chrony/ total 12 drwxr-xr-x 10 rootroot4096 Feb 24 11:09 ../ -rw-r--r-- 1 _chrony _chrony 528 Feb 24 20:15 tracking.log -rw-r--r-- 1 _chrony _chrony0 Feb 24 20:15 measurements.log drwxr-xr-x 2 _chrony _chrony 4096 Feb 24 20:15 ./ # cat /var/log/chrony/tracking.log === Date (UTC) Time IP Address St Freq ppm Skew ppm Offset L Co Offset sd Rem. corr. Root delay Root disp. Max. error === 2019-02-24 19:15:15 0.0.0.0 0-63.127 0.106 0.000e+00
Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log
On Sun, Feb 24, 2019 at 05:05:58PM +0100, Francesco Poli wrote: On Sun, 24 Feb 2019 16:25:19 +0100 Vincent Blut wrote: [...] On Sun, Feb 24, 2019 at 12:59:21PM +0100, Francesco Poli (wintermute) wrote: [...] >Everything seems to be fine, but: > > $ ps a | grep chrony > 10686 pts/1S+ 0:00 grep chrony > >the daemon is not running! Could you please provide the output of `grep -i chrony /var/log/syslog'? The lines added when doing # service chrony start are: Feb 24 16:53:39 HOST chronyd[11063]: chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG) Feb 24 16:53:39 HOST chronyd[11063]: Frequency -63.017 +/- 0.053 ppm read from /var/lib/chrony/chrony.drift Feb 24 16:53:39 HOST chronyd[11063]: Loaded seccomp filter But, once again, chrony is not running: # ps a | grep chrony 11086 pts/0S+ 0:00 grep chrony Please use `ps ax | grep chrony' (or ps -ef). `ps a' only lists processes with a tty. Also, the output of `chronyc tracking' would be useful to check chronyd’s status and system time information. >After a bit of investigation, I found out that the log directive: > > $ grep '^log ' /etc/chrony/chrony.conf > log tracking measurements statistics > >seems to also conflict with the system call filter. That is not supposed to happen. I’m running some systems with chronyd’s log files and the system call filter enabled with no issues. Could you tell me more about the “logdir” directive in /etc/chrony/chrony.conf? $ grep logdir /etc/chrony/chrony.conf logdir /var/log/chrony $ ls -altrF /var/log/chrony total 44 drwxr-xr-x 2 _chrony _chrony 4096 Feb 24 10:31 ./ drwxr-xr-x 10 rootroot 4096 Feb 24 11:09 ../ -rw-r--r-- 1 _chrony _chrony 12051 Feb 24 16:51 statistics.log -rw-r--r-- 1 _chrony _chrony 16029 Feb 24 16:51 measurements.log -rw-r--r-- 1 _chrony _chrony 6336 Feb 24 16:53 tracking.log Needless to say, the logs were written by chronyd, when running with the '-F 0' option... Ok, so please reenable the syscall filter and run the following commands (as root): # mv /var/log/chrony/measurements.log /var/log/chrony/measurements1.log # chronyc cyclelogs wait a few seconds and tell me if a new “measurements.log” file is created. Cheers, Vincent signature.asc Description: PGP signature
Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log
On Sun, 24 Feb 2019 16:25:19 +0100 Vincent Blut wrote: [...] > On Sun, Feb 24, 2019 at 12:59:21PM +0100, Francesco Poli (wintermute) > wrote: [...] > >Everything seems to be fine, but: > > > > $ ps a | grep chrony > > 10686 pts/1S+ 0:00 grep chrony > > > >the daemon is not running! > > Could you please provide the output of `grep -i chrony /var/log/syslog'? The lines added when doing # service chrony start are: Feb 24 16:53:39 HOST chronyd[11063]: chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG) Feb 24 16:53:39 HOST chronyd[11063]: Frequency -63.017 +/- 0.053 ppm read from /var/lib/chrony/chrony.drift Feb 24 16:53:39 HOST chronyd[11063]: Loaded seccomp filter But, once again, chrony is not running: # ps a | grep chrony 11086 pts/0S+ 0:00 grep chrony Of course, what is described above happens after setting: $ grep 'mailonchange\|log' /etc/chrony/chrony.conf # Uncomment the following line to turn logging on. log tracking measurements statistics logdir /var/log/chrony mailonchange root@localhost 4.0 $ grep OPT /etc/default/chrony DAEMON_OPTS="-F 0" DAEMON_OPTS="-F -1" > > >After a bit of investigation, I found out that the log directive: > > > > $ grep '^log ' /etc/chrony/chrony.conf > > log tracking measurements statistics > > > >seems to also conflict with the system call filter. > > That is not supposed to happen. I’m running some systems with chronyd’s > log files and the system call filter enabled with no issues. Could you > tell me more about the “logdir” directive in /etc/chrony/chrony.conf? $ grep logdir /etc/chrony/chrony.conf logdir /var/log/chrony $ ls -altrF /var/log/chrony total 44 drwxr-xr-x 2 _chrony _chrony 4096 Feb 24 10:31 ./ drwxr-xr-x 10 rootroot 4096 Feb 24 11:09 ../ -rw-r--r-- 1 _chrony _chrony 12051 Feb 24 16:51 statistics.log -rw-r--r-- 1 _chrony _chrony 16029 Feb 24 16:51 measurements.log -rw-r--r-- 1 _chrony _chrony 6336 Feb 24 16:53 tracking.log Needless to say, the logs were written by chronyd, when running with the '-F 0' option... [...] > >Secondly, with no mailonchange and no log, chrony seems to have become > >completely silent: how can I check that it is actually working fine, > >if I cannot even see which time servers it is tracking? > > chronyc provides some useful commands to track what is going on. Run > `chronyc help' for an exhaustive list of available commands. OK, this is a possible strategy, but, frankly speaking, checking the logs is often simpler and quicker... Anyway, should you need any further information, don't hesitate to ask. Otherwise, let's drop the moreinfo tag... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpVGtZsFwh0a.pgp Description: PGP signature
Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log
Control: tags -1 moreinfo Hi Francesco, On Sun, Feb 24, 2019 at 12:59:21PM +0100, Francesco Poli (wintermute) wrote: Package: chrony Version: 3.4-2 Severity: important Hello there! Thanks for maintaining this useful package. You’re welcome! I've just upgraded to version 3.4-2 and noticed that the daemon failed to restart, due to the mailonchange directive: $ grep -B 1 ^mailonchange /etc/chrony/chrony.conf # Warn root. mailonchange root@localhost 4.0 After reading /usr/share/doc/chrony/NEWS.Debian.gz , I found out that the new system call filter (which is now enabled by default) is incompatible with the mailonchange directive. That’s correct. This didn't make me especially happy, since that little local mail message telling me there was a significant time adjustment was nice to have... But, oh well, I can live without it, so I thought "let's get rid of it!". $ grep mailonchange /etc/chrony/chrony.conf gives no output, OK. # service chrony restart Everything seems to be fine, but: $ ps a | grep chrony 10686 pts/1S+ 0:00 grep chrony the daemon is not running! Could you please provide the output of `grep -i chrony /var/log/syslog'? After a bit of investigation, I found out that the log directive: $ grep '^log ' /etc/chrony/chrony.conf log tracking measurements statistics seems to also conflict with the system call filter. That is not supposed to happen. I’m running some systems with chronyd’s log files and the system call filter enabled with no issues. Could you tell me more about the “logdir” directive in /etc/chrony/chrony.conf? There are two issues with this. First of all, the NEWS.Debian.gz file does not seem to mention it (the man page also seems to say nothing about it). Well, let’s first find out where the issue lies. Secondly, with no mailonchange and no log, chrony seems to have become completely silent: how can I check that it is actually working fine, if I cannot even see which time servers it is tracking? chronyc provides some useful commands to track what is going on. Run `chronyc help' for an exhaustive list of available commands. Please let me know whether I misunderstood something and/or whether I am doing something wrong. Thanks for your time! Bye. Thanks for your report, Vincent signature.asc Description: PGP signature
Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log
Package: chrony Version: 3.4-2 Severity: important Hello there! Thanks for maintaining this useful package. I've just upgraded to version 3.4-2 and noticed that the daemon failed to restart, due to the mailonchange directive: $ grep -B 1 ^mailonchange /etc/chrony/chrony.conf # Warn root. mailonchange root@localhost 4.0 After reading /usr/share/doc/chrony/NEWS.Debian.gz , I found out that the new system call filter (which is now enabled by default) is incompatible with the mailonchange directive. This didn't make me especially happy, since that little local mail message telling me there was a significant time adjustment was nice to have... But, oh well, I can live without it, so I thought "let's get rid of it!". $ grep mailonchange /etc/chrony/chrony.conf gives no output, OK. # service chrony restart Everything seems to be fine, but: $ ps a | grep chrony 10686 pts/1S+ 0:00 grep chrony the daemon is not running! After a bit of investigation, I found out that the log directive: $ grep '^log ' /etc/chrony/chrony.conf log tracking measurements statistics seems to also conflict with the system call filter. There are two issues with this. First of all, the NEWS.Debian.gz file does not seem to mention it (the man page also seems to say nothing about it). Secondly, with no mailonchange and no log, chrony seems to have become completely silent: how can I check that it is actually working fine, if I cannot even see which time servers it is tracking? Is this a bug or something unavoidable (that should be documented in the NEWS.Debian.gz file and/or in the man page)? I have disabled the system call filter for the time being, in order to enable log (as well as mailonchange): $ grep OPTS /etc/default/chrony DAEMON_OPTS="-F 0" Please let me know whether I misunderstood something and/or whether I am doing something wrong. Thanks for your time! Bye. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: i386 (i586) Kernel: Linux 4.19.0-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages chrony depends on: ii adduser 3.118 ii init-system-helpers 1.56+nmu1 ii iproute2 4.20.0-2 ii libc62.28-7 ii libcap2 1:2.25-2 ii libedit2 3.1-20181209-1 ii libnettle6 3.4.1-1 ii libseccomp2 2.3.3-4 ii lsb-base 10.2018112800 ii ucf 3.0038+nmu1 chrony recommends no packages. Versions of packages chrony suggests: pn dnsutils pn networkd-dispatcher -- Configuration Files: /etc/default/chrony changed: DAEMON_OPTS="-F 0" -- no debconf information
