Fcron on new installation not work

Community
1

It seems that fcron.minutely on core 178, installed from new not from update, does not work.
In the folder I have my own script and that of the WIO.
Mine doesn’t run and I noticed that the WIO data also doesn’t update as it should every 15 minutes.
If I run my script by hand it works, it is made executable and does not generate errors.

On the contrary if I put this line:
*/1 * * * * /home/nobody/keep-alive/keep-alive
everything works directly in fcrontab

I tried to launch this line by hand, the one present in fcrontab,
test -x /usr/local/bin/run-parts && /usr/local/bin/run-parts /etc/fcron.minutely
both my script and the WIO script are executed, at this point it seems like something related to fcrontab isn’t working

Crontab services are working.

I tried putting the launch of my script and that of WIO in the fcron.hourly folder, but again nothing happens.

fcron as a service is running, I don’t see any alarms in the log.

I have two other ipfires updated and everything works

Ideas?

2

This command fcrontab -u fcronuser -l will list all the jobs of the user. Change ‘frconuser’ with your own user. What do you see?

You should also activate the logging option and review the logs.

1 Like
3

fcronuser is root, as I suppose.

1 Like
4

The command show me a fcrontab of root

5

I think any type of timer doesen’tworks, in fact even updating the pakfire list doesn’t work.
Do you have any idea how to understand where the error is, I wouldn’t want to have to do it all again from scratch.
Thank you

6

Incorrect system time can affect SSL/TLS certificate validation, potentially disrupting Pakfire’s functionality. To check time synchronization, run the command ntpq -p.

Here’s an example output from my IPFire setup:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        .LOCL.          10 l  47h   64    0    0.000   +0.000   0.000
*crd.circl.lu    94.198.159.10    2 u  667 1024  377   14.577   +1.239   0.574
+192.33.214.47   10.13.100.155    2 u  246 1024  377    9.691   +0.956   0.498

the offset field shows the time difference in milliseconds between your local system and the NTP server. A small offset typically indicates that the time is reasonably synchronized. In my case, around 1 second.

I would also check NTP logs: in the Web Interface /Logs/System Logs/NTP.

1 Like
7

This the command anwser:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        .LOCL.          10 l    9   64    1    0.000   +0.000   0.000
 ntp1.inrim.it   .CTD.            1 u    8   64    1   14.686   -1.234   0.000
 ntp2.inrim.it   .INIT.          16 u    -   64    0    0.000   +0.000   0.000
8

Check if your fcron daemon is running or not.

Run the following command

/etc/init.d/fcron status

You should get something similar to

fcron is running with Process ID(s) 3096.

The process ID will be different in your case.

If you get

/usr/sbin/fcron is not running.

then the daemon is not running and you should run

/etc/init.d/fcron start
You should then see

Starting fcron… [ OK ]

Then rerun the status command again to confirm it is running. If instead of the [ OK ] you get a
red [ FAILED ] message then it indicates that something is stopping your fcron daemon from running.

1 Like
9

fcron is running with Process ID(s) 2798.

10

Anything on the logs? Also, the logs for pakfire.

11

nothing into a log

12

How do you know that pakfire is not working?

13

this morning when the announcement of the core 179 arrived, on my home firewall I found the list of updates compiled, on this firewall on the contrary the packfire update was stopped at 4 days ago, when I installed it

14

then in the system logs/pakfire you should see some error message. Or you are thinking that pakfire did not started at all?

15

no errors in the log, I don’t feel like redoing the installation, I would like to learn how to fix these things, I can’t always use a cannon to hunt a fly HI

16

Without any log messages then it is like trying to hunt the fly without being able to see or hear it.

If the fcron daemon is working then scripts put into the minutely directory should get executed, as long as their permissions and ownerships are okay.

1 Like
17

Let’s confirm if the minutely fcron directory on your system is executing scripts or not.

I ran a test and have a script and result that worked on my system. So if we try the same on your system we will see what occurs.

Create a script with the following lines

#!/bin/bash
echo “$(date)” >> /home/test-file

place it in /etc/fcron.minutely/test and make sure that the ownership is root:root and the permissions are 755.

Then leave it for a few minutes. On my system the date was appended to the file /home/test-file every minute.

Here is the result I got after a few minutes

Tue Sep 26 17:50:00 CEST 2023
Tue Sep 26 17:51:00 CEST 2023
Tue Sep 26 17:52:00 CEST 2023
Tue Sep 26 17:53:00 CEST 2023

If that works for you then fcron and the minutely directory is working and the problem you are experiencing will be due to an error in the script you are using.

If it does not work for you then there is some problem with how fcron is working and I would suggest a re-installation and restore from backup.

2 Likes
18

Not working, I need to reistall all

19

Unfortunately I think re-installation is your best bet.

I would suggest running the above test on your system after installing and before restoring a backup. Just in case there is something in your configuration setup that is causing this, although I can’t imagine what that might be.

:crossed_fingers: that everything works well again after the re-installation.

2 Likes