Cronjobs - "Could not write cron table"

  • Hi all,

    tonight i updated from 1.4.7 to 1.5.1. The update went fine and all is working perfectly.

    I wanted to create an new Cronjob for an User and the Plugin was gone - my browser said 404. So i logged on as admin and saw that the plugin was deactivated with an Unknown Error.

    That error says:

    1. Plugin::CronJobs::_writeCronTable: Could not write cron table

    Retry didnt helped and ends in the same error.

    Sadly i couldn't find more informations about this error. I searched in /var/log/imscp and found the file "Modules::Plugin_CronJobs.log"

    1. [Tue Nov 7 23:30:09 2017] [debug] Modules::Plugin::_executePluginAction: Executing disable( ) action on Plugin::CronJobs[Tue Nov 7 23:30:09 2017] [debug] Modules::Plugin::_executePluginAction: Executing change( ) action on Plugin::CronJobs[Tue Nov 7 23:30:09 2017] [debug] Modules::Plugin::_executePluginAction: Executing enable( ) action on Plugin::CronJobs

    That was the time i updated imscp. So no informations about whats wrong. Other logs like syslog also have no informationn.

    The Plugin config says that crons are stored in "/var/spool/cron/crontabs". There are all my already created crontabs, but not the new created one. In the Database the new crontab exists with an "tocreate" entry.

    "ls -la /var/spool/ | grep cron" says:

    1. drwxr-xr-x 5 root root 4096 Jun 30 00:15 cron

    Maybe something wrong with the permissions?

    My System Information:

    Debian 8.9
    I-MSCP 1.5.1

    CronJobs 1.4.1 (without InstantSSH!)

    Other installed Plugins:

    LetsEncrypt (3.3.0)
    Mailgraph (1.1.1)
    OpenDKIM (2.0.0)
    PhpSwitcher (4.0.2)
    PolicydWeight (1.2.0)
    Postgrey (1.2.0)
    RoundcubePlugins (2.0.1 )
    SpamAssassin (2.0.1)

    If more information is needed - i will provide it! :)

    (Maybe someone knows which log file i can look to get more information?)

    Thanks a lot in advance for any help!


  • @Feldinos

    Can you try the following:

    • Stop the i-MSCP daemon: service imscp_daemon stop
    • Trigger a retry through plugin management interface
    • Execute perl /var/www/imscp/engine/imscp-rqst-mngr -v

    and provide us with the full output?

    Once done, don't forget to restart the imscp_daemon service.


  • Good Morning Nuxwin,

    thanks for your reply!

    vu2012 was the User with the exsisting crontab before i did the update.
    vu2014 was the User i tried to create an crontab right after the update.


  • @Feldinos

    I don't see any error.

    [DEBUG] Plugin::CronJobs::_writeCronTable: Writing cron table for user: vu2012
    [DEBUG] Plugin::CronJobs::_writeCronTable: Writing cron table for user: vu2014


  • That's the strange thing about it. No information what is wrong.

    If i do an: ls -la /var/spool/cron/crontabs/

    1. drwx-wx--T 2 root crontab 4096 Nov 9 07:06 .
    2. drwxr-xr-x 5 root root 4096 Jun 30 00:15 ..
    3. -rw------- 1 root crontab 1241 Sep 5 06:07 root
    4. -rw------- 1 vu2012 crontab 332 Nov 9 07:06 vu2012

    You see the new cronjob for user vu2014 wasn't written.

    I attached an image with an screenshot of the plugin managment site.

    (Should i maybe set the plugin on disabled via mysql, uninstall and re-install it?)


  • @Feldinos

    No need to reinstall the plugin. Can I access the server for further investigation?


  • @Feldinos

    Problem solved. This was a mistake from you or your customer:


    As you can see in the above screenshot, the command field was wrong. That field MUST not contains any field related to cron datetime: */15 * * * *

    To solve the problem, I've processed as follows:

    • I've changed the status of the cron job through MySQL from toenable to suspended
    • I've run perl /var/www/imscp/engine/imscp-rqst-mngr -v
    • I've edited the cron job to remove the mistaken part
    • I've re-enabled the cron job.

    In next version, I'll improve the workflow a bit:

    • On error, the plugin will not be disabled. Instead, the error message will be shown at customer level, for the specific cron for which there is a failure. That will make the customer able to edit his cron jobs without having to rely on the administrator.

    Note that I've started the imscp_daemon service because you forget to restart it after your test.