php exec("ps -p {$pid}") not working in cron

[SacAutos]

In another thread, I describe some software that I wrote in PHP to automatically export (via FTP) the backup tar files that Plesk is storing locally on my server (by pretending that it's actually a remote server). One issue that I was having is that sometimes it takes more than 24 hours for all the files to be uploaded to the remote cloud storage.

My response was to create a small file of the current process ID while the cron job was running. Then, at the start of the module, I check to see if that file exists. If it does, that process ID is collected and the php command exec("ps -p {$pid}") is used to determine whether that process is still active. If it is, then gracefully exit to prevent possible transfer duplications.

The testing went well interactively. But I'm getting an error returned when the process is run via cron:

sh: /ps: No such file or directory

What I gather from this is that the ps command (Process Status) appears to be unavailable in the cron shell.

Where do I go from here?? Is there some form of workaround to access ps via the right path? Or is there some other method I can use? Feeling stuck...

 

[burnleyvic]

I'd suspect PHP exec() function is disabled by the admin, it's a common practice especially in shared environments. You can verify this by searching through your web server error log.
Try something else, e.g. rewrite the backup script using lockfiles. The script will try to acquire the lock before starting the backup job and it will release it after the backup is completed.

 

[SacAutos]

Good advice - thank you!

Actually, I'm the system administrator However, your point is well taken. Access to system resources is generally a bad idea. I'll research filelocking instead. Much appreciated!

 

[HostaHost]

The problem you're running into is that in 10.4 a new 'feature' has been added that applies the chrootsh shell to all cron jobs created in the panel, so most jobs executed by cron become useless. Parallels has been nice enough to give us an barely usable command to specify the shell that cron jobs should be run as, however, it only works if the subscription in question is set to forbidden shell access; if you actually want to give a customer chrootsh shell access, the command no longer works, meaning you can choose between restricted access for your customers, or cron jobs that work, but not both. If you do want to try that command, it is:

/usr/local/psa/bin/server_pref -u -crontab-secure-shell /bin/bash

What I did instead was set up a cron job that alters the shell in the cron files every ten minutes back to one that actually works:

 /usr/bin/find /var/spool/cron/ -type f -exec perl -pi -e "s/\/usr\/local\/psa\/bin\/chrootsh/\/bin\/bash/g" {} \;