cron job environment won't let scripts run

Discussion in 'General' started by Jigal van Hemert, Aug 7, 2016.

  1. Jigal van Hemert

    Jigal van Hemert New Member

    I set up an Ubuntu 16.10 server with the excellent tutorial for The Perfect Server. Now I try to run the cron job for the cms TYPO3 and I run into some problems.
    At first I attempt to run:
    php [web_root]/typo3/cli_dispatch.phpsh scheduler
    This results in the problem that absolutely no .ini files are loaded and PHP tries to run with zero extensions. I also tried php7.0 as the interpreter and various paths to php, but all with the same result. It could easily be demonstrated by running php -i as cron job.
    Since the script can also be run as a shell script I tried that too. The script starts with:
    #! /usr/bin/env php
    which should be a portable way of running php. Unfortunately the effect is that the cron error log shows:
    /bin/bash: /web/typo3/cli_dispatch.phpsh: /usr/bin/env: bad interpreter: No such file or directory
    The /usr/bin/env exists and works, but not for the cron user/environment.

    I read somewhere that ISPConfig 3 lets cron run in a "jailed environment". Is this the cause for this behaviour? If so, how can I release cron from jail and end its stay in the penitentiary institution?
  2. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    I don't know that you can, I think shell commands run in jailkit by design, so probably the right thing to do is fix your jailkit environment. It sounds like you don't have /usr/bin/env there, so add that and make sure there is a 'php' command as well (it's probably a symlink to php5 or php7 or such).
  3. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

  4. Jigal van Hemert

    Jigal van Hemert New Member

    Thanks for pointing me in a right direction.
    One step (big step) further.

    [ php]
    comment = the php interpreter and libraries
    executables = /usr/bin/php
    directories = /usr/lib/php, /usr/share/php, /etc/php, /usr/share/zoneinfo
    includesections = env

    comment = environment variables
    executables = /usr/bin/env

    to the /etc/jailkit/jk_init.ini file, ran
    jk_init -c /etc/jailkit/jk_init.ini -f -k -j /var/www/clients/client1/web1 php
    (also for the other user)

    And now PHP 7 can be run with all ini files loaded.

    Database connection is still an issue:
    The current username, password or host was not accepted when the connection to the database was attempted to be established!

    I've already switched from localhost to as someone in a thread suggested, but that didn't make a difference.
    I guess it's back to debugging the TYPO3 CLI bootstrap to see if the credentials are not found.[/php]
  5. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    On a related note, I see /usr/bin/php in ispconfig's default `Jailkit cron chrooted applications` list under Server Config, but in testing a chroot'd login, I don't have /usr/bin/php present. Is something broken there? I actually expected it to fail because /usr/lib/php wasn't included, but the interepreter itself (or rather symlink to /etc/alternatives) isn't there, nor /usr/share/php.
  6. Jigal van Hemert

    Jigal van Hemert New Member

    After configuring both of the websites that need to be running (plus Apache Solr) I'm back to fixing the cron jobs.
    Things are getting weird. Both sites are TYPO3 installations with exactly the same version. For TYPO3 each installation has one cron job that calls a cli_dispatch.phpsh script every 5th minute which runs jobs from a scheduler module. From here both installations are different (different jobs in the scheduler module).
    Installation one keeps telling in the private/cron.log that the database credentials are incorrect.
    Installation two is pretty silent.
    I tried to run the dispatch script of both installations from the command line as root user and everything ran fine.
    This afternoon the cronjob of installation two suddenly ran on its own with success. After that it didn't happen again. I have no idea what to check and what to change.
  7. till

    till Super Moderator Staff Member ISPConfig Developer

    You mean you run the certbot or letsencrypt script on the shell to create a cert? Doing this disables the ability to create letsencrypt certs trough ispconfig.
  8. Jigal van Hemert

    Jigal van Hemert New Member

    No, I have two different problems at the moment and both have a separate thread.
    This thread is about running the cron job for the TYPO3 scheduler. TYPO3 has it's own handler for tasks (the Scheduler module) which uses a central script named cli_dispatch.phpsh .
    Because I know that the sysadmins at work run all cron jobs as a system user (I think it's 'root') I tried to run the cli_dispatch.phpsh script from the command line to see if there would be any problems reported because of PHP cli configuration problems. This wasn't the case. The problem seems to still be with the jailed environment for the cron jobs.
    As mentioned above, yesterday it suddenly ran successfully for one of the two sites, but only one time. It's scheduled for */5 * * * * but it hasn't run since. The cron_error.log in /var/www/clients/client2/web5/private/ is empty.
  9. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    You say the cronjob ran fine as root - was that from within the jailkit environment? If not, try creating a user with the same jailkit login environment, su to (or ssh login as) that user and run the same script as the cronjob to see if there are errors. You might even create a test cronjob running every */5 that just does "touch /tmp/yes-cron-is-running" or similar, to make sure the timestamp changes / cron is working.
  10. Jigal van Hemert

    Jigal van Hemert New Member

    For some unknown reason it works now. I did restart apache to activate a minor change in php.ini . Maybe that was enough to trigger some caches.
    Thank you both for the help!

Share This Page