6

The following applies to Lucid 10.04
It happens on my "real" computer and also in a VirtualBox VM...

(UPDATE) I just now installed Maverick 10.10 to a VM... and almost the same thing happens!
I do have keyboard control (initially) but the only way I can exit the terminal is to close it with the process still running (or Ctrl+C), and this causes the lockup (pressing Enter doesn't take it back to the prompt) 

$ metacity --replace

The above command (in the terminal) causes my system to hang, every time.

The command does not return to the prompt.
The window decoration disappears (maybe because the command hasn't completed?).
The keyboard becomes non-functional, (but the mouse still works)...

However, the following commands work fine, every time. 

$ (metacity --replace &)
$ metacity --replace &    # this works too

It may "hang" only in that I loose the keyboard, and so can't press Enter to bring it back to the prompt, (...as I have noticed is the case with some unrelated commands which don't "fully" return to the prompt, until I press Enter)

What's going on here?
My "host" OS is not new, but the VM is in mint condition (almost)... and they both exhibit this keyboard "lock-up".

Improve this question
6
  • I have has some weirdness in backgrounding rvm setup. I think it has to do with environment variables in backgrounded processes, but I can't be sure yet....good luck
    – RobotHumans
    Nov 11, 2010 at 15:11
  • Thanks.. at least I can work "around" it, but it's nice to know the "why" ...
    – Peter.O
    Nov 11, 2010 at 15:48
  • have you tried running it through something like grun?
    – RolandiXor
    Nov 11, 2010 at 16:41
  • @Roland: I had tried it via "Run Application" (Alt+F2), and I've just now tried "Launch Applicaton" (grun)... They both work okay... It's just that it seems strange that it hangs up when run in the terminal without the & ... Things "shouldn't" do that in the Terminal.. Not working would be understandable /acceptable, but disabling the keyboard (which requires a reboot) is not.
    – Peter.O
    Nov 11, 2010 at 16:49
  • 1
    you shouldn't be running metacity from the terminal though, not without something that frees the terminal after.
    – RolandiXor
    Nov 11, 2010 at 17:26

2 Answers 2

Reset to default
3

Pressing Enter doesn't return to the terminal prompt because metacity is running in that terminal. Any warning/error messages metacity produces will be printed there. This is standard behavior for any GUI app. If you don't want them to take over your terminal session, use '&'.

About the rest -- disappearing window decorations etc. -- I'm baffled myself.

Improve this answer
2
  • It only loses the window decoration when I exit the terminal via the menu (because it's either that or Ctrl+C).. This then causes the window decoration to disapper, but that's not the main problem.. The main problem is that I am left with no keyboard functionality, which means I need to reboot.. This behaviour is beyond the normal "terminal is waiting for launched App to exit" (which is basically the same as MS Windows console's START /WAIT vs START).. This situation causes things to go beyond the pale.. Oh well, I'll just have to make sure I use the ampersand.... coffee time :)
    – Peter.O
    Nov 11, 2010 at 17:47
  • Ah, if you do it without backgrounding, closing the window kills the subprocess running in it, and you end up with no window manager at all, and thus no way to change keyboard focus. I'm surprised gnome-session doesn't restart the window manager automatically, though.
    – Marius Gedminas
    Nov 13, 2010 at 18:59
2

Running metacity --replace does not make it run as a daemon. If you hit Ctrl-C or otherwise stop that metacity process from running (closing terminal would do that as well), you will be left without a window manager. That is why you lose your window decorations. I am not exactly sure why the keyboard stops functioning (my guess is that once the window manager is closed new updates to the window, like typing, won't be painted to the screen), but I have tested this and if you hit Ctrl+Alt+F1 you can still drop to the framebuffer. Clearly the keyboard has not stopped working entirely, in fact if you click a menu item in gnome-terminal you can use the up and down arrows to navigate it.

You should run metacity in a wrapper, such as screen, when you need to start it from terminal and then close the terminal window you used. Just run screen metacity --replace and press Ctrl+A+D to detach from the screen process.

Improve this answer
3
  • Phew! .. lots of new info for me to digest, but I've got the general run of it now... very interesting, (and I'm sure "dropping the framebuffer" will keep me well "entertained" for a few days..:) .. Thanks ayan...(and to all)
    – Peter.O
    Nov 11, 2010 at 18:37
  • Happy to provide some useful info. I myself had quite a bit of trouble the first time I tried to run compiz --replace (well, it was still Beryl back then...) and then close the terminal window.
    – ayan4m1
    Nov 11, 2010 at 22:06
  • Keyboard "stops functioning" because the WM controls which window is active, and in the particular case no window is active, or the one which is, doesn't usually react to any keys. Any repaints without the WM are still done, because even if the WM had been in compositing mode before quitting, on quitting the X session restores normal non-compositing mode.
    – Ruslan
    Mar 15, 2019 at 17:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .