Cinnamon: No clear way to restart Cinnamon from a tty

[bernd-wechner]

Cinnamon freezes. That's life.

But we have the beautiful ability to restart Cinnamon.

There's the famous (though only uncovered by searching the internet) ALT+F2 then r.

But this (and similar methods) only work if some of Cinnamon is still alive and responding.

When it's not I go to a tty by say pressing ALT+CTRL+F1, and find my system responsive. Conclusion it is Cinnamon, not LinuxMINT that is hung.

But what to do? How to restart Cinnamon.

It's entirely not clear as evidence by the lengthy discussion here:

http://askubuntu.com/questions/143838/how-do-i-restart-cinnamon-from-the-tty

My favourite response to which was:

cinnammon --replace --clutter-display=:0 2> /dev/null &

And yet, here's the crunch, I am testing this and can see:

1. from a terminal window in Cinnamon, it works. All the windows go down and come up again and all is good (with a minor glitch, a Wine window that I can't kill often appearing) but works.
2. if I do it on tty1 with slick timing pressing Enter then ALT+CTRL+F8 I can never catch Cinnamon doing it. So I have to wait until it's frozen again to actually test it, as I see no way of distinguishing between:
   
   
   
   • It works but is so slick and fast there's nothing to see
   
   
   • It doesn't work and Cinnamon is not restarted
   
   
3. So I tried this: cinnammon --replace --clutter-display=:0 (i.e. I'm watching stderr now) and it reports this:

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

It's definitely on :0 as w reports this:

 22:32:53 up  1:29,  3 users,  load average: 0.38, 0.37, 0.41
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
bernd    tty8     :0               21:59    1:29m 30.05s  0.11s cinnamon-session --session cinnamon

My main point here though is that it should surely be a priority for Cinnamon to have a simple reliable command line to restart it. Without having to even know the X display, restart them all dammit, or report a list of them if more than one is found and have an option to choose one.

But above all, how about the command line options
--display
--clutter-display
--screen

actually get documented?

What do they mean? Where are some examples?

This is one of the nastiest issue I am having with Cinnamon. Freezes are fortuitously rare, but when they happen, knowing I could restart it without losing all my windows but not knowing how is a frustration indeed.

[glebihan]

Since cinnamon auto-respawns, the simplest way to restart it is simply to kill the existing instance (eg killall -9 cinnamon).
Apart form that, you do need to know the display cinnamon is running on in order to be able to restart it.
The command I use is DISPLAY=:0 cinnamon --replace.

[bernd-wechner]

Thanks for the prompt reply. Alas with all due respect not helping me much or speaking to the request.

The linked to askubuntu thread is full of that very suggestion and that's all good though lends the though your summary is a little flawed, and should perhaps read: export DISPLAY=:0; cinnamon --replace as if I understand rightly DISPLAY= sets a shell variable and export DISPLAY= sets an environment variable, and you'd want a semicolon to separate the commands.

But that said, while this works fine for me in a Cinnamon terminal window from a tty it as described impossible to feel confident it is working and very likely it's not (please reread mye xperience, in particular that the tty simply reports:
No protocol specified Window manager error: Unable to open X display :0

and my main issue which is filed is the complete lack of a user friendly simple way of doing this from a tty, not a specific solution that works for some folk, has been passed word of mouth generation to generation so to speak.

Because it does from time to time freeze, and it is possible to restart from a tty there should be a simple lucid documented and provided utility to do so without having to do on-line reserch try a load of different people's ideas and end up with cryptic messages like No protocol specified with no help.

Therein lies the issue - though of course I am open to solving my specific problem, the issue with Cinnamon is the lack of a no-brainer method to do this for a novice I install MINT for say.

[glebihan]

To come back to my original suggestion : my summary DISPLAY=:0 cinnamon --replace was correct.
You do not need to use export.
The way I suggested to do it applies the DISPLAY variable to the command that you put on the same line.

If when running that, you get the message No protocol specified Window manager error: Unable to open X display :0 then either you're using the wrong display number or you're running the command with the wrong user.

As for your other points : I understand what you mean but I don't think switching to a tty is user friendly in the first place. A novice user would never think of doing that.
What needs to be fixed is the fact that cinnamon can freeze (and if you can provide any information as to when it happens, that'd be very helpful) and that seems to me like a much more important thing than providing easy commands to restart it from a tty.

[bernd-wechner]

Thanks heaps for the clarification! Great learning re: command line syntax in bash.

I agree going to a tty is not very user friendly but it's easy to teach anyone, I can teach my wife and kids that much, it's a simple keystroke.

How can I possibly be using the wrong display number? How can I diagnose that? All I've learned so far is that w *_will list it and *_w lists:

 16:32:22 up 29 min,  4 users,  load average: 0.15, 0.30, 0.38
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
bernd    tty8     :0               16:05   29:07  30.17s  0.08s cinnamon-session --session cinnamon

as to the wrong user yes, I'm root on the tty and bernd on the Cinnamon session and guess what, you hit the nail on the head! I owe you a grand favour. It now visibly works as I can enter your command, press return and switch back to tty8 and I can see it's restarted.

This also works: cinnamon --replace --display=:0

That solves my immediate problem.

It does not to my mind close the issue which is:

1) Inadequate documentation of the command line options for Cinnamon
2) Lack of a clear simple way to do this.

My local workaround is to put that command line in a shell script in /usr/local/bin, and I call it cr fro Cinnamon Restart and that works and I can teach it to novices. Alas it relies on hardcoding :0 but as far as I can tell it reliably starts on :0 (are there are reasons it would not?)

It seems a design flaw to me, for:

1. A system we know freezes from time to time (heck even Windows explorer does)
2. A system we know we can restart without loss (windows still in place no lost data) from a tty

that there is no simple command like cinnamon restart

that simply works, including for the root user (never heard of something that worked on my user account and not for root, and I only logged on as root as part of me thought you'd need su priviledges to stop and start service ...

Finally, I agree that the essential problem is freezes, but they may never been completely solved (as I said, even Windows explorer locks up occasionally as does Android, and I'm not an Apple customer but would be surprised if iOS didn't occasionally lock up too - though by reputation, less often than Windows ;-)

[gritty-gitty]

@glebihan: Albeit _Cinnamon_ is able to auto-respawn, the problem with all those freezes is that in such a case it does _not_, hence the need to go to a tty.

@bernd-wechner: And this need is absolute, as _Cinnamon_ won’t accept any key presses other than the [Ctrl+Alt] combos directed to X. That is, you’ll have to deal with the command line anyway (this problem won’t go away anytime soon, for it’s been there since the beginnings of _Cinnamon_, and it seems to be tied to deeper layers of the DE :-( ).

By drawing on my own experiences, I consider safer killing _Nemo_ as well, although this will close all file manager windows, of course. But for me, the freezes are clearly tied to mount or unmount operations, i.e. the file manager is frozen altogether. This complicates the matter a little, but to find out a user’s display is the easiest part therein:

#!/bin/bash
# /usr/local/sbin/cinnamon-restart
# Kill Nemo and Cinnamon, and restart them

MY_DISPLAY=$(w `whoami` | awk '/cinnamon-session/{print $3}')
echo Restarting the GUI on display $MY_DISPLAY …
killall -9 nemo cinnamon
sleep 3

#DISPLAY=$MY_DISPLAY cinnamon --replace >/dev/null 2>&1 &
VT=$(who|grep `whoami`|grep "($MY_DISPLAY)"|sed 's/.*tty//'|cut -d' ' -f1|head -1)
chvt $VT
sleep 5

DISPLAY=$MY_DISPLAY zenity --info --text="Cinnamon restarted" >/dev/null 2>&1
DISPLAY=$MY_DISPLAY nemo --no-default-window &

[glebihan]

@gritty-gitty : cinnamon does respawn when you kill it, even in the case of those freezes.

[bernd-wechner]

Nice script, it should be with the standard distro! For all the reasons I mention above.

Been a long time since I awked ;-), but too lazy to think about it now, I confess to wondering how this would work if two sessions are running? I have started two cinnamon sessions before, a second on tty9 just to see if could be done - it works, tty8 is frozen and you start a new on on tty9, of course it's at the login window and a virgin start not my goal so didn't explore it more. And likely to be rare as hen's teeth as scenarios go and not need coding for, but if the script were to be solid if it found more than one it should bomb listing them and asking to rerun with one as a an argument (easiest UI for it methinks). Just something a newb I've given MINT+Cinnamon can be taught to escape such a freeze.

I see this as a no brainer. If I'm trying to win people over from Windows to Linux, MINT+Cinnamon comes as the most recommended solution and I can see why. But if they then encounter these lock ups more frequently than on windows I'll lose them. And they will probably, I do an many I ask do.

If I then show them an easy way to fix it (tty1 and run this command) , simple enough that a newb could do it there is an opportunity here that sales folk are well aware of, of turning a problem into an asset. Many will be impressed at the separation of church and state so to speak oops I mean of Cinnamon and Linux and that you restart Cinnamon and keep your windows! Beautiful. Turned disappointment into mild pleasure ;-).

I would personally love to know how the new Cinnamon, respawned hooks onto the windows of the old ... and wonder if it's possible to start a new sessions and suck windows over to it. A pure thought experiment. As I see it Firefox say is just a program running on Linux that has hooks to a window on an Xterm, can be asked to rehook to another window on another Xterm? - on another Xserver?

Perhaps asking too much, but curious of the innards of X.

[gritty-gitty]

@glebihan: You’re right, of course ;-) I should modify my previous comment to “in such a case it does not _well_ [auto-respawn]” — otherwise we wouldn’t have to replace it…

@bernd-wechner: If you use multiple sessions a lot, you should process the subshell that generates MY_DISPLAY further. But I wouldn’t, as Cinnamon becomes relatively unstable even when you change the user _without closing_ the session of the old one.

The point is, the recovery from such freezes is not as smooth as it should be. For instance, the script above won’t work if you add any command that produces some graphical output _before_ Cinnamon stabilizes — hence the timeouts and _zenity_ waiting for user input above.

[glebihan]

@gritty-gitty : my point is precisely that you do not need to replace it. When you kill cinnamon, it respawns, which is why I said that killing cinnamon is the easiest way to restart it.

[bernd-wechner]

Oh I don't use multiple sessions ever at the moment. I looked at starting a new one and how as an experiment when trying to diagnose why "cinnamon --replace --display=:0" was bombing with errors is all, and demonstrated thereby that I could do "cinnamon --replace --display=:1" on a new session and it worked fine ... an incremental piece of evidence in the trail. Can't say I've fully nailed it or understood it, but the issue on :0 was that this command will (oddly to my mind) only work if issued by the user logged into the cinnamon session you're replacing, root can't do it! It bombs. Utterly weird.

Re: killing it, alas that's not specific enough as would need to know exactly which process/processes to kill. Further would love to understand the mechanisms of the respawn, how that happens. Doe upstart handle it for example? Or some other daemon?

[glebihan]

@bernd-wechner : it's very easy to know which process to kill.
As I said in my first answer, killall -9 cinnamon does the job.

As for the respawn, it's nothing that complicated, there's simply a wrapper around the cinnamon process, called cinnamon-launcher, which handles initially launching cinnamon and respawning it when it crashes.

[bernd-wechner]

Sorry I wasn't clear. I don't like that at all alas. It's worse even than the hardcoded assumption of :0 display in gritty-gitty's excellent script! It makes the bold assumption that no unintended process is caught by killall, which is a utility I would never use lightly I admit.

Sure, I understand the risk is low, probably very low, that this would have any negative impacts, not least demonstrated by your affection for it. But I do find it dirty in a way, not clean.

And filed issue is, that cinnamon should in it's suite of tools a clean simple tool for restarting it from a tty, much like gritty-gitty's script (albeit ideally with some display detection and choosing smarts in the rare circumstances that more than one is found). I'm a fan of clean solutions I guess.

And part of my drive here, is the MINT+Cinnamon seem to be targetting an audience of possible conversions from Windows. That is what brought me to it anyhow and I seem to recall reading in an abundance of on-line blurbs. That being the case I'd like to try eventually rolling it out to my family. But issues like these lock ups are prohibitive still (I'll lose them). And yet, a come back with a simple demonstration of fix (at present go to tty1 and issue a command and go back to tty8) they are likely to be impressed not lost. And by extension I think this scenario is probably a big one in the market of possible roll out.

[gritty-gitty]

@bernd-wechner: Oh, the point is that the script does _not_ make assumption of display :0, it just takes the first one which happens to be :0 mostly, but not necessarily…

@glebihan: Yes, the launcher respawns Cinnamon, but it doesn’t work out for me: if Cinnamon doesn’t get replaced, either it lands in its safe mode or it doesn’t relaunch properly :-(

[bernd-wechner]

Ooops, hadn't read it that closely. Close though, it still a weeny bit sloppy in the case of multiple returns and should perhaps bail with a list and accept an argument to specify one. Use case for a multiple returns then is, it bails with list, and prints usage: cinnamon-restart [display-id, where display-id is one of: .... which it found. ;-). Just an idea. I can code it myself and repost if I find time. Am squeezing posts in here between things right now. Maybe one evening.

I might also experiment with users ... turns out this command bails cryptically if a user other than the logged in user (in the cinnamon session being replaced) runs it (with a No protocol specified Window manager error - like that means anything to me.

So the script could also find a way to determine the logged-in user on that display, and su to that username and see if that works. Would need to empirically confirm that user B su'ed to user A can replace user A's cinnamon session. Pragmatically B would be root anyhow.

[gritty-gitty]

@glebihan: I have to correct myself: when the timeout are large enough, there is really no need to replace Cinnamon. Thus I changed the restart script above accordingly ;-)

[ManIVIctorious]

As far as I have understood this issue seems to be resolved, so could it please be closed?

[bernd-wechner]

Nah, can't agree so easily. At least on in 17.3. Cinnamon just won't restart properly even with the tips above. It just hangs and regularly does so when the net is busy.

Not sure about 18 yet. I would super awesome if a clear simple way to force a restart that doesn't force a log out and losing all out windows.

At least this:

cinnamon --replace --display=:0

from a console terminal, often just hangs and won't restart cinnamon in my experience. Not in a time frame I'm prepared to wait for.

What a dream it would be to have a clean restart that conserved windows reliably.

[SnoopMarshal]

@bernd-wechner you are amazing! My desktop showed nothing but a black screen and the icons! Cinnamon --replace --display=:0 worked like a charm.. was trying everything found in the internet but nothing worked. Thank you so much man!

[JeremyBoden]

All this CLI stuff isn't needed.
From the "frozen" GUI right-click on the command bar, click on Troubleshoot and take the 'Restart Cinnamon' option.
Works 100% for me and doesn't interfere with anything - but its bad that I have to do this.

[bernd-wechner]

JeremyBoden, you are kidding, right? With all due respect when Cinnamon is frozen (which happens now and again alas) it is, well frozen, and the whole point is to have a way of restarting it without losing one's session and windows from the CLI becasue the command bar does not respond, shows no menu. Nor does the keyboard - I mean you can always press ALT+F2 then type r and Enter and that will restart Cinnamon too, if only Cinnamon is alive enough to respond to ALT+F2 which again it sadly, from time to time isn't.

It's pretty stable and seems to have got better over time, but now and again ...

Problem is that sometimes even Cinnamon --replace --display=:0 from a tty doesn't work. Sometimes it does, and sometimes not. Depends on how stubbornly unresponsive Cinnamon has become.

It would be beautiful if Cinnamon kept a live login session persistent even if you killed it (kill -9 say) and restarted it explicitly but alas it does not (and perhaps cannot).

[jaszhix]

Switch TTYs, run

DISPLAY=:0 cinnamon-launcher

This will run cinnamon --replace, and preserve the metacity fallback after a crash. This is how Cinnamon is normally launched.

[bernd-wechner]

If that works reliably it is genius! And should really be better documented!

[JeremyBoden]

Is this true for LMDE3?
wmctrl -m says that my WM is Mutter (Muffin) - not metacity

[mtwebster]

That's correct. Metacity, however, is the fallback wm when cinnamon 'crashes' (along with mate panel) - this is the default in both mint and lmde3.

For cinnamon, there technically isn't a separate wm, it's all one process. He was just saying that using that command preserves your session's ability to fall back to metacity/mate (instead of just leaving you high and dry with nothing).

[JeremyBoden]

My description of a Cinnamon "Crash" was sadly mistaken.
Sorry.
I get an occasional situation where although Cinnamon is working in all
respects, all Windows act as if the contrast had been turned way down &
become almost transparent.
I started a terminal window in the GUI, started Firefox (so I could read my
saved email - with some difficulty due to the faintness of the text) and
entered
Jason's fix of DISPLAY=:0 cinnamon-launcher for the true frozen situation.
This restarted Cinnamon and restored my LMDE3 screen to normal.
I forgot to take a screenshot ;) - where should I look to see if this is a
known Cinnamon bug?

Regards,
Jeremy

On Tue, 18 Dec 2018 at 22:57, Michael Webster [e-mail]
wrote:

That's correct. Metacity, however, is the fallback wm when cinnamon
'crashes' (along with mate panel) - this is the default in both mint and
lmde3.

For cinnamon, there technically isn't a separate wm, it's all one process.
He was just saying that using that command preserves your session's ability
to fall back to metacity/mate (instead of just leaving you high and dry
with nothing).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/linuxmint/Cinnamon/issues/4763#issuecomment-448403131,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoBcM-k2DuaOB3vFNeNc1Kv2s6jqUshGks5u6XLKgaJpZM4GYHsi
.