Reasoning behind console limitations
 

Why is it that I can kill or start some applications from the console but not others like gnome-sessions Which necessitate a reboot? I can kill a browser from the console but I can't open one. :banghead:

Thanks in advance!

I am not intimately familiar with gnome, never liked it much, but what you are describing does not sound like a limitation of the console.

It is more likely that the gnome processes that you try to kill are respawned by other gnome related processes.

Add the "-9" option to kill or kill the whole process tree. If for a certain task you don't want gnome to run, consider dropping to runlevel 3. That should close all x related services.

One: Are you trying to kill these as userid 'root'?
Two: Are you trying to kill these with the -9 option?

There should be very few processes that you cannot kill this way. I've seen it happen occassionally when processes are deeply into some very low level database or network stuff. Still, it's rare even then. Are you perhaps talking about [defunct] processes? Those aren't actually processes, they are just an entry in the process table that has not been cleaned up yet. The parent process of the dead child must either wait() on that dead child or die itself (the parent) to clean up the process table.

Gnome should be easily kill-able. Show us the output of "ps -ef | grep gnome", your effective userid, the exact kill command you are running, the output of that kill command, and then the "ps -ef | grep gnome" output after you attempt the kill.

You should be able to open a browser from the command line. Easy. But of course you first have to have X running. You're not going to be able to successfully start any GUI-based app without a window manager. Are you perhaps running a Gnome desktop as userid "xyz" and then trying to start a browser as root? It wouldn't know what :display to send output to in that case (unless you manually told it that info).

thanks for the replies!
 

I'm actually looking at the console Alt>f2 as a remote method to fix problems in the GUI that is running X. If My desktop freezes , the first thing I do is open a non x console and (Killall BrowserName). It seems I can kill any application but not restart it from a non x console which leaves the problem if the desktop crashes someway I have no GUI way to fix it. Why is it a one-way street sort of thing?

You can only run an X11 based application by passing it a DISPLAY variable that's valid. If you want to run Firefox from one of the TTYs then just use:
Assuming you only have one monitor/x session and you want to put the application into the background and do something else.

...try to find out the reasons why instead, for example from your ~/.xsession-errors*, /var/log/Xorg* and related log files. (Unless you run unstable software or mix packages from untrusted or unsupported sources. Then as far as I'm concerned you're SOL.)


And indeed most of the time it's about the display envvar. Note you don't need to background FF from the CLI, this should do:

That doesn't work for me -- it behaves as it would if I opened it in an xterm leaving the terminal "tied up" until Firefox is killed, which <ctrl>+C does as usual.

If your desktop freezes, kill the X server. A number of problems with desktops are caused by the window manager itself freezing, but trying to FIND it can be tricky (especially with gnome3) because a number of its elements run independently and will restart other elements. Killing the X server will cut off all of the processes, and cause the GUI login process to restart it, prompting for a login.

The user processes don't always die (usually do, though it sometimes takes a minute or two). I periodically logout, then log in on console terminal (f2) as root and look to see if something is still running... Then I do a killall -9 <username>... and look again. That should take care of it.

When I want to restart X from one of the TTYs you can probably run "service gdm3 restart" or "service kdm restart" (or whatever your display manager is called) and that should do it for you. For example when installing NVIDIA's binary drivers I'd run "service gdm3 stop" install the driver etc. then "service gdm3 start" and things would be up and running again.

That usually works... but doesn't clean up the user processes that don't terminate like they should. (sometimes they just suck up CPU time). I keep finding nepomuk running forever unless I kill them manually (they just accumulate until memory gets exhausted).

thanks for the replies!
 

I'm interested in the connection between virtual consoles and not actually trying to fix a version of Mandriva 2010 that was a mess and has never been updated because 1/2 the code of the entire O.S would have to have been replaced. env DISPLAY=":0.0" firefox
and export DISPLAY=:0 ; firefox & give messages or Protocol Not specified , Can't open display :0 . and [1] + ext 1 firefox I think. The out come does not really matter.

I guess I will try to find more info on virtual consoles.

I think unSpawn and I both made small mistakes with what we posted, you could try: with a '&' on the end if you want. I think unSpawn mean to type "export" and I was guessing at setting DISPLAY to ":0" because I have two displays and I use ":0.0" or "0.1" but I think if you have one display it may still be ":0.0".

If I run echo $Display I get (0:) Still,what is the connection between terminals in a logical sense? Why is it that in console 1 (Alt >f1) I can kill a program in x or console 7 and console 1 knows where it is? Why/how can I effect different terminals from the one I'm using? There is obviously a bias towards console 7 by the other consoles. It's like they are all sharing the X console.

The system is the connection, otherwise each virtual terminal is a separate login shell and there is no "connection" with other terminals other than the underlying kernel/processes/filesystem (i.e., the system).

You can kill a process that was started in another terminal, assuming proper permissions, because it is running on the system under control of the kernel.

You cannot start a new process "in" another terminal because you are not a child of that other terminal nor running within the context of that other terminal.