Hello LDMer,
This email is to make you aware of an issue with the LDM on systems running
version 219 of the daemon systemd(8). If you don't run systemd(8), then you
may ignore this email until you do.
Version 219 of systemd(8) -- depending on how it was compiled for your
operating system -- can, by default, cause all upstream LDM processes
feeding downstream LDM processes to terminate due to an error. The
downstream LDM processes will reconnect and this process will repeat
indefinitely. This behavior is revealed by searching the upstream LDM's log
file for the string "uldb.c". For example
$ fgrep uldb.c ~/var/logs/ldmd.log | head -2
20230111T183527.886480Z xxx.xxx.xxx(feed)[73820] uldb.c:db_lock:1742 ERROR
Couldn't lock database for writing
20230111T183527.886488Z xxx.xxx.xxx(feed)[73820] uldb.c:uldb_addProcess:2152
ERROR Couldn't lock database
$
This problem results from the LDM using a shared-memory segment to hold its
list of active upstream LDM processes and systemd(8) deleting *all *of a
user's inter-process communication objects (which includes shared-memory
segments) when the user exits *any* session -- including ones launched via
a crontab(1) entry!
Don't get me started on what I think about this behavior.
The solution is to stop systemd(8) from doing this by ensuring that the
parameter "RemoveIPC" is set to "no" in the file "/etc/systemd/logind.conf":
# grep IPC -i /etc/systemd/logind.conf
#RemoveIPC=yes
If the value is "no", then nothing need be done, even if it's
commented-out; otherwise, set its value to "no", make sure it's *not*
commented-out, execute
the command
systemctl restart systemd-logind
and then restart your LDM.
You can read more on this issue in the rant
https://knzl.at/systemd-removeipc/ or by googling "systemd RemoveIPC".
Contact support-ldm@xxxxxxxxxxxxxxxx if you have any questions.
Regards,
Steve Emmerson
