System crashes from errant apps

[kingtermite]

I'm not familiar with the Linux kernel structure and OS architecture, so I've got a few questions.

I've run a few apps (games) that I installed from the universe (Ubuntu). I understand these are not supported apps and the fact they crashed, is fine.

However, when these apps crashed, they crashed my whole system. It's happened about 3 or 4 times now.

a) When system seems to freeze, are there any things to try to recover?

b) Is the kernel run in separate memory space from apps? If so, then how are they crashing the system?

c) What about device drivers? I thought I read somewhere they that they were built in to the kernel. Is that true? Isn't that dangerous as a simple device driver (like app example above) gone errant can crash the whole system?

[windangel44]

It's rather unusual for an app to freeze a system completely, but you can try to bring up a console window.

Ctrl-Alt-F1

Give it a few seconds to see what happens. You can return to the gui display via Alt-F7. (usually)

[netstrider]

kingtermine,

I do not believe the applications are crashing your entire system but could rather be the X windowing system. Should this happen again you can try the above example or try restarting your desktop environment by pressing CTRL+ALT+BACKSPACE.

[i92guboj]

However, when these apps crashed, they crashed my whole system. It's happened about 3 or 4 times now.

The only way that this can happen in linux is due to:

1.- a defective kernel with experimental patches and cruft
2.- a defective kernel module/driver

Otherwise, the apps can crash, X can crash, but the kernel should still be alive (and you should still be able to login via ssh and kill the program that hanged, for example).

c) What about device drivers? I thought I read somewhere they that they were built in to the kernel. Is that true? Isn't that dangerous as a simple device driver (like app example above) gone errant can crash the whole system?

I don't understand what do you want to say on that sentence. The only way that a driver can have the absolute power that it needs is to put it in kernel space, though lately there has been some work on separating certain drivers to the user land (look on FUSE, sshfs, ntfs-3g or fuseiso). This is not always possible since many times there's a need to work on a closer level to the hardware (there's no way that a FUSE based driver could do DRI, like a graphics video driver, at a decent speed.

This shouldn't be a problem. A driver that's not experimental should always be stable and newer ones often are stabilized in a very short amount of time. Linux has a record on that. Of course, linux still can't do anything about closed drivers, for example, the nvidia or ati ones, and the like. Since we have no access to the sources for these.

[kingtermite]

I don't understand what do you want to say on that sentence. The only way that a driver can have the absolute power that it needs is to put it in kernel space, though lately there has been some work on separating certain drivers to the user land (look on FUSE, sshfs, ntfs-3g or fuseiso). This is not always possible since many times there's a need to work on a closer level to the hardware (there's no way that a FUSE based driver could do DRI, like a graphics video driver, at a decent speed.

This shouldn't be a problem. A driver that's not experimental should always be stable and newer ones often are stabilized in a very short amount of time. Linux has a record on that. Of course, linux still can't do anything about closed drivers, for example, the nvidia or ati ones, and the like. Since we have no access to the sources for these.

Momentary lapse of reason (credit to PF). Of course they must run in kernel space to have access to hardware. Duh!

I guess I was confused...still coming from/thinking in Windows world. I think of drivers as separate DLLs or whatever. They may load and run in kernel memory, but are separate files.

I guess I was getting confused by the whole "what if I get a new device.....will it run since driver won't be in kernel yet?".

[kingtermite]

Well......I've had it happen a few more times now.

None of the above key combinations did anything. When its happened, its happened hard. The entire screen just freezes and it's gone. I have to hard boot to get computer back up. Doesn't seem as if keyboard input is even being received.

[i92guboj]

Momentary lapse of reason (credit to PF). Of course they must run in kernel space to have access to hardware. Duh!

I guess I was confused...still coming from/thinking in Windows world. I think of drivers as separate DLLs or whatever. They may load and run in kernel memory, but are separate files.

In linux, the modules can be either statically built into the kernel or as separate .ko files.

I guess I was getting confused by the whole "what if I get a new device.....will it run since driver won't be in kernel yet?".

It will not be recognized by the kernel if it's not claimed by any existing driver. Not a big problem though. Binary distros usually build everything as modules, and the kernels and init systems nowadays are usually smart enough to load anything that's needed at boot time.

If you are building the thing yourself and a driver is missing, you can use lspci to identify the device. A bit of googling and the use of the search functionality in the kernel's menuconfig are usually enough to find the correct driver. That functionality is activated in menuconfig by pressing the slash '/'.

About your original problem, can't you try to login using ssh from another machine in your network? If not, make sure that the acpid service is running, and try to use the power button to -at least- shut the system down cleanly.

Also, read here about the magic sysrq key combos. They can at least prevent you from screwing your file system when the system hangs.

Magic SysRq key - Wikipedia, the free encyclopedia

But... you still need to find the root of your problem.

[kingtermite]

In linux, the modules can be either statically built into the kernel or as separate .ko files.



It will not be recognized by the kernel if it's not claimed by any existing driver. Not a big problem though. Binary distros usually build everything as modules, and the kernels and init systems nowadays are usually smart enough to load anything that's needed at boot time.

If you are building the thing yourself and a driver is missing, you can use lspci to identify the device. A bit of googling and the use of the search functionality in the kernel's menuconfig are usually enough to find the correct driver. That functionality is activated in menuconfig by pressing the slash '/'.

About your original problem, can't you try to login using ssh from another machine in your network? If not, make sure that the acpid service is running, and try to use the power button to -at least- shut the system down cleanly.

Also, read here about the magic sysrq key combos. They can at least prevent you from screwing your file system when the system hangs.

Magic SysRq key - Wikipedia, the free encyclopedia

But... you still need to find the root of your problem.

Thanks for the tip on how getting drivers in to the kernel. I'm still pretty new to how the whole OS architecture works.


Appreciate the tip on Magic SysRq. I'll look at it. I can't get in from another computer on network as this is my only computer (laptop). I'll also have to do some research to see what this acpid service you are referring to is. Appreciate the help.

[i92guboj]

I'll also have to do some research to see what this acpid service you are referring to is. Appreciate the help.

It's usually the service that administrates the power related event. For example, it's the service that makes your computer shuts down adequately when you press the power button on your computer's case.

How to enable/disable this is usually dependant on your distro. Most modern distros also have it enabled by default. I'd look into the manuals for your distro. Look for something about enabling/disabling serverces are startup (or daemons).