You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure if the issue is just CentOS based, but it looks like the only way the scheduling/time field is filled in, is when crons are user crons (from /var/spool/cron). Because of this Crab can't predict if the cron is running as it should.
Not sure if this is because of the "user" field in a /etc/crontab cron or what.
Also, crons only get added via the /etc/crontab file in Crab when the cron executes. Until then it's not within the Crab interface and can't be imported using the CLI crab import command.
Eg /etc/crontab file that doesn't work right with Crab:
SHELL=/usr/local/bin/cron_shell
PYTHONPATH=/usr/share/crab
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/home/user
MAILTO=/dev/null
HOME=/
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
12 * * * * root /usr/bin/disk_check.sh >> /dev/null 2>&1
*/15 * * * * user /usr/bin/command.sh >> /dev/null 2>&1
The text was updated successfully, but these errors were encountered:
There is a --file option for the "crab import" command. This should allow you to specify the file from which to import cron rules, which could be /etc/crontab. For example:
crab import --file /etc/crontab
However the crontab parser doesn't know that it's an /etc/crontab (with user names) rather than a user crontab, so the user names will probably end up as part of the command. That would also mean that Crab variables could not be added to commands in the usual bash style, as they would appear after the user name, and Crab wouldn't see them.
Crab might still be able to recognize the jobs if a CRABID were set for each rule on the preceding line, as that would take precedence over trying to match the command. Alternatively you could import an edited crontab with the user name removed. I could look into adding support for parsing crontabs in this format. It might have to be via another option to the "crab import" command?
Another issue is that Crab would think both jobs are owned by the user who imports the crontab, rather than two separate users. You could try adding a CRABUSERNAME=user variable assignment above the job which runs as "user".
Not sure if the issue is just CentOS based, but it looks like the only way the scheduling/time field is filled in, is when crons are user crons (from /var/spool/cron). Because of this Crab can't predict if the cron is running as it should.
Not sure if this is because of the "user" field in a /etc/crontab cron or what.
Also, crons only get added via the /etc/crontab file in Crab when the cron executes. Until then it's not within the Crab interface and can't be imported using the CLI
crab import
command.Eg /etc/crontab file that doesn't work right with Crab:
The text was updated successfully, but these errors were encountered: