Dear Maintainers, I noticed that the debsums (daily/weekly/monthly) cron jobs will throw an error when the scripts are run as systemd units - which is the case if you use systemd-cron as a replacement of the traditional cron daemon. The error message reads: tee: /proc/self/fd/3: No such device or address This is caused by the output redirection to a temporary file descriptor so the output can be sent to stdout as well as the log daemon. Systemd, by default, limits pipes to stdout and stderr only, which is why `tee /proc/self/fd/3' fails. I found an easy fix for this, however. Process substitution allows for the same output duplication/redirection and works regardless of being run as a systemd unit or not. The attached diff works for me. Would you consider shipping this simple fix as a stable update? Thank you! Regards, Timo
Sorry, I don't mean to bother you. But I made one more - and actually important - mistake. I tested my changed script with bash, and not dash. dash doesn't seem to support process substitution, so the attached diff does unfortunately not work as is. If you were to adopt my fix, the shebang would also need to be changed to bash. And that makes the fix actually a bit less simple. Hence, I would understand if you would prefer not to adopt my proposed fix, even though I hope that the issue itself will somehow be addressed eventually. Thanks!
just a drive-by comment - would it help to do the fd3 stuff in a subshell?
temporary file and cat it at the end. mktemp is in coreutils, which is essential, and this doesn't use any non-dash syntax. Sending the output as email is delayed until the script finishes anyway, so this should be equivalent. Caveat: the diff attached is untested with systemd. I just ran it as: sudo dash -xv cron.weekly and it appeared to work as expected (although found no issues on my particular machine).
that claim makes no sense. the new fd is created by the previous command, and systemd doesn't prevent it (otherwise there would be an error). what might be happening is that stdout is a journald socket, which cannot be opened via the .../fd/x mechanism. chatgpt claims this, so there is a slight chance that it might be true ... the proper solution is to include a systemd timer unit with debsums. the current script's complexity is ~100% stuff that systemd has built-ins for.