There is an interesting bug which can be used to crash systemd via a dangling symlink. For details please see [0].
To trigger the bug, you need a socket activated service. I'm using cups in this case. The steps to reproduce are a/ Make sure cups.socket is properly configured and in state active (listening) b/ Make sure cups.service is *not* running c/ Create /etc/systemd/system/cups.socket.conf.d/ and then a dangling symlink like this ln -s /nonexistent /etc/systemd/system/cups.socket.conf.d/foo.conf d/ Run systemctl daemon-reload The socket is now in this state: Active: active (listening) Loaded: error (Reason: No such file or directory) e/ Now trigger a request on the cups.socket, e.g. using lpq → systemd freezes The problem afaics 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. I tested this with 204 and 208, and both versions are affected. Any suggestions how to fix this? A few remarks 1/ A dangling drop-in snippet should imho *not* cause the unit Load state to be Loaded: error (Reason: No such file or directory) 2/ If a socket is in such a state, we probably shouldn't process incoming requests and try to start the service 3/ Should we stop the socket if the Load state is "error" Michael [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742322#58 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
