Problem with PHP "Scheduled Tasks"

[Sergio Manzi]

I have a PHP script I need to run monthly.

I've set it up in "Scheduled Tasks", and when I test it from inside the configuration page (Run Now button) everything is ok, but when I save it (OK button) and try to run it from the Scheduled Task list (Run Now link), it miserably fails with the following diagnostic:

-: /opt/plesk/php/5.6/bin/php: No such file or directory​

If instead of the PHP 5.6.23 I choose PHP 5.4.16 by OS vendor, then I get:

-: /usr/bin/php: No such file or directory​

 

[Sergio Manzi]

"solved" by changing permissions and default shell in service plan from /bin/bash (chroot) to /bin/bash, but.... is this expected??

 

[Sergio Manzi]

ouch... I've reset the service plan to the chrooted shell, deleted the task, re-created the task and everything is fine...

Can't replicate the issue right now. I'll dig deeper...

 

[Sergio Manzi]

... and, discussing with myself and whomever potentially interested, it seems that shell settings doesn't have anything to do with my issue, while there is another condition that consistently generate the problem (at least with my script and settings), i.e.adding an "argument" to the PHP script.

• Without any argument the script runs perfectly.
• With an argument ("-quiet" in my case) the script runs if invoked from within the configuration page, but generates the problem when run from cron or from the scheduled tasks list

very strange and apparently unbelievable behaviour, I admit, but if sombody can please confirm this, I think this should be reopened as an "issue".

P.S.: I think I initially was mislead by myself performing the different tests while sometime using and sometime not the script argument: a very bad methodological mistake.

P.P.S: Where are the per-subscription cron jobs configured? I mean, which file does contain the list and parameteres of the scheduled tasks? Or is it just database stuff (the ScheduledTasks table)?

 

[UFHH01]

Hi Sergio Manzi,

P.P.S: Where are the per-subscription cron jobs configured? I mean, which file does contain the list and parameteres of the scheduled tasks? Or is it just database stuff (the ScheduledTasks table)?

Cronjobs are stored on your server and the "cron daemon" is responsible to trigger cronjobs. Consider to list cronjobs as followed:

As user "root" over the command line:

To list all crontabs for the user "root" on your server:

crontab -l

To list all cronjobs for the user "USERNAME"

crontab -u USERNAME -l

In addition, you can find additional system-wide cronjobs at "/etc/cron.d" "/etc/cron.daily" "/etc/cron.hourly" "/etc/cron.monthly" and "/etc/cron.weekly".

The cronjobs for the system-users on your server are stored at "/var/spool/cron/crontabs/".
Each subscription has it's own system-user, so that you will find defined, depending cronjobs at the above location.

... while there is another condition that consistently generate the problem (at least with my script and settings), i.e.adding an "argument" to the PHP script.

• Without any argument the script runs perfectly.
• With an argument ("-quiet" in my case) the script runs if invoked from within the configuration page, but generates the problem when run from cron or from the scheduled tasks list

very strange and apparently unbelievable behaviour, I admit, but if sombody can please confirm this, I think this should be reopened as an "issue".

Pls. keep in mind, that "quiet mode" ( => "-q" ) for example is a STANDARD command line option for PHP commands over the command line - it is not even mentionend anymore in the manual pages.

Pls. see => http://php.net/manual/en/features.commandline.differences.php

CLI is started up in quiet mode by default, though the -q and --no-header switches are kept for compatibility so that it is possible to use older CGI scripts.

Possible CLI options for PHP are listed at:
=> http://php.net/manual/en/features.commandline.options.php

 

[Sergio Manzi]

Hello UFHH01,

thanks for the info!

As you've surely understood I'm not a great Linux sysadmin, so thanks particularly for the info about each user's cron configuration.

The '-quiet' option I'm referring is not meant as a php-cli option, but as an option passed to the PHP script itself, accessed through the standard POSIX mechanism, the $argc and $argv globals.

without that option the cron job is listed as:

/opt/plesk/php/5.6/bin/php -f 'httpdocs/cli/some-backup.php' > /dev/null​

when I add the -quiet option in Plesk's "Scheduled Tasks" configuration page, I'm getting:

/opt/plesk/php/5.6/bin/php -f 'httpdocs/cli/some-backup.php' -- '-quiet' > /dev/null​

and this too seems to be perfectly correct, but I'm getting the above mentioned error.

So I tried substituting the original PHP script with a simple one just printing out the passed arguments:

<?php

global $argc, $argv;

echo "argc = {$argc}\n";

for ($i = 1; $i < $argc; $i++) {
  echo "argv[{$i}] = {$argv[$i]}\n";
}

This does work, both from the configuration page and from the tasks list...

At this point I'm suspecting something wrong in the original backup script and thus I'll try to have its developer to look into the issue (a tough job, believe me...)

I'm really sorry for having disturbed about an issue which doesn't seems to be Plesk related at all...

Regards,

Sergio

 

[Sergio Manzi]

I thought this was solved, while actually it isn't...

Can someone please try and confirm this is an issue?

• create an httpdocs/cli/test.php file with the content as in the previous post
• create a scheduled task running the above php file (PHP version doesn't seems to matter) with the following arguments: --profile 2 (be sure to have "Notify: Every time", so you can examine output...)
  
• save the scheduled task (OK button...)
• if you wish, verify your crontab file (/var/spool/cron/username). Mine is like that:

0  0  *  *  *  /opt/plesk/php/5.6/bin/php -f 'httpdocs/cli/test.php' -- '--profile' '2'

• run the cron job by clicking on the "Run Now" link
  
• output will be something like this:

-: /opt/plesk/php/5.6/bin/php: No such file or directory

• Now try editing the task and run it from inside the edit window ("Run Now" button).
• Task will succeed and output will be something like this:

argc = 3
argv[1] = --profile
argv[2] = 2

• If the task is left to execute automatically it will fail too...

 

[Sergio Manzi]

As a follow-up, I got in touch with tech support and they could duplicate the issue.

I'll post here if/when a solution will be found.

Cheers!

Sergio

 

[Bitpalast]

Assuming you are speaking of the admin scheduled tasks panel, have you tried to not to run your PHP script as a "PHP script", but as a system command like this?

/usr/bin/php /path/to/script/test.php --oneparameter --anotherparameter --thirdparameter

This will not enclose parameters in quotes and execute properly.

 

[Sergio Manzi]

Hello @Peter Debik!

Yes, I tried fiddling with something like that, but TBH I wasn't able to find the good path to PHP...

Keep in mind that the affected subscriptions have been declared to use "/bin/bash (chrooted)" and thus /usr/bin/php isn't available...

 

[Bitpalast]

Just did many tests on this, very interesting issue (bug), I wonder why none of our customers has brought that up until now. It is not working right, I can confirm that. Solution by Plesk team needed.

 

[Sergio Manzi]

It is not working right, I can confirm that. Solution by Plesk team needed.

In theory they are working on it: issue has been acknowledged and is being escalated.

I'll post back here as soon as they have a working solution.

Thanks!

 

[Sergio Manzi]

A solution (I consider it just a temporary emergency patch) has been proposed:

cp -a /usr/bin/php* /var/www/vhosts/chroot/bin/
cp -a /usr/lib64/* /var/www/vhosts/chroot/lib64/        # <===  ouch!!!
mkdir -p /var/www/vhosts/chroot/opt/plesk/php/
cp -a /opt/plesk/php/* /var/www/vhosts/chroot/opt/plesk/php/

# Apply changes to a domain you need this to work on:
/usr/local/psa/admin/sbin/chrootmng --create --source=/var/www/vhosts/chroot --target=/var/www/vhosts/example.com  # <=== change "example.com" with your domain

It solve the issue, but:

• I'm wondering how much "jailed" the chrooted enviro will be after that
• I don't think PHP updates will be mirrored to the chrooted shell, when released

 

[Sergio Manzi]

A quick update to inform those who are interested that the issue has been escalated to "developers", also because of a possible (no hard facts about that) minor security issue discovered in the meanwhile.

Next update expected within two working days.

 

[Sergio Manzi]

Latest update:

The case has been analysed further, and submitted to developers as an internal issue with id #PPPM-4887; the fix is considered to be included in one of the next Plesk updates.

I guess that's good news, but my original ticket is now set as "Pending confirmation by customer" (which I find slightly ironic): I'll appreciate if someone with more experience in dealing with Plesk support could hint on what that usually means: days? weeks? months?

 

[Sergio Manzi]

There is now an official KB article about this (and related) issue: https://kb.plesk.com/en/129693

The article exposes the (mild) security issue I was citing above, i.e. that scheduled tasks executed from their edit window are run under /bin/sh even if the chosen one is the chrooted one (/usr/local/psa/bin/chrootsh).

The article also provides a workaround for making PHP tasks with arguments work, but, IMHO, it does it the wrong way, i.e. by forcing the "bin/sh" under which the issue does not appear.

I think, anyway, that this can be a security issue as customers who are declared to use "/bin/bash (chrooted)" to limit the commands they can use while logged in and/or in their scheduled tasks, now have full access to whatever command/program they want.

This, unless there is no other safety layer I'm not aware of and that negates/mitigates the issue.

 

[ALAA_20]

hello we want to append via php script a sheduled task but under root subscription, cause with other user it doesn't run, thanks for help