You are not logged in.
Pages: 1
I just had a hard freeze on my system while running KDE (no keyboard input, so no soft rebooting or quitting X or anything, and I could move the mouse but not click anything). It scared me a bit because the screen went all weird (like the colours went negative).
I am wondering if this could be due to /tmp filling up. I didn't keep an eye on it and I was playing with GIMP (setting its scratch to /tmp). Quite some time after I had already closed it I ran into the freeze immediately after clicking on a link in Firefox. Did my system just have enough at that point? Doesn't /tmp get cleared out after a while on its own?
If this is a /tmp problem, how can I avoid it in future? Should I make a cron job to delete it out every once in a while? It's not on its own partition so I can't really make it larger.
Offline
No /tmp/ filling up will not cause a system to die.
Your system wasnt hard frozen, you could still move the mouse. Chances are that your system memory got used up. Most of the time, if you wait, the kernel's oom killer will come into play and kill off processes that are using plenty of ram.
If you have compiled your kernel with Magic Sysrq key support, you can force an oom kill, (as of 2.6.12) afaik with Alt+Sysrq+f and the kernel will kill off the process or processes that use the most ram.
Offline
If you have compiled your kernel with Magic Sysrq key support, you can force an oom kill, (as of 2.6.12) afaik with Alt+Sysrq+f and the kernel will kill off the process or processes that use the most ram.
Oh, I like this "feature" - didn't know about it.
Google gave me this link for more information.
:: / my web presence
Offline
It's useful, someone who uses the Arch kernels should post in the bugtracker and request it to be included. It's saved me from a reboot many a times.
Offline
Do other distros turn it on by default?
Does it have any bad effects on the performance and/or stability ?
Offline
You mean Sysrq? That should be on by default yes, very handy and doesn't slow down anything.
/tmp is mounted as tmpfs by default in Arch, try uncommenting that line in fstab. Not that it will fix the real problem.
Offline
This seems like a disadvantage of having sysrq enabled by default.
Leaving magic SysRq enabled on a production machine can be potentially dangerous. Anyone with physical access to the machine can bring it down instantly.
You should also disable SysRq if other people can log in to your system remotely. A < break > sent from a remote console will be interpreted as < Alt+SysRq >, and the consequences can be disastrous.
I don't know if this is a real danger or only a warning. Anyone with physical access to a machine can throw it out of a window. Anyway, maybe this is the reason why it's not on the default kernel.
And where were all the sportsmen who always pulled you though?
They're all resting down in Cornwall
writing up their memoirs for a paper-back edition
of the Boy Scout Manual.
Offline
That's only for remote serial consoles, not ssh or something... By default people already can do Ctrl+Alt+backspace and then Ctrl+alt+del if they dislike the reset button for some reason.
So seriously, any other reason to not enable it by default?
Offline
Thanks for the info; especially about sysrq.
Most of the time, if you wait, the kernel's oom killer will come into play and kill off processes that are using plenty of ram.
How long of a wait are we usually talking? 5 minutes? Or perhaps I should go to bed for the night and check it in the morning. Just curious.
Offline
Name me stupid, but which is the [Sysrq] key???
Frumpus ♥ addict
[mu'.krum.pus], [frum.pus]
Offline
On my keyboard, it's the same key as prt scr (print screen).
Offline
Pages: 1