Resolved Crontab works partially

[Erwan]

Hi all,

We have a strange problem on a server (Obsidian 18.0.29).
Several cron jobs are defined in the hosting. Some work perfectly, others only run when you manually start the task (with the panel and the button "run now").
I have disabled and restarted the cron service but it doesn't change anything.

An idea of the problem?

Erwan

 

[IgorG]

I would specify the full script path there.

 

[Erwan]

Igor,
This does not change the operation: manual launch via "Run now" works, no launch otherwise despite the fact that the script is active.

 

[Erwan]

We have 15 tasks with the same file and different args.
Could this be the problem?

 

[Bitpalast]

no launch otherwise despite the fact that the script is active.

Could you please precisely explain what is happening? From your description I understand that the script is indeed starting, but then it does not do anything. What is the output of the cronjob? Is the script actually running, what does the process list (#ps aux | grep name_of_your_script) say?

 

[Erwan]

Peter,

> Task don't work automatically; the task does not run every 5 minutes. In fact never.
> Task works when i click on "Run now" in the plesk panel.

When i look the process list (#ps aux | grep php), i don't find the task...
Very strange.

I found another task which worked for up to 2 days and which is in the same case while nothing has been modified except adding processing with the same file (args differents) with the same frequency...
Others works...

I tested by disabling anothers tasks to see if that changes anything... no
No charge on the server: load average: 0,08, 0,13, 0,13

 

[Bitpalast]

Maybe the job's script is running, but exits right after start because it is missing something when run from the crontab environment. I'd replace the script with a very simple one that only writes something to a defined location on disk to check whether the script IS running or whether the script really is not running. From my previous experience in such cases, the problem is in the script, not with the crontab execution.

 

[Erwan]

Peter,
I agree but...

I've create a very simple php script:
<?php
mail("[email protected]", "Control execution", "Date: ".date("Y-m-d H:i:s"));
?>

I've create a cronjob (attach file) to call this script.
When i click on "Run now", i receive the email.
Otherwise no email while the task is active...

NB: i also restart the server. No change.
Crazy...

 

[Erwan]

So, i'm back with always the problem...

Another strange thing:
- i create a task (attach file: screen1)
- if i click on "Run now", it works.
- if i click now on "Active" and after on "Ok", i've the message: "Information: The scheduled task was successfully updated.".
- But in the list of Scheduled Tasks, the task is desactivated (attach file: screen2). If i return inside (screen3):
> task desactivated
> PHP version is not 7.3 (5.4)
> argument with quotes...

An idea of the problem?

Erwan

 

[Bitpalast]

Your screenshots show that you have not checked the "Active" checkbox.
So what you are saying is that you check the "Active" checkbox, then click "OK", then go back into the task and it is "inactive" again?
What happens when you click on the white "X" in the dark circle in the list of tasks? It should turn into green (activates the task).

 

[Erwan]

Peter,

So what you are saying is that you check the "Active" checkbox, then click "OK", then go back into the task and it is "inactive" again?
>> yes

What happens when you click on the white "X" in the dark circle in the list of tasks? It should turn into green (activates the task).
>> same thing. Message on the top: Information: "The scheduled task extranet.mydomain.fr/bin/sage_synchro.php was switched on."
But the "X" in the dark circle is still here an the task not active...
It's delusional.
We have been using Plesk for over 10 years on dozens of servers and we have never seen this ...

Are there any logs somewhere of these actions?

 

[Bitpalast]

/var/log/plesk/panel.log could show something.

Have you verified that the cron service is running at all?

Scheduled tasks do not start automatically on Plesk for Linux server

Applicable to: Plesk for Linux Symptoms On a Plesk for Linux server, scheduled tasks do not start automatically, including scheduled backup or statistics tasks. If a scheduled task is starte...

support.plesk.com

 

[Erwan]

In the panel.log, only:

Service running:
# service crond status
Redirecting to /bin/systemctl status crond.service
● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
Active: active (running) since mer. 2020-10-21 08:35:41 CEST; 3 weeks 1 days ago
Main PID: 950 (crond)
Memory: 11.6M
CGroup: /system.slice/crond.service
└─950 /usr/sbin/crond -n

nov. 12 13:27:01 w800 crond[950]: (client) RELOAD (/var/spool/cron/client)
nov. 12 13:29:01 w800 crond[950]: (client) RELOAD (/var/spool/cron/client)
nov. 12 13:30:01 w800 crond[950]: (client) RELOAD (/var/spool/cron/client)
nov. 12 13:36:01 w800 crond[950]: (client) RELOAD (/var/spool/cron/client)
nov. 12 13:37:01 w800 crond[950]: (client) RELOAD (/var/spool/cron/client)
nov. 12 13:49:01 w800 crond[950]: (client) RELOAD (/var/spool/cron/client)
nov. 12 13:53:01 w800 crond[950]: (client) RELOAD (/var/spool/cron/client)
nov. 12 14:02:01 w800 crond[950]: (client) RELOAD (/var/spool/cron/client)
nov. 12 14:09:01 w800 crond[950]: (client) RELOAD (/var/spool/cron/client)
nov. 12 14:10:01 w800 crond[950]: (client) RELOAD (/var/spool/cron/client)

 

[Erwan]

Only:
[2020-11-12 13:18:01.345] ERR [panel] Protocol version '1.6.8.0' is deprecated. Current protocol version is '1.6.9.1'.

 

[Bitpalast]

No issues in the panel log, cron running, all other settings correct. This will need an investigation on your server. Please submit a ticket to Plesk support.

How to get support directly from Plesk?

Question How to get support directly from Plesk? Answer Lease-type Plesk licenses purchased directly from Plesk running on supported Plesk version include full free support. Perpetual-type license...

support.plesk.com

 

[Martin Dias]

I suspect that after a suspension of the domain the PSA lock was not removed correctly, something like this:

root@mail ~ # cat /var/spool/cron/crontabs/jdoe
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (- installed on Thu Nov 12 18:54:32 2020)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
MAILTO=""
SHELL="/opt/psa/bin/chrootsh"
##!PSA!##0      0       *       *       *       test

With the ##!PSA!## there I can reproduce the issue of enabling it but it stays disabled.
Can you check that?

 

[Bitpalast]

As @Arashi now mentions it I remember cases like this with our customers. But in these cases the domains were actually disabled and/or the main domain was disabled which lead to it. I forgot all about it, because last time I had seen it must be three or four years ago.

 

[Erwan]

Yes it seems to be the problem...
In fact, the main domain (not the one we are working on - subdomain) will only point to the server when going into production.
We have a lot of ##!PSA!## in the file...

Thanks a lot !!!!!