How to change the time when fcron executes @12h

Is there a way to modify suricata rules updates times for ET community closer to the actual release time?

It is set to update every 12 hours, and lately the updates are out of sync because the actual Updates are getting released a little after IPFire Suricata checks for updates.
Next update cycle will update it, but that’s a long delay.

# Perform a surciata rules update every 12 hours.
@ 12h [ -f "/var/ipfire/red/active" ] && /usr/local/bin/update-ids-ruleset >/dev/null 2>&1

Looking at the ET folder, updates are released around 5PM EST or 10PM GMT {Proofpoint Emerging Threats Rules}

Proofpoint Emerging Threats Rules

Sounds like nobody knows what I am talking about.

Let me rephrase the questions,

Is there a way to change the time when fcrontab executes “every 12 hours” tasks.

It’s odd but my testing IPFire runs updates just on time, right after the new Suricata rules are released.

The other IPFire updates too early, then needs to wait 10 -11 hrs to try again.

Yes, What do you want to change it to?

Here is every 6 hours:

@ 6h [ -f "/var/ipfire/red/active" ] && /usr/local/bin/update-ids-ruleset >/dev/null 2>&1

Make a backup of the fcrontab -e output. If fcrontab is ever updated your changes will be lost (unless you have a backup!).

Also keep in mind this will (may?!?) use lots of resources when updating!

I noticed it uses a lot of resources so I don’t mind every 12 hours.
I just want to move the time when fcrontab starts. the countdown to “every 12 h”

It seems to be a little out of sync

change it to even 11 hours. that might be random enough

Looking at the fcron page about its commands
at the section labelled
" Entries based on elapsed system up time"

The @ 12h portion means run this command every 12 hours of actual elapsed fcron execution time.

So if the IPFire has been turned off for any time that time will be considered as non execution time, so the actual time of the fcron rule being executed will depend on when the machine was first started up and how long it has been turned off in the intervening period.

Therefore different IPFire machines can have different times for running that command depending on when they were first started up and how often they have been turned off.

So you could put it closer to sync by turning the IPFire off for a certain amount of time so that it will try just after a potential release time.


Why not use the standard cron time/date fields? e.g 1 /*12 * * * is 1 minute past midday and midnight. Or you could do something like 1 2,14 * * * which is 1 minute past 2am and 2pm. See the Crontab Guru.

1 Like

Thank you for this suggestion, I couldn’t afford to turn off this IPFire but I was able to stop fcron wait 2 hours and start fcron again

/etc/rc.d/init.d/fcron stop

wait 2 hours

/etc/rc.d/init.d/fcron start

looking at the logs I see that after 13.5 hours of running, the @12 h update was synced. and it has been updating regularly at fcron start time + 1.5 hours

Will the crontab rule created at CrontabGuru work for Fcron as well?

I would be interested to know why the @12h is preferred.
The only reason I could think of is to have each IPFire instance update at a different time, almost randomly. Otherwise all IPFires would start updating at a particular time and folks at Emerging Threats would be annoyed and start blocking our IP’s.???

1 Like

Have a look at the man pages - fcrontab(5) — Arch manual pages

If all IPFire systems will do this at the same time it is like a DOS attack to the downloadservers. So we not want update tasks at the same time on all installations.


lol did you just tell me to RTFM - Wikipedia ?

Not sure how the summer time change affected your fcron jobs.

I noticed that jobs like NTP sync , Suricata update and pakfire were delayed this morning and afternoon by 1 hour.

Like fcron never adjusted to daylight savings time, it stayed in Standard time or maybe UTC.

Not an issue just an observation :slight_smile: