Cron fails silently in environment with jailed shells

[ioweb-gr]

Preconditions (*)

1. OpenMage 20.0.10

Steps to reproduce (*)

1. Enable a jailed shell that's missing some binaries on the target OpenMage installation
2. Add cron.php in a cron job

Expected result (*)

1. Cron runs correctly or throws an error about missing binaries

Actual result (*)

1. Cron fails silently

The problem stems from the fact that the cron.php file only checks if specific php functions are disabled and if bash exists basically.

In my case it would run these two commands

/bin/sh '/httpdocs/cron.sh' 'cron.php' -mdefault 1 > /dev/null 2>&1 & /bin/sh '/httpdocs/cron.sh' 'cron.php' -malways 1 > /dev/null 2>&1 &

Removing the > /dev/null redirection will yield meaningful information that's supressed which would allow the user to know there's something wrong with cron.

In my case again it would be

/httpdocs/cron.sh: 1: /httpdocs/cron.sh: expr: not found
/httpdocs/cron.sh: 46: /httpdocs/cron.sh: ps: not found

Of course in a jailed shell ps would not be available. It might be in Cloudlinux OS but not in chroot or jailkit as it's a security risk.

I think there needs to be some improvement here to check if the required binaries are also available before deciding that cron can run in shell context.

Any ideas?

[ADDISON74]

This was more a request for help than an issue in OpenMage code. For the future please post in Discussions section.

[Flyingmana]

@ADDISON74 please be more carefully with this. There is a clear problem description, steps to reproduce it and explaination why this is a problem.

And I would definitely say, error messages which are hidden by OpenMage are an Issue which should be fixed.

The next steps are now, finding out why we use the pipe to /dev/null there, and what alternatives do we have.

[ioweb-gr]

Indeed it puzzles me why Cron job errors are suppressed. Also I'm not requesting help on this, the workaround is to set isShellDisabled to true when in a jail shell however I do think that if theres a way OpenMage could probably handle this better, I'd like to explore the possibility

[ioweb-gr]

I also forgot to note that this was a Plesk installation on the server so probably all Plesk installations will probably suffer from this if the shell functionality is enabled using chroot. I think it's worth looking into providing better integration with one of the major players in hosting environments

[ioweb-gr]

Because almost all shared hosting providers will limit their shells to prevent privilege escalation to the absolute minimum of applications needed. This can be for cases where you have a business site in WordPress and an eshop in the same hardware. There are eshops with low traffic and a few orders running OpenMage and not all can afford dedicated hardware

Using a jailed shell is a popular practice and you're basically saying the majority of hosting providers setup constitutes a special situation.

Even ignoring the fact that it's a special situation, there exists a situation where OpenMage thinks Cron is running while it's not running, but it should be running and doesn't notify about the error.

[ADDISON74]

I understood your situation, but it will not be solved without the system administrator's help. I think such a situation should be made known to those who are using OM on host sharing so that they can check and determine if they need to ask the system administrator for some extras or not. Once added the OM cron script in account interface it should run as expected. This can be checked in the cron_schedule table or by using the AOE extension (preferably). If this is not working you should ask for system administrator's help.

I personally do not see what changes should be made in OM code to solve this particular situation. Without system administrator you can do nothing. That is why I stated that it is not a problem related to the OM code but a request for help, which should be brought to the attention of others.

If you allow me a tip Magento should be installed on at least one VDS/VPS. Nowadays the costs have dropped dramatically, in addition the control of the virtual machine is preferable for guaranteed resources and especially for security.

[ioweb-gr]

Let me answer a few points of those because I've talked to quite a few system administrators with your concerns because I also thought it was the hosts fault.

Unless you're using cagefs and cloudlinux with jailkit and chroot the ps executable is not considered safe.

Sure you can get a cheap vps or vds running on a Xeon CPU however all of them have extremely low clock speeds as there's an inverse relationship between number of cores and clock speed. Since php runs single threaded you benefit more by semi dedicated shared hosting on high clock speeds than by using a VPS for the same cost roughly.

In any case whether we should all run on VPS or dedicated or cloud solutions is besides the point.

Unless you would like to restrict OpenMage to specific infrastructure I think the site administrator should either be able to choose php Cron or shell Cron execution, or OpenMage should inform about the inability to function in the specific environment.

[fballiano]

I think the question is where did you read to use these commands:

/bin/sh '/httpdocs/cron.sh' 'cron.php' -mdefault 1 > /dev/null 2>&1 &
/bin/sh '/httpdocs/cron.sh' 'cron.php' -malways 1 > /dev/null 2>&1 &

with the redirect to /dev/null? cause maybe we can just fix the doc (if it's in our repos)

[ioweb-gr]

@fballiano I didn't read about them, these are hardcoded in the cron.php file

[fballiano]

perfect, thanks, then I think we should remove the redirection

[ADDISON74]

@ioweb-gr - Could you please check if this PR #2380 solves your issue? I know it comes long after your report but you are in the right position for testing it.