[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