Hot answers tagged

273

Ctrl-Q To disable this altogether, stick stty -ixon in a startup script. To allow any key to get things flowing again, use stty ixany. ps: It's neither the terminal nor the shell that does this, but the OS's terminal driver.


160

Ctrl-Q is indeed the answer. I thought I'd toss in a little history of this that is too long to fit in the margins of ak2's correct answer. Back in the dark ages, a terminal was a large piece of equipment that connected to a remote device (originally another terminal because teletypes were so much easier to learn to operate than a telegraph key) over a long ...


36

Are you using a 64-bit version of Linux with a lot of memory? In that case the problem could be that Linux can lock for minutes on big writes on slow devices like for example SD cards or USB sticks. It's a known bug that should be fixed in newer kernels. See http://lwn.net/Articles/572911/ Workaround: as root issue: echo $((16*1024*1024)) > ...


13

A better solution than turning off swap, which will at best cause random processes to be killed when memory runs low, is to set the per process data segment limit for processes that pull stuff off the net. This way a runaway browser will hit the limit and die, rather than cause the whole system to become unusable. Example, from the shell (ulimit -d ...


10

Disabling swap won't do what you want. You will still get violent I/O throughput, but it will be of clean pages rather than dirty ones. With no swap, the system will compress the cache of clean (unmodified) pages to near zero, because those are the only pages it can evict from physical memory. It can only evict dirty (modified) pages from memory by writing ...


10

The pipe symbol is sending the ouput of nano to the input of the uniq command. However, nano is still running and receiving your keyboard input. It's just that you can't see its ouput as uniq won't ouput it's results until it sees an End-Of-File (this isn't important to the question). When you press ctrl-c it is 'caught' by nano, but it does not cause it ...


9

I don't know what the Cinnamon guys renamed gnome-shell when they forked, so you'll have to find this out. It's probably either cinnamon-shell or cinnamon or something. I'll assume it's called cinnamon. Now, the GNOME Shell - and by extension, Cinnamon - will respond to SIGHUP by completely reinitializing. It's basically the same as typing r into the AltF2 ...


8

If you want a way to reboot, without saving open documents, but without hitting the reset button, then there are ways that are less likely to cause data loss. First, try Ctrl+Alt+F1. That should bring you to a virtual console, as ixtmixilix said. Once you're in a virtual console, Ctrl+Alt+Delete will shut down and reboot the machine. If that technique ...


8

If the screen and input devices (keyboard and mouse or trackpad) froze, the first place to start by looking would be in /var/log/Xorg.0.log (assuming that Xorg is running on the first display server). If that doesn't yield any immediate clues, the next logs to check would be /var/log/messages.log and /var/log/dmesg.log. If you are unable to find anything ...


7

From the btrfs gotchas page: Files with a lot of random writes can become heavily fragmented (10000+ extents) causing trashing on HDDs and excessive multi-second spikes of CPU load on systems with an SSD or large amount a RAM. On servers and workstations this affects databases and virtual machine images. The nodatacow mount option may be ...


7

Running reboot is a perfectly safe way of doing it. If you just wanted to log out (restart your GUI session), you could run: sudo service mdm restart That will restart the Mint Display Manager, the default display manager under Mint.


6

It sounds like your kernel panicked in some way such that sshd couldn't send the server keys. Possibly, the kernel was wedged in such a way that the network stack was still up, but the vfs layer was unavailable. When I experienced similar problems on a RHEL4 system, I set up the netdump and netconsole services, and a dedicated netdump and syslog server to ...


6

They are probably very related. STOP USING THAT COMPUTER UNTIL YOU FIX THE FAN It can only take milliseconds for the CPU to go from "OK" to "OMG I melted". They should never be used with out proper cooling. To do so, will cause damage, and could cause a fire, injury, and all manor of bad things. That warning aside Linux and most semi-modern computers ...


6

One option to do a quick test could be to use a KGDB enabled kernel and stop the kernel manually and test, see this link. On another note, things I remember that could cause your pauses: cpufreq, cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency, the value is in ns (4000 in my AMD FX(tm)-8120 Eight-Core Processor) shouldn't be a problem, ...


5

To make this change pervasive you'll need to add these limits to the entire environment. Changes using the ulimit command are only to the current environment. NOTE: This will have no effect on the root user! Example Edit this file: vi /etc/security/limits.conf and add entries to the file limiting the number of processes (nproc) that a specific user or ...


5

The superuser or any process with the CAP_SYS_ADMIN or CAP_SYS_RESOURCE capabilities are not affected by that limitation, that's not something that can be changed. root can always fork processes. If some software is not trusted, it should not run as root anyway.


5

If you have a keyboard attached, you could do the RESUIB method. Otherwise try to ssh into your box, and us top, ps and the usual helper and log checker programs to hunt down your problem.


4

This is a bug in Fedora 17. You can work around it by disabling the Plymouth boot screen: systemctl mask plymouth-start.service It will be fixed in Fedora 18.


4

For some weird reason, cpio doesn't like to take a file argument. Instead, you have to pipe the archive into cpio. An inexperienced user would do the following: cat initramfs-linux.img | cpio -i However, this would get you the Useless Use of cat Award. A better way would be: cpio -i < initramfs-linux.img This uses the shell's built-in redirection ...


4

When you are able to do CTRLALTF1, after you can try to kill the offending software. (via pgrep, pkill...). Not always, but often, it is enough to gain back the control of the graphical environment and to log-out normally after a CTRLALTF7 If you cannot do it usually with CTRLALTBACKSPACE you can restart the graphic server. On Ubuntu you should give ...


3

The two most common causes of crashes are video driver bugs and bad RAM. You can look for clues in logs in /var/log. Video problems are logged in /var/log/Xorg.0.log. Problems detected by the kernel are logged in /var/log/kern.log or /var/log/messages or some other file depending on the distribution, I don't know which file Manjaro uses. However, if your ...


3

You are presumably using the i915 driver for the integrated video, and I bet it has something to do with this bug: https://bugzilla.kernel.org/show_bug.cgi?id=58381 Since the "freezing" is a kernel panic. Try: grep i915_hangcheck_hung /var/log/* And see what turns up. You might try turning off "use hardware acceleration when available" in chrome ...


3

As other answers have already explained, Ctrl+C doesn't kill Nano because the input of nano is still coming from the terminal, and the terminal is still nano's controlling terminal, so Nano is putting the terminal in raw mode where control characters such as Ctrl+C are transmitted to the program and not intercepted by the terminal to generate signals. When ...


3

Test the partitions with a livecd of some distro more updated. Mount the partition, write a lot of files and check the dmesg. The kernel of Debian Stable is old and if your problem is a kernel bug, probably is solved. You also can try with other schedulers. Add "elevator=noop" or "elevator=deadline" to your grub. Sometimes, other schedulers can help with ...


3

There are the so-called "Magic SysRq keys" -- a set of keypresses that can be embedded at kernel level and will be honored as long as both the kernel process and the keyboard interrupt are still being listened to, and can be called by alt-SysRq-keypress. These can perform various emergency tasks such as an emergency S ync of all mounted filesystems, k I ...


3

Not exactly what I was looking for but close: iotop -o So I will use: sudo nice -20 sudo iotop -tbod10 > ~/iotop.log


3

To me this sounds like the system is out of resources so the process needed by the server side of ssh cannot be allocated. The actual bottleneck can vary - out of processes or out of memory - and the only way to be sure is to look at the logs and console to see if anything is present there. You may want to set up a scenario of pre-started ssh-jobs - one to ...


3

To make sure that swap is not used, you'd be better off preventing any swap being added at boot. This can be done, depending on the system, by disabling the swap boot service or just commenting out the swap entry in /etc/fstab. As far as your hangup is concerned, the stop() function in /etc/init.d/swap might give a clue: stop() { ebegin ...


3

Yes , the easiest way to archieve this , is enable the keys to kill Xorg server , and re-launch X session. To enable this , open System Settings -> Keyboard Layout options (or use keyboard command in Unity interface , hit ALT + F2) , and check this option: Control + Alt + Backspace So when it hangs , hit CTRL + ALT + Backspace will kill X server , and ...


3

Try removing any extra plugins or syntax files you have for editing JS files. A poorly written vimscript or syntax file (basically a bunch of regexes) can make Vim eat all CPU cycles in a blink.



Only top voted, non community-wiki answers of a minimum length are eligible