I see this bug too, both in 0.0.13-1~deb8u1 and 0.0.13-1. After some
investigation I found this:
# service tlsdated start
# pgrep -l tlsdated
20776 tlsdated
20777 tlsdated-setter
# strace -f -p 20776 2>&1 | grep execve
[pid 20786] execve("", ["", "-H", "google.com", "-p", "443", "-x",
"socks5://127.0.0.1:9050", "-Vraw", "-n"], [/* 4 vars */]) = -1 ENOENT
(No such file or directory)
[pid 20786] write(2, "[tlsdate-monitor] execve() faile"..., 60) = 60
In other words, tlsdated tries to execute the program in the file "",
which obviously doesn't exist. However, if I don't use the init script
but run tlsdated directly:
# strace -f /usr/sbin/tlsdated 2>&1 | grep execve
execve("/usr/sbin/tlsdated", ["/usr/sbin/tlsdated"], [/* 39 vars */])
= 0
[pid 20999] execve("/usr/bin/tlsdate", ["/usr/bin/tlsdate", "-H",
"google.com", "-H", "google.com", "-p", "443", "-x",
"socks5://127.0.0.1:9050", "-Vraw", "-n"], [/* 39 vars */]
<unfinished ...>
[pid 20999] <... execve resumed> ) = 0
[pid 20999] execve("/usr/bin/tlsdate-helper", ["tlsdate",
"google.com", "443", "tlsv1", "racket", "quiet",
"/etc/tlsdate/ca-roots/tlsdate-ca"..., "dont-set-clock", "showtime=raw",
"no-fun", "holdfast", "socks5://127.0.0.1:9050", "tls"], [/* 39 vars
*/]) = 0
Here it executes /usr/bin/tlsdate instead, which is presumably what it
should have done in the first execution as well, and it prints
[event:handle_time_setter] time set from the network (1435683813)
to the syslog. So the problem only occurs when you run it with the init
script.
I hope this is helpful.
--ll
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
