Garbage Collector 1,5

I believe this plugin (Garbage Collector 1.5) is now defunct but it was working till recently in Elgg 1.8.13. Now that I have moved to a different server within the same hosting company it no longer works. They suggest I may not have the latest cron library. Where would I find this in Elgg and what is the latest version. Is it easy to replace?

Thanks, Jon

  • I don't think that there's any "cron library" outdated. But you have most likely just not set up the cronjobs on your new server that are required by Elgg. That's why the garbagecollector and logrotate jobs are not triggered anymore. And maybe also why the newsletter plugin is no longer working (https://elgg.org/discussion/view/2630135/extract-email-addresses-as-csv).

    Read http://learn.elgg.org/en/stable/admin/cron.html and set up the cronjobs (for example in CPanel or whatever used on your server to such administrative tasks).

  • Thanks for your suggestions, iionly. According to Croncheck in my Admin Panel the five minute cron for the Newsletter script has been running fine since server transfer. My server admin also added a one minute and fifteen minute cron and they worked fine. The weekly cron for garbagecollector and logrotate has never worked and yesterday I changed the option to "monthly" also editing the cron in C-Panel. It was set to trigger at midnight but did not work.  The weekly cron that worked since 2013 is:

    0=0 20 * * 2 /usr/bin/wget --spider --output-document=/dev/null http://www.westminstercollegeforum.net/wcf/cron/weekly >/dev/null 2>&1

    I'll look into the suggestions and links you sent. Many thanks.

  • Weekly cronjob parameters don't look right to me. First, I don't know about the = character - I think it shouldn't be there. Secondly, the 3rd parameter (20) would mean that the weekly cronjob is only executed on the 20th of a month and due to the 5th parameter (2) only if the 2th is the second day of the week...

    Try it with

    0 0 * * * 2 /usr/bin/wget --spider --output-document=/dev/null http://www.westminstercollegeforum.net/wcf/cron/weekly >/dev/null 2>&1

    or

    0 0 1 * * * /usr/bin/wget --spider --output-document=/dev/null http://www.westminstercollegeforum.net/wcf/cron/monthly >/dev/null 2>&1

  • As I see it the 0= was part of the backup record from the old server and not part of the cron. Don't know why I copied it into my message. C-Panel interface accepts only 5 characters. The original cron that worked for 3 years on the old server was:

    0 20 * * 2 /usr/bin/wget --spider --output-document=/dev/null http://www.westminstercollegeforum.net/wcf/cron/weekly >/dev/null 2>&1

    but it didn't work on the new server. So I tried variations of the hour (second parameter)  and weekday (fifth parameter). None have worked.

    I don't see how I can fit the six characters you suggest in the C-Panel interface. See attached screenshot. Oops, sorry, can't attach here.

  • Sorry. Only 5 parameters actually. I'd added one star to much in the example lines. So, weekly should work with the parameters you gave in your last posting (without the = character).

    Do you see any errors in the server log at the time the weekly cron is supposed to run? Have you tried to execute the weekly cron manually by calling http://www.westminstercollegeforum.net/wcf/cron/weekly in the browser (will work at any time)?

  • I looked all over cPanel but don't seem to have access to the server log. Am on a shared server. I went through the browser as you suggested but can't interpret the result other than the fact it gave a fatal error message. (I've redacted my user and domain name - should have done that before I guess in the cron examples.) Here's a copy:

    Fatal Error.

    Unknown storage engine 'archive'

    QUERY: ALTER TABLE elgg_system_log_1490836514 engine=archive

    DatabaseException Object
    (
    [message:protected] => Unknown storage engine 'archive'

    QUERY: ALTER TABLE elgg_system_log_1490836514 engine=archive
    [string:Exception:private] => exception 'DatabaseException' with message 'Unknown storage engine 'archive'

    QUERY: ALTER TABLE elgg_system_log_1490836514 engine=archive' in /home/xxx/domains/xxx.net/public_html/wcf/engine/lib/database.php:265
    Stack trace:
    #0 /home/xxx/domains/xxx.net/public_html/wcf/engine/lib/database.php(497): execute_query('ALTER TABLE elg...', Resource id #54)
    #1 /home/xxx/domains/xxx.net/public_html/wcf/engine/lib/system_log.php(254): update_data('ALTER TABLE elg...')
    #2 /home/xxx/domains/xxx.net/public_html/wcf/mod/logrotate/start.php(51): archive_log(604800)
    #3 [internal function]: logrotate_archive_cron('cron', 'weekly', '', Array)
    #4 /home/xxx/domains/xxx.net/public_html/wcf/engine/lib/elgglib.php(981): call_user_func_array('logrotate_archi...', Array)
    #5 /home/xxx/domains/xxx.net/public_html/wcf/engine/lib/cron.php(58): elgg_trigger_plugin_hook('cron', 'weekly', Array, '')
    #6 [internal function]: cron_page_handler(Array, 'cron')
    #7 /home/xxx/domains/xxx.net/public_html/wcf/engine/lib/pagehandler.php(53): call_user_func('cron_page_handl...', Array, 'cron')
    #8 /home/xxx/domains/xxx.net/public_html/wcf/engine/handlers/page_handler.php(46): page_handler('cron', 'weekly')
    #9 {main}
    [code:protected] => 0
    [file:protected] => /home/xxx/domains/xxx.net/public_html/wcf/engine/lib/database.php
    [line:protected] => 265
    [trace:Exception:private] => Array
    (
    [0] => Array
    (
    [file] => /home/xxx/domains/xxx.net/public_html/wcf/engine/lib/database.php
    [line] => 497
    [function] => execute_query
    [args] => Array
    (
    [0] => ALTER TABLE elgg_system_log_1490836514 engine=archive
    [1] => Resource id #54
    )

    )

    [1] => Array
    (
    [file] => /home/xxx/domains/xxx.net/public_html/wcf/engine/lib/system_log.php
    [line] => 254
    [function] => update_data
    [args] => Array
    (
    [0] => ALTER TABLE elgg_system_log_1490836514 engine=archive
    )

    )

    [2] => Array
    (
    [file] => /home/xxx/domains/xxx.net/public_html/wcf/mod/logrotate/start.php
    [line] => 51
    [function] => archive_log
    [args] => Array
    (
    [0] => 604800
    )

    )

    [3] => Array
    (
    [function] => logrotate_archive_cron
    [args] => Array
    (
    [0] => cron
    [1] => weekly
    [2] =>
    [3] => Array
    (
    [time] => 1490836514
    )

    )

    )

    [4] => Array
    (
    [file] => /home/xxx/domains/xxx.net/public_html/wcf/engine/lib/elgglib.php
    [line] => 981
    [function] => call_user_func_array
    [args] => Array
    (
    [0] => logrotate_archive_cron
    [1] => Array
    (
    [0] => cron
    [1] => weekly
    [2] =>
    [3] => Array
    (
    [time] => 1490836514
    )

    )

    )

    )

    [5] => Array
    (
    [file] => /home/xxx/domains/xxx.net/public_html/wcf/engine/lib/cron.php
    [line] => 58
    [function] => elgg_trigger_plugin_hook
    [args] => Array
    (
    [0] => cron
    [1] => weekly
    [2] => Array
    (
    [time] => 1490836514
    )

    [3] =>
    )

    )

    [6] => Array
    (
    [function] => cron_page_handler
    [args] => Array
    (
    [0] => Array
    (
    [0] => weekly
    )

    [1] => cron
    )

    )

    [7] => Array
    (
    [file] => /home/xxx/domains/xxx.net/public_html/wcf/engine/lib/pagehandler.php
    [line] => 53
    [function] => call_user_func
    [args] => Array
    (
    [0] => cron_page_handler
    [1] => Array
    (
    [0] => weekly
    )

    [2] => cron
    )

    )

    [8] => Array
    (
    [file] => /home/xxx/domains/xxx.net/public_html/wcf/engine/handlers/page_handler.php
    [line] => 46
    [function] => page_handler
    [args] => Array
    (
    [0] => cron
    [1] => weekly
    )

    )

    )

    [previous:Exception:private] =>
    )

  • The database server (e.g. mysql or mariadb) supports different engines for different purposes. But it depends on the configuration of the database server which of these engines are enabled and can be used.

    Elgg makes use of two engines: the myisam storage engine is used for almost all database tables. But there's also the archive engine used for the tables created by the logrotate table when it cleans up the log table in the Elgg database. And here's now the problem that's occuring on your site: the archive engine isn't enabled in the database server configuration. As you are on a shared server you will most likely not be allowed to change the configuration of the database server. I can only suggest for you to contact the support of your webhoster and ask them if they agree on enabling the archive engine or if they have an alternative suggestion (which might mean to change the hosting plan or to move to another server).

    The fatal error you see when trying to run the cron job manually is very likely also occuring when the cronjob is triggered by the cron daemon and that's the reason the cronjob appears to not being executed. Actually, it is most likely started but fails to complete.

    I don't know if disabling the logrotate plugin will "fix" the issue. There might no new elgg_system_log backup tables created but the garbagecollector plugin might try to access any existing log backup table nonetheless. You can delete the elgg_system_log_<timestamp number> tables (but NOT the elgg_system_log table!!!). If the logrotate plugin is disabled there shouldn't be new backups created. But then the system log table with increase (and might get quite large as it's no longer cleaned up). With my No Logging plugin (https://elgg.org/plugins/1441338) you can stop (almost all) log entries added to the log table. But a good long term solution (even when using the No Logging plugin) is in any case getting the archive engine enabled on the server your site is hosted on (even if this means to move to another server or even webhoster).

  • P.S. you should also ask the support of your webhoster about the system logs (Apache access log and error log, Mysql log, mail log, PHP log) when asking about the archive engine of the database server. It's always good to know where the logs are saved - and if they are even saved. If something goes wrong, a look into the logs often helps. And it also never hurts to look into the logs once in a while even if everything seems to run fine to check what goes on on the server.

  • Very many thanks iionly for taking the time to explain all this. I have informed my server admin of these points regarding Elgg server requirements. I'm hoping he will  enable the archive engine in my case. After all it seems odd that he wouldn't if it was enabled on the old server I was recently transferred from. Also it was his idea to move me as I hadn't been able to get Let's Encrypt SSL going in Direct Admin. He said it was much easier in cPanel, which indeed it was. I felt I had to go with SSL with the new browser versions popping up those scary warnings on password and all other text input fields! (My Elgg site had never been compromised in four years).

     

     

  • My server admin has replied:

    "If the problem is only the storage engine ARCHIVE, i can move your diskspace to another server, where this storage is enabled."

    Do you think we can pretty well guarantee the weekly cron for garbage collector will work if he does this? I don't look forward to yet another move!

    I'm almost ready to give up on v1.8 and install the latest. Think I could import members as have successfully extracted csv file of members and emails but I'd loose all other data from past  four years.