[Bug 1016313] New: Base:System/systemd: journal has stopped working in v232
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 Bug ID: 1016313 Summary: Base:System/systemd: journal has stopped working in v232 Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: Bugzilla Assignee: systemd-maintainers@suse.de Reporter: scalpel4k@gmail.com QA Contact: novbugzilla-bugs@forge.provo.novell.com Found By: --- Blocker: --- Hi guys, since I updated to v232 my journal stopped working. Starting the service gives an unspecific error message: 'Job for systemd-journald.service failed. ....' I have now tinkered with the unit file and found that the following line is causing trouble. SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount @obsolete @raw-io I don't know how to further investigate this, so please let me know what I can do to send in more details. bye Michi -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c1 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fbui@suse.com --- Comment #1 from Franck Bui <fbui@suse.com> --- Hi Michael, Weird nothing similar was reported so far. Could you try ? - restore the SystemCallFilter= directive - enable debug logs: systemd-analyze set-log-level debug - start journald: systemctl restart systemd-journald - show the output of journalctl -b Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c2 --- Comment #2 from Michael Woski <scalpel4k@gmail.com> --- (In reply to Franck Bui from comment #1) Hi Franck, thanks for your reply. Unfortunately, having a crashing journal service doesn't give you too much insight, even in debug mode ;-) However, I have other services that were also crashing so I went for the timesyncd service for which I will attach the journal output. I was also looking into other service files and saw that e.g. the logind unit file had some filter settings as well, however, the service has been working just fine. I found that one difference to the timesyncd service is actually the @mount signal. So I deleted that particular statement and ultimately timesyncd started to work again. bye Michi -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c3 --- Comment #3 from Michael Woski <scalpel4k@gmail.com> --- Created attachment 707304 --> http://bugzilla.opensuse.org/attachment.cgi?id=707304&action=edit journal for restarting timesyncd (with original service file) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c4 --- Comment #4 from Franck Bui <fbui@suse.com> --- (In reply to Michael Woski from comment #2)
thanks for your reply. Unfortunately, having a crashing journal service doesn't give you too much insight, even in debug mode ;-)
yeah... I won the dumb question of the week ;) Currently I'm puzzled as it works fine here... Anything relevant in dmesg ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c5 --- Comment #5 from Michael Woski <scalpel4k@gmail.com> --- (In reply to Franck Bui from comment #4)
yeah... I won the dumb question of the week ;) I won't tell anyone ...
Anyway, dmesg is of no help, there's nothing interesting :-( -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c6 --- Comment #6 from Franck Bui <fbui@suse.com> --- Ok then if you agree I'll prepare a testing package tomorrow that will make timesyncd sleeps during 20 secs or so before starting so you'll have enough time to attach to the process with gdb and locate the place that calls a filtered syscall. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c7 --- Comment #7 from Michael Woski <scalpel4k@gmail.com> --- (In reply to Franck Bui from comment #6)
Ok then if you agree I'll prepare a testing package tomorrow that will make timesyncd sleeps during 20 secs or so before starting so you'll have enough time to attach to the process with gdb and locate the place that calls a filtered syscall. I could do it on my own by just wrapping it all in a script with a sleep call, right?
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c8 --- Comment #8 from Franck Bui <fbui@suse.com> --- Not sure how you will attach to timesyncd this way as it won't be started when the service will sleep. Here's the testing package: http://download.opensuse.org/repositories/home:/fbui:/systemd:/next:/openSUS... Please install it (zypper dup --repo X) and also install systemd-debug{source,info) from this repo to. You might need to install liblz4-1_7 from your regular repo first if it's not already installed on your setup. Reboot and start manually systemd-timesyncd, it should hang now for 30 secs. In another terminal, find out the PID of the daemon (ps aux | grep timesyncd) and attach to it with "gdb -p <pid>". You'll be able to step in through the code and see which part exactly cause the SIGSYS. Thanks ! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c9 --- Comment #9 from Michael Woski <scalpel4k@gmail.com> --- (In reply to Franck Bui from comment #8) Hi Franck, sorry for the long delay. Meanwhile I was able to test your packages, but the whole thing didn't work as intended, I guess. systemd seems to kill the process straightaway, so there's no systemd-timesyncd process to attach to. I had this problem as well when I tried to start gdb directly from a script. Could it be that this is not really a problem with the service in question but with systemd itself? Whenever a unit file has that @mount parameter systemd denies executing the service? bye Michi -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c10 --- Comment #10 from Franck Bui <fbui@suse.com> --- (In reply to Michael Woski from comment #9)
sorry for the long delay. Meanwhile I was able to test your packages, but the whole thing didn't work as intended, I guess. systemd seems to kill the process straightaway, so there's no systemd-timesyncd process to attach to.
Hmm that's strange, IIRC I gave the testing package a try and it worked as expected. It's supposed to wait during 30 sec before starting its execution. Did you try to start systemd-timesyncd manually ? You should make sure that the service is disabled at boot and start it manually. Also WatchdogSec=3min for this service so you won't have enough time to debug before systemd notifies that the service is stuck. As a consequence systemd will kill it. To disable this: $ mkdir /etc/systemd/system/systemd-timesyncd.d $ cat >/etc/systemd/system/systemd-timesyncd.d/no-watchdog.conf<<EOF WatchdogSec=0 EOF $ systemctl daemon-reload Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c11 --- Comment #11 from Michael Woski <scalpel4k@gmail.com> --- (In reply to Franck Bui from comment #10) I think I did everything correctly regarding the service setup. As I said, it looks like timesyncd doesn't get started in the first place. Yesterday I discovered that I had very old gvfs files on my system, but no rpm was actually installed. It could well be that my system has some old cruft somewhere lying around which is causing the problem ... although gvfs wasn't to blame in this case. I have openSUSE with systemd 232 running in a few virtual machines without that particular issue. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c12 --- Comment #12 from Franck Bui <fbui@suse.com> --- (In reply to Michael Woski from comment #11)
(In reply to Franck Bui from comment #10)
I think I did everything correctly regarding the service setup. As I said, it looks like timesyncd doesn't get started in the first place.
Hmm according to the log you provided in comment #3: Dec 20 17:23:45 linux01.mic.e-concepts.de systemd[31307]: systemd-timesyncd.service: Executing: /usr/lib/systemd/systemd-timesyncd which indicates that systemd has at least executed the binary. But it looks like the (new) process fails very early. Could you try to create a dumb service by duplicating systemd-timesyncd one and then try: 1/ to replace: ExecStart=/usr/lib/systemd/systemd-timesyncd with ExecStart=/usr/lib/systemd/sleep 10000 You'll need to copy /usr/bin/sleep to /usr/lib/systemd/ 2/ if 1/ doesn't exhibit the probleme restore ExecStart=/usr/lib/systemd/systemd-timesyncd 3/ make the service as simple as possible by removing all fields in [Service] section that are not needed to reproduce the issue. 4/ show the output of "strace -c <content of ExecStart>" Also it might be interesting to see what happens if you add "SystemCallErrorNumber=EPERM", I meant if the debug log show something more interesting.
I have openSUSE with systemd 232 running in a few virtual machines without that particular issue.
BTW could you describe your affected setup ? is it a virtual machine ? which arch ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c13 --- Comment #13 from Michael Woski <scalpel4k@gmail.com> --- (In reply to Franck Bui from comment #12)
1/ to replace:
ExecStart=/usr/lib/systemd/systemd-timesyncd
with
ExecStart=/usr/lib/systemd/sleep 10000
You'll need to copy /usr/bin/sleep to /usr/lib/systemd/
works
3/ make the service as simple as possible by removing all fields in [Service] section that are not needed to reproduce the issue.
well, it's the @mount option in the SystemCallFilter. Removing all other properties does not help as long as that @mount option is set
4/ show the output of "strace -c <content of ExecStart>"
see attached files
Also it might be interesting to see what happens if you add "SystemCallErrorNumber=EPERM", I meant if the debug log show something more interesting.
it's working, but I would have expected that.
BTW could you describe your affected setup ? is it a virtual machine ? which arch ?
x86_64, "real" machine, openSUSE Factory -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c14 --- Comment #14 from Michael Woski <scalpel4k@gmail.com> --- funny, I can't find where I can upload attachments :-P Job for systemd-timesyncd.service failed because a fatal signal was delivered to the control process. See "systemctl status systemd-timesyncd.service" and "journalctl -xe" for details. % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 0.00 0.000000 0 23 read 0.00 0.000000 0 53 22 open 0.00 0.000000 0 32 close 0.00 0.000000 0 5 3 stat 0.00 0.000000 0 32 fstat 0.00 0.000000 0 55 mmap 0.00 0.000000 0 38 mprotect 0.00 0.000000 0 1 munmap 0.00 0.000000 0 3 brk 0.00 0.000000 0 3 rt_sigaction 0.00 0.000000 0 3 rt_sigprocmask 0.00 0.000000 0 2 1 ioctl 0.00 0.000000 0 2 writev 0.00 0.000000 0 3 3 access 0.00 0.000000 0 1 socket 0.00 0.000000 0 1 connect 0.00 0.000000 0 5 sendmsg 0.00 0.000000 0 41 12 recvmsg 0.00 0.000000 0 1 getsockname 0.00 0.000000 0 2 setsockopt 0.00 0.000000 0 5 getsockopt 0.00 0.000000 0 1 clone 0.00 0.000000 0 1 execve 0.00 0.000000 0 2 kill 0.00 0.000000 0 1 getrlimit 0.00 0.000000 0 3 geteuid 0.00 0.000000 0 2 1 statfs 0.00 0.000000 0 1 arch_prctl 0.00 0.000000 0 1 1 mount 0.00 0.000000 0 1 gettid 0.00 0.000000 0 1 futex 0.00 0.000000 0 1 set_tid_address 0.00 0.000000 0 1 waitid 0.00 0.000000 0 12 ppoll 0.00 0.000000 0 1 set_robust_list 0.00 0.000000 0 1 getrandom ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000000 341 43 total -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c15 --- Comment #15 from Michael Woski <scalpel4k@gmail.com> --- open("/usr/lib/locale/en_GB.utf8/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=57, ...}) = 0 mmap(NULL, 57, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2b4eadf000 close(3) = 0 open("/usr/lib/locale/en_DE.UTF-8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_DE.utf8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_DE/LC_MONETARY", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en.UTF-8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en.utf8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en/LC_MONETARY", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/proc/self/stat", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 read(3, "2992 (systemctl) R 2990 2990 161"..., 1024) = 313 close(3) = 0 rt_sigaction(SIGBUS, {sa_handler=0x7f2b4e536170, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f2b4e2ae080}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 ioctl(1, TCGETS, 0x7fff37085200) = -1 ENOTTY (Inappropriate ioctl for device) stat("/proc/1/root", {st_mode=S_IFDIR|0755, st_size=198, ...}) = 0 stat("/", {st_mode=S_IFDIR|0755, st_size=198, ...}) = 0 geteuid() = 0 open("/sys/fs/kdbus/0-system/bus", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 ENOENT (No such file or directory) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 getsockopt(3, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0 setsockopt(3, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = 0 getsockopt(3, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0 setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = 0 connect(3, {sa_family=AF_UNIX, sun_path="/run/systemd/private"}, 22) = 0 getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0 fstat(3, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0 getsockopt(3, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0 getsockname(3, {sa_family=AF_UNIX}, [128->2]) = 0 geteuid() = 0 sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0AUTH EXTERNAL ", iov_len=15}, {iov_base="30", iov_len=2}, {iov_base="\r\nNEGOTIATE_UNIX_FD\r\nBEGIN\r\n", iov_len=28}], msg_iovlen=3, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 45 getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f2b4eab3fd0) = 2993 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 geteuid() = 0 gettid() = 2992 getrandom("\245\257\205,10\332\353\370\366\16k{\343/\340", 16, GRND_NONBLOCK) = 16 recvmsg(3, {msg_namelen=0}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) ppoll([{fd=3, events=POLLIN}], 1, {tv_sec=24, tv_nsec=999472000}, NULL, 8) = 1 ([{fd=3, revents=POLLIN}], left {tv_sec=24, tv_nsec=998933877}) recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="OK fb0a1a942ed446bbbff46cce22c7e"..., iov_len=256}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 52 sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\4\1,\0\0\0\1\0\0\0\240\0\0\0\1\1o\0\31\0\0\0/org/fre"..., iov_len=176}, {iov_base="\31\0\0\0systemd-timesyncd.service\0\0\0"..., iov_len=44}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 220 recvmsg(3, {msg_namelen=0}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) ppoll([{fd=3, events=POLLIN}], 1, {tv_sec=24, tv_nsec=999966000}, NULL, 8) = 1 ([{fd=3, revents=POLLIN}], left {tv_sec=24, tv_nsec=999791012}) recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1'\0\0\0\1\0\0\0\17\0\0\0\5\1u\0\1\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\10\1g\0\1o\0\0\"\0\0\0/org/freedesktop/sys"..., iov_len=47}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 47 sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\4\1\36\0\0\0\2\0\0\0\227\0\0\0\1\1o\0\31\0\0\0/org/fre"..., iov_len=168}, {iov_base="\31\0\0\0systemd-timesyncd.service\0", iov_len=30}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 198 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1J\0\0\0\2\0\0\0q\0\0\0\1\1o\0\31\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/systemd1\0\0\0\0\0\0\0"..., iov_len=186}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 186 recvmsg(3, {msg_namelen=0}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) ppoll([{fd=3, events=POLLIN}], 1, {tv_sec=24, tv_nsec=999912000}, NULL, 8) = 1 ([{fd=3, revents=POLLIN}], left {tv_sec=24, tv_nsec=998905407}) recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1L\0\0\0\3\0\0\0~\0\0\0\1\1o\0\31\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/systemd1\0\0\0\0\0\0\0"..., iov_len=196}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 196 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1\221\2\0\0\4\0\0\0\236\0\0\0\1\1o\0<\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/systemd1/unit/s"..., iov_len=809}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 809 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1D\3\0\0\5\0\0\0\236\0\0\0\1\1o\0<\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/systemd1/unit/s"..., iov_len=988}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 988 recvmsg(3, {msg_namelen=0}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) ppoll([{fd=3, events=POLLIN}], 1, {tv_sec=24, tv_nsec=998640000}, NULL, 8) = 1 ([{fd=3, revents=POLLIN}], left {tv_sec=24, tv_nsec=998639375}) recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1H\0\0\0\6\0\0\0\206\0\0\0\1\1o\0\"\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/systemd1/job/74"..., iov_len=200}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 200 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1A\0\0\0\7\0\0\0\17\0\0\0\5\1u\0\2\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\10\1g\0\1o\0\0<\0\0\0/org/freedesktop/sys"..., iov_len=73}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 73 sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\4\0019\0\0\0\3\0\0\0\260\0\0\0\1\1o\0<\0\0\0/org/fre"..., iov_len=192}, {iov_base="\35\0\0\0org.freedesktop.systemd1.Uni"..., iov_len=57}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 249 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\10\0\0\0\10\0\0\0\17\0\0\0\5\1u\0\3\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\10\1g\0\1v\0\0\1b\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 16 recvmsg(3, {msg_namelen=0}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) ppoll([{fd=3, events=POLLIN}], 1, NULL, NULL, 8) = 1 ([{fd=3, revents=POLLIN}]) recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1L\0\0\0\t\0\0\0~\0\0\0\1\1o\0\31\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/systemd1\0\0\0\0\0\0\0"..., iov_len=196}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 196 recvmsg(3, {msg_namelen=0}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) ppoll([{fd=3, events=POLLIN}], 1, NULL, NULL, 8) = 1 ([{fd=3, revents=POLLIN}]) recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1W\0\0\0\n\0\0\0z\0\0\0\1\1o\0\31\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/systemd1\0\0\0\0\0\0\0"..., iov_len=207}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 207 sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\4\0013\0\0\0\4\0\0\0\260\0\0\0\1\1o\0<\0\0\0/org/fre"..., iov_len=192}, {iov_base=" \0\0\0org.freedesktop.systemd1.Ser"..., iov_len=51}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 243 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1L\0\0\0\v\0\0\0~\0\0\0\1\1o\0\31\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/systemd1\0\0\0\0\0\0\0"..., iov_len=196}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 196 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1\221\2\0\0\f\0\0\0\236\0\0\0\1\1o\0<\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/systemd1/unit/s"..., iov_len=809}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 809 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1,\3\0\0\r\0\0\0\236\0\0\0\1\1o\0<\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/systemd1/unit/s"..., iov_len=964}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 964 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\17\0\0\0\16\0\0\0\17\0\0\0\5\1u\0\4\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\10\1g\0\1v\0\0\1s\0\0\6\0\0\0signal\0", iov_len=23}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 23 writev(2, [{iov_base="Job for systemd-timesyncd.servic"..., iov_len=101}, {iov_base="\n", iov_len=1}], 2Job for systemd-timesyncd.service failed because a fatal signal was delivered to the control process. ) = 102 writev(2, [{iov_base="See \"systemctl status systemd-ti"..., iov_len=82}, {iov_base="\n", iov_len=1}], 2See "systemctl status systemd-timesyncd.service" and "journalctl -xe" for details. ) = 83 close(3) = 0 kill(2993, SIGTERM) = 0 kill(2993, SIGCONT) = 0 waitid(P_PID, 2993, {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2993, si_uid=0, si_status=0, si_utime=0, si_stime=0}, WEXITED, NULL) = 0 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2993, si_uid=0, si_status=0, si_utime=0, si_stime=0} --- exit_group(1) = ? +++ exited with 1 +++ -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c16 --- Comment #16 from Michael Woski <scalpel4k@gmail.com> --- Created attachment 708582 --> http://bugzilla.opensuse.org/attachment.cgi?id=708582&action=edit strace that's embarrassing, here's the announced attachment -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c17 --- Comment #17 from Franck Bui <fbui@suse.com> --- (In reply to Michael Woski from comment #16)
Created attachment 708582 [details] strace
The (s)trace here is uninteresting: execve("/usr/bin/systemctl", ["systemctl", "start", "systemd-timesyncd.service"], [/* 116 vars */]) = 0 you did strace systemctl... the interesting process in your case is systemd-timesyncd which is started by systemd (PID1). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c18 --- Comment #18 from Franck Bui <fbui@suse.com> --- (In reply to Michael Woski from comment #14)
funny, I can't find where I can upload attachments :-P
Job for systemd-timesyncd.service failed because a fatal signal was delivered to the control process. See "systemctl status systemd-timesyncd.service" and "journalctl -xe" for details. % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 0.00 0.000000 0 23 read
How did you get this output exactly ? Did you issue "strace -c /usr/lib/systemd/systemd-timesyncd" to get this summary ? Or did you issue "systemctl status systemd-timesyncd" ? Or something else ? Please next time show the command line you used.
[...] 0.00 0.000000 0 1 execve 0.00 0.000000 0 2 kill 0.00 0.000000 0 1 getrlimit 0.00 0.000000 0 3 geteuid 0.00 0.000000 0 2 1 statfs 0.00 0.000000 0 1 arch_prctl 0.00 0.000000 0 1 1 mount
Here's the mount syscall which triggers the killing signal. Could you remove the "-c" option passed to strace and redo the same test ? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c19 --- Comment #19 from Michael Woski <scalpel4k@gmail.com> --- (In reply to Franck Bui from comment #18) both outputs from earlier where from tracing systemctl, one with -c and one without. So basically both are about the same thing. For clarity, this is what I did: strace -c systemctl start systemd-timesyncd -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c20 --- Comment #20 from Franck Bui <fbui@suse.com> --- (In reply to Michael Woski from comment #19)
For clarity, this is what I did: strace -c systemctl start systemd-timesyncd
That's not what I was asking for in comment #12. I was asking for the output of: "strace -c /usr/lib/systemd/systemd-timesyncd" -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c21 --- Comment #21 from Michael Woski <scalpel4k@gmail.com> --- Created attachment 708603 --> http://bugzilla.opensuse.org/attachment.cgi?id=708603&action=edit strace -c /usr/lib/systemd/systemd-timesyncd -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c22 --- Comment #22 from Franck Bui <fbui@suse.com> --- (In reply to Michael Woski from comment #21)
Created attachment 708603 [details] strace -c /usr/lib/systemd/systemd-timesyncd
Thanks. Please now show the output of "strace /usr/lib/systemd/systemd-timesyncd" -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c23 --- Comment #23 from Michael Woski <scalpel4k@gmail.com> --- Created attachment 708604 --> http://bugzilla.opensuse.org/attachment.cgi?id=708604&action=edit strace /usr/lib/systemd/systemd-timesyncd -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c24 --- Comment #24 from Franck Bui <fbui@suse.com> --- Ok, the issue you're facing is probably due to :
execve("/usr/lib/systemd/systemd-timesyncd", ["/usr/lib/systemd/systemd-timesyn"...], [/* 116 vars */]) = 0 ... statfs("/sys/fs/selinux", 0x7ffec2cac480) = -1 ENOENT (No such file or directory) statfs("/selinux", {f_type=BTRFS_SUPER_MAGIC, f_bsize=4096, f_blocks=31204254, f_bfree=29339042, f_bavail=29153112, f_files=0, f_ffree=0, f_fsid={val=[2664197864, 450012966]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOATIME}) = 0 mount("proc", "/proc", "proc", 0, NULL) = -1 EBUSY (Device or resource busy)
This call to mount(2) is done when ld is loading and initializing the share libs used by systemd-timesyncd. libselinux is one of them and is the one which does the mount(2) syscall.
From libselinux changelog:
$ rpm -q libselinux1 libselinux1-2.5-2.5.x86_64 $ rpm -q --changelog libselinux1 [...] * Sun Jul 24 2016 crrodriguez@opensuse.org - Avoid mounting /proc outside of selinux_init_load_policy(). (Stephen Smalley) reverts upstream 5a8d8c4, 9df4988, fixes among other things systemd seccomp sandboxing otherwise all filters must allow mount(2) (libselinux-proc-mount-only-if-needed.patch) [...] So it seems that this issue has been addressed already... Can you check the version of this lib installed on your system and make sure that the version you're using includes this fix ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c25 Michael Woski <scalpel4k@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #25 from Michael Woski <scalpel4k@gmail.com> --- (In reply to Franck Bui from comment #24) that was the reason indeed. I had an rpm with version 2.5-1.1 shadowing the latest version from Factory. Sorry for the trouble and many thanks for your help and patience. bye Michi -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c26 Rainer Klier <rainer.klier@gmx.at> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rainer.klier@gmx.at --- Comment #26 from Rainer Klier <rainer.klier@gmx.at> --- (In reply to Michael Woski from comment #25)
(In reply to Franck Bui from comment #24)
that was the reason indeed. I had an rpm with version 2.5-1.1 shadowing the latest version from Factory. Sorry for the trouble and many thanks for your help and patience.
this bug also affects me. i also have libselinux1-2.5-1.1.x86_64 installed. i am currently updating to verify that it fixes the problem for me. thanks. i think, that systemd 232 should have a dependency to libselinux1-2.5-2.5, and should not be installed without libselinux1-2.5-2.5. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1016313 http://bugzilla.opensuse.org/show_bug.cgi?id=1016313#c27 --- Comment #27 from Rainer Klier <rainer.klier@gmx.at> --- (In reply to Rainer Klier from comment #26)
(In reply to Michael Woski from comment #25)
(In reply to Franck Bui from comment #24)
this bug also affects me. i also have libselinux1-2.5-1.1.x86_64 installed. i am currently updating to verify that it fixes the problem for me.
it is fixed with updating libselinux1. :-D -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com