Luuk
OK so I was totally wrong, my method won't work. I've tried it in crontab on a few systems and it fails miserably. 😐
DON'T:
First red herring to be aware of: try doing crontab -e as logged in user via SSH to the website OR changing into that user and trying to crontab -e, it wont' work. you'll get some cron jobs show, but not others and it's basically a sh.t show. save you sanity and just don't.
DO:
login to CP as root and issue the following command sudo crontab -u <user> -e this will load up the correct crontab file which is actually /var/spool/cron/crontabs/<user> it says to NOT directly edit this file if you try with vim directly, I tried it, it did keep what I wanted, but use the crontab -u <user> -e method as that more likely correct and edits that file anyway in the end, it first edits /tmp/crontab.<random_string>/crontab, but ends up in that /var/spool/cron/crontabs/<user>. If you add and remove cronjobs from the UI they will load and disappear in that file correctly. Using this command to remove something that was added in the UI, will remove it too from the UI.
Good news for you is you CAN issue your command via this method and it will work as the website user.
I've restarted the PHP container and I've moved the container and the cron job stays and works, it doesn't show within the UI though. Adding and removing jobs via the UI didn't undo it either.
I used this to test:
*/1 * */32,1-7 * 3 echo "foo" >> ~/test-cron.log
*/1 * */32,1-7 * 1 echo "bar" >> ~/test-cron.log
Never got bar which was to be expected if it's working correctly. It's Wednesday 😃
** Although I can't find any reason not to edit the crontab as I've described, adding and removing cronjobs via UI didn't effect it, moving and restarting didn't affect it. There MIGHT be some other edge case where this could fail. Enhance is still unknown in some of the things it does. If in doubt check with @Adam via a ticket.
Sorry to be wrong at the start, hope to have helped in the end.
