On 24/10/17 02:38, Lennart Poettering wrote:
On Do, 12.10.17 12:23, Joel Holdsworth ([email protected])
wrote:
Hi All,
I have an issue with the standard unit file:
./units/[email protected]
In my use case if the main application crashes twice in 2-minutes, the
system will reboot into a recovery environment. I'm using systemd-coredump
to capture the coredump files, but the problem is that if the reboot is
triggered, then the coredump process is killed during shutdown before the
coredump has been written to disk.
First of all, I'm having trouble correcting this behaviour. The
[email protected] should have no Conflicts=shutdown.target, and it
must have Before=shutdown.target. I tried making similar changes to the
corresponding .slice and .socket - but for some reason the coredump process
is still getting killed. Is there any way to make systemd log the reason why
a process was chosen for termination?
Also, the coredump process need to complete before the the relevant
partition is unmounted. Is there a way to do that?
These are all systemd n00b questions. But the bigger question is about
whether this is a bug in the standard unit files.
Quite frankly you hit a misdesign in the coredump service there. To
make this safe I figure it needs to become a Type=oneshot service
(i.e. instead of being a long-running service that shall be terminated
at shutdown it would the be a short-running service that we'll wait
for before shutting down).
COuld you please file a bug about this in the github issue tracker, so
that we fix this for good upstream?
Lennart
Hi Lennart, thanks for the response.
I filed a bug: https://github.com/systemd/systemd/issues/7176
For the time being, I found a hack setting
KillSignal=<some-no-op-signal> gives me the behavior I want, but
obviously it would be better to have a proper solution to prevent this.
Joel
_______________________________________________
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
