On Thu, 06.11.14 16:32, Damien Robert (damien.olivier.rob...@gmail.com) wrote:
Here are the logs:
Nov 06 16:14:56 numenor systemd[1]: Started Network Time Synchronization.
Nov 06 16:14:56 numenor systemd-timesyncd[4881]: Using NTP server
10.3.255.254:123 (10.3.255.254).
Nov 06 16:15:06 numenor systemd-timesyncd[4881]: Timed out waiting for reply
from 10.3.255.254:123 (10.3.255.254).
Nov 06 16:15:06 numenor kernel: systemd-timesyn[4881]: segfault at 8 ip
b77bea0a sp bfddf800 error 4 in systemd-timesyncd[b77b5000+1c000]
Nov 06 16:15:06 numenor systemd[1]: systemd-timesyncd.service: main process
exited, code=killed, status=11/SEGV
Nov 06 16:15:06 numenor systemd[1]: Unit systemd-timesyncd.service entered
failed state.
Nov 06 16:15:06 numenor systemd[1]: systemd-timesyncd.service has no holdoff
time, scheduling restart.
I don't understand why I don't get a core dump, sending SIGABRT to a 'sleep'
does produce one:
Nov 06 16:09:39 numenor systemd-coredump[4321]: Process 4315 (sleep) of user
100
0 dumped core.
And my systemd/system.conf does not have a DefaultLimitCORE, and indeed
$ systemctl show systemd-timesyncd | grep LimitCORE
LimitCORE=18446744073709551615
Hmm, so, by default we leave the RLIMIT_CORE setting unmodified how we
got it from the kernel. This is the right choice usually, if you use
systemd-coredump to collect the coredumps of the system, since that is
actually not affected by the resource limit. The resource limit only
applies to core dumps stored to disk.
You can change the system-wide default for RLIMIT_CORE in
system.conf. However, I'd instead suggest to make use of
systemd-coredump instead.
Thanks!
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
