This one's baffled me. I have Ubuntu 14.04, 3 days ago (2014-20-10) it started slowing down.

I've reproduced it by opening gedit and then closing gedit, when the issue is active it hits roughly 2 seconds to close an empty file, whilst without the issue this is always instant - affects everything else in a similar manner.

top reports no unusual activity when the freeze occurs, htop the same, iotop the same as well.

The issue only arises after 30 minutes of uptime, I can guarantee that at 29mins of uptime I could not reproduce it, at 31 minutes of uptime I could reproduce this consistently (using above method, no apps started other than terminal and htop) and managed to repeat this 4 or 5 times (by shutting down, booting up and waiting half hour - which was enjoyable).

The issue persists even after reboots but can be reset by shutting down and powering back up, what part of Ubuntu holds state after reboots but not shutdowns?

Relevant logs for this period are syslog, auth.log and Xorg.0.log (by examining contents of /var/log for time modified in specified range)

syslog:

Oct 22 17:21:36 raiden NetworkManager[1102]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted

Oct 22 17:39:01 raiden CRON[3284]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))

Oct 22 18:09:01 raiden CRON[3370]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))

authlog:

Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session opened for user root by (uid=0)

Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session closed for user root

Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session opened for user root by (uid=0)

Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session closed for user root

Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session opened for user root by (uid=0)

Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session closed for user root

Xorg.0.log: (probably me just waking computer back up)

[  3466.727] (II) intel(0): switch to mode [email protected] on LVDS1 using pipe 0, position (0, 900), rotation normal, reflection none

[  3466.880] (II) intel(0): switch to mode [email protected] on VGA1 using pipe 1, position (0, 0), rotation normal, reflection none

None of those indicate anything bad and subsequent steps to reproduce the issue indicate no changes to the logs so these were most likely just innocent logs.

I presume there's 3 possible sources of this problem:

Software install: I installed something dodgy

I did:

• history | grep apt-get' - no installs in that time period


• Looked at synaptic package manager history - nothing in that time period


• Software centre history - last update was several weeks before (there was a dependency issue so I hadn't done any updates in a while)


• I installed Skype for Ubuntu around that time period but there's no indication it's caused by Skype (removed it anyway)

Cron job going wrong

Checked cronjobs in crontab, /etc/cron.d /etc/cron.daily and hourly nothing indicating it's something in there only a PHP cron job occurs every 30 minutes but if it were cron it would do it at certain points around the clock not 30 minutes after startup.

Analysing new processes that have been started between non-slowdown state and slowdown state suggest no new processes are started, (first test this showed up a kworker thread but this is likely to just be a coincidence). I presume this must mean it's either an existing process that triggered it or something else.

Malware

Due to it's elusiveness and the mysterious 30 min absence of the issue (30 minutes seems like a human-chosen amount of time) I began to think it could be some kind of malware however unlikely it could be (hadn't done an update for a while and have a few open ports). So ran rkhunter (rootkit finder) but nothing untoward was found.

Other things I've tried:

• Unticking certain compiz components - no change


• Restarting compiz - no change


• Unticking all compiz components - no change (except for me wrestling to get the computer usable again)


• Playing various musical instruments whilst waiting for uptime to get to 30 minutes and then watching the results of top and htop for any suspicious changes - nothing odd

Has anyone had anything similar to this happen to them or could point me in the right direction if you do I'll hit the up vote button repeatedly on your answer (I'll make sure it's an odd number)