# /etc/init.d/tlsdated restart * Stopping tlsdated ... * start-stop-daemon: no matching processes found [ ok ] * Starting tlsdated ... [ ok ] # /etc/init.d/tlsdated status * status: crashed On another machine where it worked I have (note, it is up and running in the first time): vh ~ # /etc/init.d/tlsdated restart * Stopping tlsdated ... [ ok ] * Starting tlsdated ... [ ok ] vh ~ # /etc/init.d/tlsdated restart * Stopping tlsdated ... * start-stop-daemon: no matching processes found [ ok ] * Starting tlsdated ... [ ok ] vh ~ # /etc/init.d/tlsdated restart * Stopping tlsdated ... * start-stop-daemon: no matching processes found [ ok ] * Starting tlsdated ... [ ok ] This is what I get after launch it manually: vh ~ # tlsdated -- /usr/bin/tlsdate -l -H www.google.com initial time sync type: system-clock synced rtc to sysclock [event:action_time_set] time setter pipe truncated! (0): Success [event:action_time_set] time setter pipe truncated! (-1): Bad file descriptor tlsdate-setter exitting: code:KILLED status:31 pid:32439 uid:0 tlsdated clean up finished; exiting
I've a bit different behaviour but same result. Execute manually works as fine as expected. Starting tlsdated (daemon) results in crashed status. /var/log/messages: Dec 19 14:34:22 d004 tlsdated[9048]: initial time sync type: system-clock Dec 19 14:34:22 d004 tlsdated[9048]: [event:action_time_set] time setter pipe truncated! (0): Success Dec 19 14:34:22 d004 tlsdated[9048]: [event:action_time_set] time setter pipe truncated! (-1): Bad file descriptor Dec 19 14:34:22 d004 tlsdated[9048]: tlsdate-setter exitting: code:KILLED status:31 pid:9050 uid:0 Dec 19 14:34:22 d004 tlsdated[9048]: tlsdated clean up finished; exiting! Dec 19 14:34:22 d004 kernel: audit: type=1326 audit(1513690462.000:2): auid=1000 uid=0 gid=0 ses=4 pid=9050 comm="tlsdated-setter" exe="/usr/sbin/tlsdated" sig=31 syscall=39 compat=0 ip=0x7f867a090197 code=0x0 Dec 19 14:34:23 d004 /etc/init.d/tlsdated[9074]: status: crashed It seems to be a issue with glibc. After updating a working instance to last stable sys-libs/glibc-2.25-r9 tlsdate daemon stopped working.
I see other distributions already killed it as it is dead for years and buggy: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827461
Is a good idea evaluate the google fork? https://chromium.googlesource.com/chromiumos/third_party/tlsdate/
I just discovered that the daemon crashes only if USE seccomp is enabled. So the problem resides in the seccomp system. I tried to apply a patch from google, but it still does not work for me because maybe I'm missing something else. ( https://chromium.googlesource.com/chromiumos/third_party/tlsdate/+/dbc57c67851f90eebdc2c07852e1df226daa9f50%5E%21/ ) Is a good idea mask the use seccomp for now?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=73eb78b120e29dba2f8272bbdd4ae6dc17644eb1 commit 73eb78b120e29dba2f8272bbdd4ae6dc17644eb1 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2018-12-04 16:52:27 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-12-04 16:53:40 +0000 net-misc/tlsdate: Remove last-rited pkg Closes: https://bugs.gentoo.org/637286 Signed-off-by: Michał Górny <mgorny@gentoo.org> net-misc/tlsdate/Manifest | 1 - .../files/tlsdate-0.0.13-tlsdated-service.patch | 22 ------- net-misc/tlsdate/files/tlsdate.confd | 8 --- net-misc/tlsdate/files/tlsdate.rc | 16 ----- net-misc/tlsdate/files/tlsdated.confd | 15 ----- net-misc/tlsdate/files/tlsdated.default | 4 -- net-misc/tlsdate/files/tlsdated.rc | 18 ----- net-misc/tlsdate/files/tlsdated.tmpfiles.conf | 1 - net-misc/tlsdate/metadata.xml | 8 --- net-misc/tlsdate/tlsdate-0.0.13.ebuild | 76 ---------------------- profiles/arch/arm64/package.use.mask | 4 -- profiles/arch/mips/package.use.mask | 4 -- profiles/package.mask | 6 -- 13 files changed, 183 deletions(-)
