[Pkg-systemd-maintainers] Bug#742322: backtrace for systemd crash

Michael Biebl biebl at debian.org
Thu Mar 27 01:57:47 GMT 2014


Am 27.03.2014 02:29, schrieb Michael Biebl:
> Am 26.03.2014 17:39, schrieb Andreas Cadhalpun:

> The sequence of events is
> a/ make sure cups.socket is running and correctly setup
> b/ make sure cups.service is not running
> c/ make /etc/systemd/system/cups.socket.d/cupsd-listen.conf a dangling
> symlink
> d/ trigger a daemon-reload
> e/ trigger activity on the cups socket, e.g. via lpq
>    → You get the abort

As mentioned on IRC, the problem is triggered in src/core/socket.c:
socket_enter_running(), when the incoming request causes the start of
the corresponding service unit via
r = manager_add_job(UNIT(s)->manager, JOB_START, UNIT_DEREF(s->service),
JOB_REPLACE, true, &error, NULL);


I think after the socket configuration has been messed up and the
daemon-reload, UNIT_DEREF(s->service) does no longer point to a valid
unit, and so the assert in manager_add_job() kicks in.

Ideas how to address this?
Should we just stop a socket if we detect on daemon-reload that the
socket configuration has been messed up?

Or should we do some sanity-checking of the unit in socket_enter_running
before we pass it on to manager_add_job()?
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140327/a75ed986/attachment-0002.sig>


More information about the Pkg-systemd-maintainers mailing list