1

I have a laptop converted to a Linux Mint server running a variety of services. Recently, it started being unaccessible at random.

The situation seems intermittent. The server is usually blazing fast. I can still ping the server, but any attempt to access its services (ssh, web, etc) takes a prohibitive amount of time.

When I try to access the server with SSH, it can take over 15 minutes before I get to the login screen. The hard drive activity light stays on and the machine is running hotter than usual but not dangerously so. If I reboot the machine, it is super fast for some time, until it randomly becomes unresponsive again, maybe days later.

I have tried using iotop, but I've spent the past 45 minutes just waiting for it:

user@machine~ $ sudo iotop
[sudo] password for user: debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE

debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0

EDIT I power cycled the server and took a look at all the logs. These were the last entries in syslog. There were several hundred of identical lines preceding it:

Jul 17 20:35:16 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:35:40  pulseaudio[2106]: last message repeated 673 times
Jul 17 20:35:40 t510-mint rsyslogd-2177: imuxsock begins to drop messages from pid 2106 due to rate-limiting
Jul 17 20:35:41 t510-mint rsyslogd-2177: imuxsock lost 6 messages from pid 2106 due to rate-limiting
Jul 17 20:35:41 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:36:05  pulseaudio[2106]: last message repeated 673 times
Jul 17 20:36:05 t510-mint rsyslogd-2177: imuxsock begins to drop messages from pid 2106 due to rate-limiting
Jul 17 20:36:06 t510-mint rsyslogd-2177: imuxsock lost 6 messages from pid 2106 due to rate-limiting
Jul 17 20:36:06 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:37:19  pulseaudio[2106]: last message repeated 567 times
  • Logs? Did you check logs? like /var/log/messages or /var/log/dmesg.0 and so on? – rush Jul 17 '14 at 15:48
  • 1
    Sounds like a swapping issue. Please edit your question and tell us how much RAM and how much swap you have. Also show us the output of grep swappiness /etc/sysctl.conf. – terdon Jul 17 '14 at 15:48
  • I would love to check the logs, but the system is still inaccessible. The swappiness settings should be the default ones. However, I have considered checking for memory usage too. – Nicolas Bouliane Jul 17 '14 at 15:59
  • Also run top and look at the VIRT column to see if there's anything that is a lot larger than the size of your RAM. – Mark Plotnick Jul 17 '14 at 16:13
  • I like this command vmstat 1. You can leave running in background and paste the most recent lines when it fails? – LatinSuD Jul 17 '14 at 17:43
0

You can try accessing the system in runlevel 3 for multiuser command line mode and try to clean some space on the / filesystem, while you are at it, it'll be a great idea to get some unused space (if any) for some extra swap. If you already are in runlevel 3, then clean the system at runlevel 1 which will load basic services for you to run diagnostics and/or troubleshoot. The system should become accessible from this runlevel and you should be able to get some logs as well (grep swappiness /etc/sysctl.conf).

Take a look at this post for runlevel info:

Debian init runlevels

  • The filesystem has plenty of space left, so that is not an issue. The grep command returns nothing with those parameters. – Nicolas Bouliane Jul 18 '14 at 0:22
  • What about the swap space? Do you have enough assigned? grep SwapTotal /proc/meminfo – strkIV Jul 18 '14 at 0:38
  • I was able to get the same thing to happen a few seconds ago. There was plenty of RAM left, so it shouldn't be a problem, correct? – Nicolas Bouliane Jul 18 '14 at 0:40
  • Well, enough RAM doesn't always means that you are OK to go. RAM is always important, but Linux uses swap space too for process buffering. Swap is recommended to be 2x the size of RAM but this is just a suggestion. If you have enough RAM and HDD space, then 1x of swap should be OK. Something else to check is what the top command gives you when the services are running, try: top > Shift+f > n. That will give you who's eating RAM when the problem occurs – strkIV Jul 18 '14 at 0:46
  • Got 8GB of SWAP (and 4GB of RAM), so I assume this is fine? – Nicolas Bouliane Jul 18 '14 at 0:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.