#1116939 debsums: Cron job error "tee: /proc/self/fd/3: No such device or address" under systemd

#1116939#5
Date:
2025-09-30 19:41:09 UTC
From:
To:
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

#1116939#10
Date:
2025-09-30 21:10:44 UTC
From:
To:

#1116939#15
Date:
2025-09-30 21:25:20 UTC
From:
To:
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!

#1116939#20
Date:
2025-10-03 09:59:02 UTC
From:
To:
just a drive-by comment - would it help to do the fd3 stuff in a subshell?
#1116939#25
Date:
2026-01-07 05:09:43 UTC
From:
To:
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).

#1116939#30
Date:
2026-01-27 10:19:01 UTC
From:
To:
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.