Mail notifications from fcron

Installing & Running IPFire
1

Does anyone (successfully) use email notifications from fcron? I have read all of the man pages and set the fcrontabs accordingly. But no matter what I do, I never receive email notifications (unless the script has mail built into it) for the scripts in /etc/fcron.[period] or in the fcrontab itself. The scripts are executed (e.g., a test script touches a file) but no stdout is emailed.

fcrontab -e
#
# crontab for ipfire
#
# Set global variables
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
#MAILTO=full email address
HOME=/
!mailfrom(full email address),mailto(full email address)

# Do all jobs in this directories
*/1 * * * *     test -x /usr/local/bin/run-parts && /usr/local/bin/run-parts /etc/fcron.minutely
*/5 * * * *     test -x /usr/local/bin/run-parts && /usr/local/bin/run-parts /etc/fcron.cyclic
01 * * * *      test -x /usr/local/bin/run-parts && /usr/local/bin/run-parts /etc/fcron.hourly
&nice(10),bootrun 25 1 * * *    test -x /usr/local/bin/run-parts && /usr/local/bin/run-parts /etc/fcron.daily
&nice(10),bootrun 47 2 * * 1    test -x /usr/local/bin/run-parts && /usr/local/bin/run-parts /etc/fcron.weekly
&nice(10),bootrun 52 3 1 * *    test -x /usr/local/bin/run-parts && /usr/local/bin/run-parts /etc/fcron.monthly
.
.
.
# Test fcron mail
&mailto(root),forcemail 12 * * * * echo "Hello World" && touch /root/test1312

There is a test script in /etc/fcron.hourly and the last line of root’s fcrontab has mail commands in it. The scripts execute (i.e., files are created) but no email notification.

cron log:
13:12:00 fcron[9501]:  Job 'echo "Hello World" && touch /root/test1312' completed
13:12:00 fcron[9503]:  Job 'test -x /usr/local/bin/run-parts && /usr/local/bin/run-parts /etc/fcron.minutely' started for user root (pid 9504)
13:12:00 fcron[9501]:  Job 'echo "Hello World" && touch /root/test1312' started for user root (pid 9502)
13:01:00 fcron[8376]:  Job 'test -x /usr/local/bin/run-parts && /usr/local/bin/run-parts /etc/fcron.hourly' completed
13:01:00 fcron[8378]:  Job '/usr/sbin/logrotate /etc/logrotate.conf' completed
13:01:00 fcron[8378]:  Job '/usr/sbin/logrotate /etc/logrotate.conf' started for user root (pid 8379)
13:01:00 fcron[25463]:      Skipping execution of already running job: root's 'test -x /usr/local/bin/run-parts && /usr/local/bin/run-parts /etc/fcron.minutely'
13:01:00 fcron[8376]:  Job 'test -x /usr/local/bin/run-parts && /usr/local/bin/run-parts /etc/fcron.hourly' started for user root (pid 8377)

Nothing in the mail log (no errors, no attempt to send).

Any insight?

2

There is no logging or output from fcron by default. You can turn it on for troubleshooting but if you leave it on permanently then you could end up filling the logs up very quickly.

See the troubleshooting section of the fcron entry in the IPFire documentation.

https://www.ipfire.org/docs/pkgs/fcron#troubleshooting

3

Thanks, Adolph. I’ve been on that docs page many times and only turn on the logging while troubleshooting.

I’m seeing that fcron is arduously different from cron. I’m not sure what purpose the mailto() and forcemail options serve. In a normal cron (with MAILTO= properly set),

27 * * * * echo "Hello World" && touch /root/test1427

will send an email with Hello World in it (the STDOUT). From the fcron/fcrontab man pages, it would seem it did the same.

There’s only a few scripts that I need the output from and I built a mail command into them. It’s only a few extra lines of code, but it sure would be nice if the mailto option worked as it’s explained in the man page.

4

I found this rather interesting since I have set cron to restart the unbound service - I know: soon irrelevant, but still - so I will poke this a bit and see what can be accomplished.

5

That is the case but the build of fcron in IPFire is done with the option --without-sendmail and therefore the fcron.conf file has the no link to where the sendmail package is located on IPFire.

That seems the simplest option. For all the normal admin tasks that are being run within IPFire, defined in the fcrontab that is provided, there is no requirement to email that any of these updates etc have been triggered.

6

That makes so much sense. I have the sendmail path in fcron.conf but I was wondering if there was a way of disabling the mail function at source/compile. Now I know. Thanks, Adolf!

7

Thanks, SecCon, but no need to research any further. Adolph advised that fcron was compiled without the sendmail option, so any mail-related commands are ignored.

8

I have a working setup. It is running a few tests but pulls crontab event and sends notifications. It should also be upgrade persistent, but I will get back to that after some scheduled tests.

Will have more towards end of week.

9

Thanks Ernie and Adolf — the compile-time --without-sendmail explanation was the missing piece I needed too.

I went ahead and explored further anyway since I had a practical use case: a daily Unbound restart job running under fcronuser. Here is what I - and ClaudeAI - tested extensively and found.

The working solution

While fcron’s internal mailto() is a no-op on IPFire, the mail service itself works fine for script-level notifications. The sendmail binary at /usr/sbin/sendmail is a symlink chain to /usr/sbin/dma (DragonFly Mail Agent), and calling it explicitly from within scripts works correctly — provided the mail relay is configured under System → Mail Service.

The pattern that works:

  #!/bin/bash
  OUTPUT=$(your-command 2>&1)
  EXIT=$?

  if [ $EXIT -eq 0 ]; then
      (echo "From: security@yourdomain.com"
       echo "Subject: [$(hostname)] OK: yourjob $(date '+%Y-%m-%d %H:%M')"
       echo ""
       echo "Status: SUCCESS"
       echo "Output: $OUTPUT") | /usr/sbin/sendmail recipient@yourdomain.com
  else
      (echo "From: security@yourdomain.com"
       echo "Subject: [$(hostname)] FAILED: yourjob $(date '+%Y-%m-%d %H:%M')"
       echo ""
       echo "Status: FAILED (exit $EXIT)"
       echo "Output: $OUTPUT") | /usr/sbin/sendmail recipient@yourdomain.com
  fi

Note that sendmail on IPFire does not accept a -s subject flag — the Subject line must be a header in the message body, with a blank line separating headers from the body.

I have wrapped this into a generic fcron-notify.sh script that takes a job name and command as arguments, so the same wrapper handles all jobs. Still running for a few days to confirm reboot resilience, but working cleanly so far.

A dead man’s switch — alerting when a job does NOT run

This is arguably more useful than completion notifications. A companion watchdog script checks a sentinel file written on each successful run. If the sentinel is missing or stale beyond a threshold (I use 25 hours for daily jobs), it sends an alert.

Sentinel files must live on persistent storage — not /var/run/ (tmpfs, wiped on reboot) and not /tmp/. I use /var/lib/fcronuser/ for this, created with ownership fcronuser:fcronuser.

Two non-obvious gotchas on hardened setups

  1. POLICYOUT firewall rules

If you run a strict outbound whitelist for the firewall’s own traffic (POLICYOUT chain via /etc/sysconfig/firewall.local), port 465 must be explicitly allowed. Without it, DMA silently queues everything in /var/spool/dma/ and never delivers — no error, no warning, jobs appear to work fine. The spool at /var/spool/dma/ is the first place to check if mails disappear.

iptables -I POLICYOUT 1 -p tcp --dport 465 -j ACCEPT

Apply with: /etc/sysconfig/firewall.local reload

  1. fcronuser and the mail group

If running jobs under a dedicated fcronuser (the recommended upgrade-safe approach per IPFire docs), the user must be a member of the mail group. The DMA binary at /usr/sbin/dma is setgid mail — without group membership, sendmail silently fails from non-root users.

usermod -aG mail fcronuser

Security considerations

For those using a dedicated fcronuser account, the following permissions are accumulated and worth being aware of:

  • sudo /etc/init.d/unbound restart (NOPASSWD) — fcronuser can restart Unbound, nothing else. Defined in /etc/sudoers.d/fcronuser.
  • syslogd group membership — required to write to /var/log/messages for log scrubbing jobs. A compromised fcronuser could in theory modify system logs. Mitigated by fcronuser having no login shell (/bin/false) and no interactive access.
  • mail group membership — required to execute the DMA binary. Could theoretically relay mail through the configured SMTP account. Same mitigation applies.

None of these are unreasonable for a dedicated no-shell service account on a single-admin home firewall, but they are worth documenting and understanding. The attack surface is limited to fcron job injection — there is no interactive login path.

Happy to share the full scripts if useful.