Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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
ldm-users
archives: