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
