[systemd-devel] segfault in timesyncd

Lennart Poettering lennart at poettering.net
Thu Dec 4 15:03:40 PST 2014

On Thu, 06.11.14 16:32, Damien Robert (damien.olivier.robert at 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 (
> Nov 06 16:15:06 numenor systemd-timesyncd[4881]: Timed out waiting for reply from (
> 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.



Lennart Poettering, Red Hat

More information about the systemd-devel mailing list