• Hi,
    My website gets crashed daily at a specific time. The SQl killed queries shows the killed query:
    wp-otionsSEToption_value= '1453383390.8738820552825927734375' WHEREoption_name` = ‘_transient_doing_cron’
    with different option value for each killed query. This causes server overload and website crashes.
    What is the problem and solution to it?
    I have already disabled wp-cron and run a daily cron job from my server only.

    Thanks in advance
    Neeraj

Viewing 7 replies - 1 through 7 (of 7 total)
  • Hello, Neeraj, & welcome to the WordPress support forum. Please accept my apologies for the delayed response. As volunteers, sometimes life gets in the way of being able to respond to requests for help as quickly as we’d like.

    I think the first thing that might be helpful is to provide us w/your site url. In addition, error logs in your web folders and/or in your control panel might also prove helpful. It’d also be good to know what sort of hosting you have, i.e., shared, VPS, etc.

    Thread Starter nikmadan

    (@nikmadan)

    Hi Jackie,
    Just lost the contact as my post was not replied for a few days.. just checked and found your reply.. Thanks for the same…
    It will be nice if you could help me with this… i am still struggling with the problem despite everything that i could imagine..
    If i put my wp_options for repair, it fixes the issue for 1 day.. next day the same problem…

    my website: http://www.aceachievers.in
    Hosting: Shared; Hostgator
    Below is the near daily error log

    localhost 2016-03-08 12:08:13 mand:Query :INSERT wp_options(option_name,option_value,autoload) VALUES ('_transient_doing_cron', '1457438871.6845641136169433593750', 'yes') ON DUPLICATE KEY UPDATEoption_name= VALUES(option_name),option_value= VALUES(option_value),autoload= VALUES(autoload`)

    localhost 2016-03-08 12:09:53 mand:Query :INSERT wp_options(option_name,option_value,autoload) VALUES ('_transient_doing_cron', '1457438968.8348429203033447265625', 'yes') ON DUPLICATE KEY UPDATEoption_name= VALUES(option_name),option_value= VALUES(option_value),autoload= VALUES(autoload`)

    localhost 2016-03-08 12:10:08 mand:Query :INSERT wp_options(option_name,option_value,autoload) VALUES ('_transient_doing_cron', '1457438985.6655321121215820312500', 'yes') ON DUPLICATE KEY UPDATEoption_name= VALUES(option_name),option_value= VALUES(option_value),autoload= VALUES(autoload`)

    The same query for a different transient keeps getting killed.. I have deleted all the transients too but it keeps on propping again and again…

    Thanks in advance
    Neeraj

    Hi, neeraj.

    Since I’m guessing you don’t have shell access on that account, let’s try this.

    * Please go to your CPanel, then PHPMyadmin.
    * Choose the database for your site.
    * Tick the checkbox beside the wp_options table, then choose repair from the dropdown.

    I notice you’ve actually got 2 sites, so you might wish to try this for both.

    We’ll try our best to help you solve this. Let us know how this goes, won’t you?

    All the best.

    Thread Starter nikmadan

    (@nikmadan)

    Dear Jackie,
    I have already been doing this (putting Wp-Options on repair) everyday to keep my site afloat. That ways it works fine for 1 day… next day more bowlful of killed sql queries and crashed website….

    And the 2nd site I made was just so that I could offload my primary site from traffic. It was born out of compulsion rather than need!!!
    And I have a third site too!!! That one is my Webstore.

    Incidentally when the first site drops, the other 2 keep working although a bit slowly. I must remind that all of them are on the same server and domain.

    I have shell access on my C Panel but have never used it as I am not too sure about it and dont know how to use it optimally. Like all central access lines, touching it may have far reaching consequences so I never get into it.

    Please let me know what more can I do?

    Thanks
    Neeraj

    Thread Starter nikmadan

    (@nikmadan)

    And yes, must remind you that some months back I had a virus attack on the site. That I repaired using the anti virus scanner on my hosting account. Since then no more virus attacks but this problem started only after that.
    Thanks

    Well, Neeraj, that was important information, & I don’t believe I knew that until now. It rather changes everything.

    Despite your having run an antivirus, I rather suspect your site is not fixed. Specifically, those programs can’t search the database to determine if any compromise still exists there. Nor can they search outside the WordPress installation. So my suspicion is that the site is still compromised.

    I am going to paste a very long article that I wrote on the subject of repairing a compromised site below. Though it’s long, follow the instructions step by step, & hopefully it won’t get overwhelming. Be that as it may, please follow up w/us if you require additional assistance. Fixing a site compromise is not easy, but it can be done w/persistence. Good luck, &, again, don’t hesitate to follow up w/us if you need more help.

    In addition to this article, a resource you can go to is:
    http://codex.wordpress.org/FAQ_My_site_was_hacked

    When dealing w/a site compromise, the objectives are twofold:
    1) Fix the site; &
    2) Fix backdoors that the hacker used to gain entrance into your site, so this hopefully will not happen again.

    Most people place great emphasis on objective #1, but, in truth, the 2nd one is actually the most important, as, without it, your site will continue to be reinfected.

    Here are the steps to take.

    First, notify your host, as this might be a serverside hack as opposed to simply a site compromise. Also, if you’re on shared hosting, the hack has the potential to compromise the entire server. Additionally, you may wish to take the site offline, & your host can help you do this. They might not help you–then again, they might. You won’t know unless you notify them. If they say it’s not their responsibility, (& it really may not be), then please continue reading.

    Second, scan any devices you will use to log onto your website for malware. It does no good to change credentials, etc., which you will need to do, if malware phones them home to their command & control center. It’s actually better to do more than 1 scan, each using a different program, as no single malware scanner can detect everything.

    Third, secure your network. Definitively use secure FTP as opposed to regular FTP. The port used for secure FTP varies from host to host. Many use port 22, some 2222, while others use different ports altogether. Check their knowledge base or call their support. You can ask this question when you notify them of the compromise in the first step.

    Never log onto your site using a public hotspot, such as those in hotels, cafes, etc. Make sure you’ve changed the default password, Ssid, (&, if applicable) the username on your router/modem. If you don’t use wireless, turn it off in your router’s options.

    All these steps are required to ensure that no one can snoop your credentials, etc.

    Now that the device you’ll use to fix your site, as well as your network, is secure, it’s time to direct your attention to actually fixing your site.

    Next, please log into your website control panel from a secure connection and change all passwords, including those to any databases you may have set up. This includes your control panel/FTP credentials & your WordPress database.

    Next, take a backup of your website’s files. Be certain to label it such that the label contains both the date you backed it up on, as well as the word “hacked”–we certainly don’t want you accidentally restoring this backup! This can be helpful, though, in terms of perhaps being able to determine how this occurred, though my feeling is that it likely did so because of an outdated site. Probably you should just back up your web root. Depending on your host, it might be called public_html, htdocs, www, or /. If you don’t wish to back up the entire root, then at least back up your uploads folder, as well as others that might contain content that can’t be replaced.

    Please also back up your database as well. The article at
    http://codex.wordpress.org/Backing_Up_Your_Database
    shows you how to do that, in case you need it. The section regarding phpMyadmin is likely the most relevant to your case. It’s going to be necessary to search that database file to see if any evidence of the hack exists there. That can be done by opening the file in a text editor. To start off with, consider searching for the words:

    <script
    <? php;
    base64;
    eval

    preg_replace
    strrev

    You might also wish at this point to backup your WordPress content. To do that:
    * Log into your WordPress dashboard.
    * Go to ‘Tools > Export’.
    * Choose to export all content.

    While in your dashboard, go to ‘Users > All Users’ and delete any users there that you don’t recognize, especially administrators. A WordPress account should never contain the username ‘admin’. If yours does, make an administrative account that does not contain the word (don’t forget to use a very strong password), then delete the old admin username account.

    Also be advised that sometimes supposed image files can contain code, so open all your image files, particularly in your uploads folders, to ensure they really are images & don’t contain code. Better yet, if you have the images on your machine, replace files in the uploads folders with them.

    If you find nothing, either in your database or in your /uploads folders, then the next step is to delete, then completely reinstall WordPress, as well as any plugins or themes you were using. I also advise creating an entirely new database w/a new user & password. You can then import your content into the newly reinstalled site.

    Please also let someone knowledgeable look at your .htaccess file so they can make certain no backdoor code exists there.

    In summary, here are the steps:
    1) Back up your WordPress files, including core, themes, & plugins;
    2) Back up your database using PhpMyadmin;
    3) Look through the database to insure there is no evidence of the hack;
    4) Search the uploads folders for image files that contain code;
    5) Let someone knowledgeable look at your .htaccess file.
    6) If you have doubts about your database, please have a professional take a look.

    Thread Starter nikmadan

    (@nikmadan)

    Thanks Jackie,

    That is really long, interesting and helpful article. I am sure it should do the job as this is what my suspicion was as I have checked virtually everything I could think of!!!
    My HT access file used to get corrupted earlier, but after antivirus scans, it now is ok. It has only the WordPress code now.
    Currently I have suspended all transients and this is keeping the parent site temporarily under control.
    I surely will follow all your steps, one by one, and do hope that it sort the issue once and for all.
    Thanks for all the help. Will post further if I get stuck somewhere.

    Warm Regards
    Dr. Neeraj Wadhawan

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Transient_doing_cron crashes the website daily’ is closed to new replies.