Restart cinnamon - cryptic bother, why does it not work?

[bernd.wechner]

I find cinammon freezes from time to time. Mostly ALT+F2 then r resolves this if it's still responding to ALT+F2. But if it's not then I got to tty1 and want to restart it.

Problem 1: There is no lucid simple way to do this that is easy to find. Instead the best I can find is this:

http://askubuntu.com/questions/143838/h ... om-the-tty

Which converges on this solution more or less:

Code: Select all

export DISPLAY=:0; cinnamon --replace

if only there were agreement.

Problem 1a: cinnamon command-line documentation is lacking. What do these options do and what are examples of their use:
--display
--clutter-display
--screen

totally cryptic to me and not documented.

Problem 1b: Some folk stipulate DISPLAY=:0 others DISPLAY=:0.0, what's the difference? I would love learn what's going on here, not just have a list of recipes to try.

Problem 2: It doesn't work for me.

If I do "export DISPLAY=:0; cinnamon --replace" on tty1 I receive this message:

Code: Select all

No protocol specified
Window manager error: Unable to open X display :0

Go figure. But just to make life interesting if I start another server with: startx -- :1 (a command I barely understand alas having read the man page on startx) I get a new cinnamon session on tty9. That's actually an awesome thing to learn itself!

But guess what? On tty1 this ""export DISPLAY=:1; cinnamon --replace"" actually restarts it! It works.

But it doesn't work for ":0" reporting instead:

Code: Select all

No protocol specified
Window manager error: Unable to open X display :0

as mentioned above.

What can I do to diagnose this further? To understand what is going on. To interpret this strange message "No protocol specified"

OK search online. I found this:

http://unix.stackexchange.com/questions ... l-specifie

It suggests "export $(dbus-launch)" which means nothing to me (lord only knows how that causes the mentioned dbus-daemon reinitialisation but for what it's worth on tty1 it simply reports "No protocol specified"

No progress.

I did find a similar forum post:

http://forums.linuxmint.com/viewtopic.p ... 8&t=159772

But again have learned nothing though did try the recipe "service mdm restart" which was not at all what I wanted (logged me out when I want to restart it and keep my windows!) and afterwards "cinnamon --replace" continues to report no protocol specified"

Now here is a cruncher. From a terminal window in Cinnamon, "cinnamon --replace" works! just not from tty1 logged in a root.

There are two issues here for me:

1) How do I fix my problem
2) How do I learn what's going on instead of getting a pile of recipe commands without explanation that might fix it?

What does "No protocol specified" mean?

[bernd.wechner]

I'm not exactly blown away by the total lack of replies.

But for what it's worth I have learned:

• 1) For reasons beyond the comprehension of mere mortals if you logged in to Cinnamon as UserMe then you can only restart Cinnamon when logged in as UserMe not as root. Yep root has less power here than UserMe does! Go figure.
  2) The way to restart cinnamon and keep windows you had open is to run "cinnamon --replace --display=:0". Yeah, go figure, you need to tell it which X display Cinnamon is running on.

Point 2 is beautiful in a way. It suggests I could run a parallel session of Cinnamon on :1 say (perhaps on tty9?). How? That would be cool. Could have one user logged in on tty8 and another on tty9.

If only I could figure out how to do that. The rate of response here of course does not encourage. So will try another post and other forums I guess.

[mellobob]

Another thing to try when Alt-F2 doesn't work is the key press Ctr-Alt-Escape.

[bernd.wechner]

Alas in most instances of freeze that bother me keyboard is totally unresponsive except, and this surprises me ALT+CTR+F1 and family. But yes Alt+F2 and CTRL+ALT+ESC are good friends ... they work for a good number of lockups alas, so many I'm not exactly happy with Cinnamon ... Grrrr. But it may not be its fault. All I know is that the last resort of a switch to tty1 always seems to work and I can play around there and sometimes bring it back to life by selectively killing stuff.

We're not talking a resource issue as I have an 8 core Intel Core I7 on a ROG board with 32 GB of RAM on a 240GB SSD with abundant Hard disk too ... and I watch resources pretty closely on the lower panel.

But I do tentatively find lockups correlating with high network traffic ...but that is not a reliable observation at all.

[bernd.wechner]

Oh I should not that I do know that:

Code: Select all

 startx -- :1 

Starts a new cinnamon session on tty9. Which is good, But I don't fully get it.

I don't want to minimize resource consumption so want to understand what is going on with this command.

1) How does the first cinnamon session gets started? Where in the boot sequence and who does it? upstart?
2) What's the distinction between the X server and Cinnamon (the graphic desktop manager)? Does each Cinnamon instance demand its own X server, or can one X server manager two or more Cinnamon instances? If the latter this command I have is sub optimal.

Learning, learning, learning ...

Bernd.

[lofi]

hey Bernd, everyone,

Is it ok to bump a 2016 thread ?
I'm about to make a new thread and was searching for duplicates beforehand. That one was close, but not quite.
I just wanted to thank Bernd for sharing his discoveries (and questions) here despite the lack of answers.
With the magic of search engines (and good databases and paying hosting fees), one is never speaking alone. You never know if someone from a distant future (like 2028) is listening.

I don't have the same problem, but I'm interested in the exact difference between restarting Mint from the normal session (TTY7) and restarting from another TTY. From this thread, I understand that TTY1 with the command starting with export DISPLAY=0 will restart cinnamon as root.
If I don't find a duplicate, my thread will be about restarting Cinnamon from TTY and polkit problems.

[Moem]

Is it ok to bump a 2016 thread ?

We strongly prefer that you don't. Maybe a re-read of the forum rules is in order?