systemd can be crashed by using creating a dangling symlink in foo.service.d/. It was originally filed in the Debian bug tracker [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/questions:
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"?

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742322#58