Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


[Serious] Please help, VPS going offline one too many times. Need help troubleshooting.
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

[Serious] Please help, VPS going offline one too many times. Need help troubleshooting.

over past week, my VPS is going off line around mid-night. I am not sure how to go about checking/ troubleshooting.

VPS running CENTOS 6 with 3GB ram and 120G HDD space.

The vps (to my knowledge) was running with an uptime of 40 days till last week. I am positive that I have not changed any settings lately as all was running well so far.

Please help me in identifying what is causing my vps to go offline...

any rouge script?
any memory limitations?
any logs to check?
any script which can trigger an alert/ email before VPS goes offline?

Since its an unmanaged VPS, I am on my own here. Below is the latest /var/logs/messages. I do not see anything fishy. Any other logs to check?

Sep 7 22:03:52 cloud1 clamd[681]: SelfCheck: Database status OK. Sep 7 22:13:52 cloud1 clamd[681]: SelfCheck: Database status OK. Sep 7 22:23:52 cloud1 clamd[681]: SelfCheck: Database status OK. Sep 7 22:33:52 cloud1 clamd[681]: SelfCheck: Database status OK. Sep 7 22:43:52 cloud1 clamd[681]: SelfCheck: Database status OK. Sep 7 22:53:52 cloud1 clamd[681]: SelfCheck: Database status OK. Sep 7 23:03:52 cloud1 clamd[681]: SelfCheck: Database status OK. Sep 7 23:13:52 cloud1 clamd[681]: SelfCheck: Database status OK. Sep 7 23:23:53 cloud1 clamd[681]: SelfCheck: Database status OK. Sep 8 00:51:16 cloud1 kernel: imklog 5.8.10, log source = /proc/kmsg started. Sep 8 00:51:16 cloud1 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="650" x-info="http://www.rsyslog.com"] start Sep 8 00:51:16 cloud1 xinetd[679]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in. Sep 8 00:51:16 cloud1 xinetd[679]: Started working: 0 available services Sep 8 00:51:16 cloud1 clamd[686]: clamd daemon 0.97.6 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64) Sep 8 00:51:16 cloud1 clamd[686]: Running as user clam (UID 497, GID 498) Sep 8 00:51:16 cloud1 clamd[686]: Log file size limited to -1 bytes. Sep 8 00:51:16 cloud1 clamd[686]: Reading databases from /var/lib/clamav Sep 8 00:51:16 cloud1 clamd[686]: Not loading PUA signatures. Sep 8 00:51:16 cloud1 clamd[686]: Bytecode: Security mode set to "TrustSigned". Sep 8 00:51:19 cloud1 clamd[686]: Loaded 2730842 signatures. Sep 8 00:51:20 cloud1 clamd[686]: TCP: Bound to address 127.0.0.1 on port 3310 Sep 8 00:51:20 cloud1 clamd[686]: TCP: Setting connection queue length to 30 Sep 8 00:51:20 cloud1 clamd[686]: LOCAL: Unix socket file /var/run/clamav/clamd.sock Sep 8 00:51:20 cloud1 clamd[686]: LOCAL: Setting connection queue length to 30 Sep 8 00:51:20 cloud1 clamd[689]: Limits: Global size limit set to 104857600 bytes. Sep 8 00:51:20 cloud1 clamd[689]: Limits: File size limit set to 26214400 bytes. Sep 8 00:51:20 cloud1 clamd[689]: Limits: Recursion level limit set to 16. Sep 8 00:51:20 cloud1 clamd[689]: Limits: Files limit set to 10000. Sep 8 00:51:20 cloud1 clamd[689]: Archive support enabled. Sep 8 00:51:20 cloud1 clamd[689]: Algorithmic detection enabled. Sep 8 00:51:20 cloud1 clamd[689]: Portable Executable support enabled. Sep 8 00:51:20 cloud1 clamd[689]: ELF support enabled. Sep 8 00:51:20 cloud1 clamd[689]: Detection of broken executables enabled. Sep 8 00:51:20 cloud1 clamd[689]: Mail files support enabled. Sep 8 00:51:20 cloud1 clamd[689]: OLE2 support enabled. Sep 8 00:51:20 cloud1 clamd[689]: PDF support enabled. Sep 8 00:51:20 cloud1 clamd[689]: HTML support enabled. Sep 8 00:51:20 cloud1 clamd[689]: Self checking every 600 seconds. Sep 8 00:51:21 cloud1 saslauthd[890]: detach_tty : master pid is: 890 Sep 8 00:51:21 cloud1 saslauthd[890]: ipc_init : listening on socket: /var/run/saslauthd/mux Sep 8 01:01:20 cloud1 clamd[689]: No stats for Database check - forcing reload Sep 8 01:01:20 cloud1 clamd[689]: Reading databases from /var/lib/clamav Sep 8 01:01:23 cloud1 clamd[689]: Database correctly reloaded (2730842 signatures)

Comments

  • praveenpraveen Member
    edited September 2013

    Are you sure that the host node is the one going down?
    Since it is going down mid night, I doubt your host node is restarted by the provider for some reason .. please contact your provider and check.

  • I checked with them, and the claim nothing is wrong at their end.

    Any logs to check which will have exact information on when system is going down?

    Any script which I can write to do that?

  • Try checking your crontab

  • Anything on the console before you reboot?

  • It could be the network itself, which the host probably wouldn't catch right away. If it continues, ask them again but be slightly more demanding, if it isn't fixed. Try finding another host.

  • @miTgiB said:
    Anything on the console before you reboot?

    I cannot connect via SSH. So, cannot check that.

  • @Tsume said:
    It could be the network itself, which the host probably wouldn't catch right away. If it continues, ask them again but be slightly more demanding, if it isn't fixed. Try finding another host.

    Hmm, I will check with them again. But, any logs / scripts which will send an email if the system goes offline?

  • @awson said:
    Try checking your crontab

    I have 3-4 crons running (they are simple content mirroring crons running Rsync). So far, all was working well, until last week when things went awary.

  • netomxnetomx Moderator, Veteran

    Maybe they shut it down because a from script eats a lot of CPU?

  • @netomx said:
    Maybe they shut it down because a from script eats a lot of CPU?

    All I have is 3 rsync scripts running after 1 hour and a few domains (no traffic at all).

Sign In or Register to comment.