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?
signature.asc
Description: OpenPGP digital signature
