• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Scheduled Tasks always fail

yabado

Regular Pleskian
Whenever a user in my Cloudlinux powered Plesk Panel 12 tries to use the scheduled tasks, this is the error that is emailed to them...

execl: couldn't exec `/usr/local/psa/bin/chrootsh'
execl: No such file or directory


Does not matter what the task is, same error every time.

Even something as simple as wget http://plesk.com

What is wrong?
 
The chrootsh file does exists and no migration was ever made .

12K -rwsr-x--- 1 root psacln 8.1K Jun 6 2014 /usr/local/psa/bin/chrootsh

So that is not it.
 
Here is what I had to do to fix this. I know it cannot be correct, but now the task fires without error.

Open the site's cron file here...

/var/spool/cron/mysite

The comment out this line

#SHELL=/usr/local/psa/bin/chrootsh

After that the task will work. That SHELL command does not work and breaks everything.

Can someone explain what this does and why it does not work?
 
Hi yabado,

did you as well reconfigure the chrootsh - setting, as suggested in the KB? ( /usr/local/psa/bin/server_pref -u -crontab-secure-shell /usr/local/psa/bin/chrootsh )

Did you try as well to define the complete path to the executable? I.e.: "/usr/bin/wget http://www.example.com/cron.php" ?


The solution you choosed is the way to "trust" your customers to run scripts not only in the chroot - environment.
Instead of editing the file "/var/spool/cron/mysite", you could have used the setting:

/usr/local/psa/bin/server_pref -u -crontab-secure-shell “”

For more possible server preferences, please use the command:

/usr/local/psa/bin/server_pref --help
 
Setting the complete path in the "task" is not he issue.

The job never gets past the 'SHELL=/usr/local/psa/bin/chrootsh' line in the spool file.
 
If I establish this ...

/usr/local/psa/bin/server_pref -u -crontab-secure-shell “”

... will it open my server up to users using malicious scripts that could effect outside their chrooted area?

Or does it just allow them to use binaries outside of their ftp area ( i.e. wget, curl, php, etc... ) ?

Just trying to figure out the safest and best way to allow a user to setup a task, primarily hitting a specific web page every x minutes?

From what I have done so far, it seems nothing will work when the 'SHELL=/usr/local/psa/bin/chrootsh' is in their spool file?
 
Hi yabado,

the provided command does nothing else, than what you did by editing your "/var/spool/cron/mysite" ( #SHELL=/usr/local/psa/bin/chrootsh ), it opens up the chroot and let the users use other binaries as well, apart the ones at "/var/www/vhosts/chroot/bin".

You could try as well to solve your issue by checking and reconfiguring your settings with the tool "chrootmng"

  • Check if your binaries at "/var/www/vhosts/chroot/bin" exist and check as well that the libraries exist at "/var/www/vhosts/chroot/lib". - in case of wget, it should be
Code:
/var/www/vhosts/chroot/usr/lib/liblwres.so.60
/var/www/vhosts/chroot/usr/lib/libdns.so.64
/var/www/vhosts/chroot/usr/lib/libgssapi_krb5.so.2
/var/www/vhosts/chroot/usr/lib/libbind9.so.60
/var/www/vhosts/chroot/usr/lib/libisccfg.so.60
/var/www/vhosts/chroot/usr/lib/libisc.so.60
/var/www/vhosts/chroot/lib/libcap.so.2
/var/www/vhosts/chroot/usr/lib/libxml2.so.2
/var/www/vhosts/chroot/usr/lib/libGeoIP.so.1
/var/www/vhosts/chroot/usr/lib/libkrb5.so.3
/var/www/vhosts/chroot/usr/lib/libk5crypto.so.3
/var/www/vhosts/chroot/lib/libcom_err.so.2
/var/www/vhosts/chroot/usr/lib/libkrb5support.so.0
/var/www/vhosts/chroot/lib/libkeyutils.so.1
/var/www/vhosts/chroot/lib/libresolv.so.2
/var/www/vhosts/chroot/usr/lib/libisccc.so.60

  • Reconfigure the chroot - environment with:
/usr/local/psa/admin/sbin/chrootmng --remove --source=/var/www/vhosts/chroot/ --target=/var/www/vhosts/<domain>
/usr/local/psa/admin/sbin/chrootmng --create --source=/var/www/vhosts/chroot/ --target=/var/www/vhosts/<domain>
  • Reconfigure your server settings:
/usr/local/psa/bin/server_pref -u -crontab-secure-shell /usr/local/psa/bin/chrootsh
  • Setup the cronjob to ( for example! ) :
wget -O /dev/null "http://www.example.com/cron.php"
  • Please make sure, that the domain setting at ""Access to the server over SSH" is set in the domain settings and "/bin/bash" is set, instead of "forbidden"
If you are unsure about this setting, please have a look at:

Please wait up for the next scheduled execution of the cronjob that you just setup and please reply with the result here in the thread.
 
Still getting this error when it runs...

execl: couldn't exec `/usr/local/psa/bin/chrootsh'
execl: No such file or directory

I checked /var/www/vhosts/chroot/bin and /var/www/vhosts/chroot/lib, and they both contain the necessary files.

All I want is for my users to be able to schedule a task, or at very least request a web page, every 5 minutes ( for example ).

I am running Cloudlinux, could that be part of the issue?
 
Turns out is was an issue with CloudLinux. Their support team fixed me up. CageFS prevents the need to use the chroot.
 
Back
Top