Unable to start applications after suspend/hibernation

[Ruben Vermeersch]

Quite often, when resuming after hibernation, I am unable to start any applications, there is zero response from the application. This is highly annoying as it renders hibernation useless 50% of the time.

I'll provide an strace output of an application when I encounter it again.

[William Grant (wgrant)]

Can you please give us details of the hardware you are encountering this issue on? There are similar issues relating to failed reinitialization of Serial ATA devices.

[Ruben Vermeersch (ruben)]

This is a software issue (as far as I can tell), related to the session manager. I'm experiencing this on my Dell Inspiron 8600 laptop (which has IDE). It happens frequently and it's not an isolated case (as my sister also sees it often on her computer).

More debug output will be provided once I have it.

[Ruben Vermeersch (ruben)]

Ok, it happened again, good thing I left a terminal open.

The attached file shows the output of running "strace gedit"

The last lines is where it gets interesting:

socket(PF_FILE, SOCK_STREAM, 0) = 10
uname({sys="Linux", node="tokyo", ...}) = 0
connect(10, {sa_family=AF_FILE, path="/tmp/.ICE-unix/19981"}, 22) = 0
fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
write(10, "\0\1\0\0\0\0\0\0", 8) = 8
read(10,

It just hangs then.

ruben@tokyo:~ $ pidof gedit | xargs ps u
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
ruben 21096 0.3 1.1 19188 5992 pts/1 S+ 15:13 0:00 gedit
ruben@tokyo:~ $ ls -al /tmp/.ICE-unix/19981
srwxrwxrwx 1 ruben ruben 0 2006-06-09 10:08 /tmp/.ICE-unix/19981=

[Ealden Escañan (ealden)]

I experience this as well. I'm running Ubuntu 6.06 on a Fujitsu Lifebook C1211D laptop[1] which I don't think is using SATA.

[1] https://wiki.ubuntu.com/LaptopTestingTeam/FujitsuLifebookC1211D

[Ruben Vermeersch (ruben)]

It's gnome-session, starting apps with --sm-disable makes them work. When I delete the files in /tmp/.ICE-unix/ my apps start again.

Somehow gnome-session seems to be locking up.

[Ruben Vermeersch (ruben)]

It's gnome-session!

[Ealden Escañan (ealden)]

On Sun, 2006-06-11 at 15:45 +0000, Ruben Vermeersch wrote:
> It's gnome-session, starting apps with --sm-disable makes them work.
> When I delete the files in /tmp/.ICE-unix/ my apps start again.
>
> Somehow gnome-session seems to be locking up.
>

Thanks for the tip. I'll try it once I experience this problem again.

--
Ealden Esto E. Escañan <email address hidden>
GPG: 0x992B69C6 || http://ealden.net

[Ealden Escañan (ealden)]

On Mon, 2006-06-12 at 00:15 +0800, Ealden Esto E. Escañan wrote:
> On Sun, 2006-06-11 at 15:45 +0000, Ruben Vermeersch wrote:
> > It's gnome-session, starting apps with --sm-disable makes them work.
> > When I delete the files in /tmp/.ICE-unix/ my apps start again.
> >
> > Somehow gnome-session seems to be locking up.
> >
>
> Thanks for the tip. I'll try it once I experience this problem again.

I experienced this again today, and deleted /tmp/.ICE-unix. My apps
started again.

Thanks

--
Ealden Esto E. Escañan <email address hidden>
GPG: 0x992B69C6 || http://ealden.net

[Adriaan Peeters (apeeters)]

For example xterm does not have the --sm-diable option so you cannot start it that way. It is possible to start network-admin --sm-diable though to reset the network configurarion to a working state.

gnome-session might hang because of a non-working network environment, see bug #49431

[Ealden Escañan (ealden)]

On Mon, 2006-06-12 at 19:38 +0000, Adriaan Peeters wrote:
> For example xterm does not have the --sm-diable option so you cannot
> start it that way. It is possible to start network-admin --sm-diable
> though to reset the network configurarion to a working state.
>
> gnome-session might hang because of a non-working network environment,
> see bug #49431
>

I've checked #49431. I don't use a static IP and let network-manager
take care of connecting to different networks.

I imagine the effect would still be the same though, since there
shouldn't be an IP yet on resume, and then would connect to "another"
network environment.

Then again, IANA network guy :-)

--
Ealden Esto E. Escañan <email address hidden>
GPG: 0x992B69C6 || http://ealden.net

[Adriaan Peeters (apeeters)]

My gnome-session magically resumed operation after about 10 to 30 minutes. Or at least the programs I started showed up. So just having some patience helps.

[Sebastien Bacher (seb128)]

Does your loopback is still correctly configured when that happens? Does "ping 127.0.0.1" works correctly?

[Ruben Vermeersch (ruben)]

Tested this and yes, the loopback is up and working. Happens both for me (running NetworkManager) and my sister (using the usual Ubuntu network tools).

[Ealden Escañan (ealden)]

On Thu, 2006-06-15 at 10:13 +0000, Sebastien Bacher wrote:
> Does your loopback is still correctly configured when that happens? Does
> "ping 127.0.0.1" works correctly?
>

Yes it does.

--
Ealden Esto E. Escañan <email address hidden>
GPG: 0x992B69C6 || http://ealden.net

[Jan (jan23)]

I can confirm this bug on my Notebook MSI S260. It happens regularly, about once in a day. The applications start suddenly after about 10 minutes. I don't have any problem with the network and ping localhost works.

[Martin Emrich (emme)]

Hi!

I have the same symptoms here:

- Thinkpad T41p
- Ubuntu 6.06 LTS
- After resume from suspend-to-ram (or standby, don't know which S?-Level GNOME uses), gnome-terminal et al. do not start correctly
- strace -p <pid of gnome-terminal> stalls at "read(10,"
- after removing everything in /tmp/.ICE-unix/ , starting another gnome-terminal works
- but on hitting System->End Session... , the logout window still does not appear
- Killing the session with CTRL-ALT-BS returns the computer to an useable state.

Is there another way to help out? When I have some time left, I'll try to do a script strace()ing gnome-session over a suspend-resume cycle, but as this error does not appear every time, it will take some time...

Ciao

Martin

[Martin Emrich (emme)]

Hmm, after writing a script which continously attaches strace to gnome-session (and keeping it running in the background), the bug gets worse:

- It happens much more often
- After hitting CTRL-ALT-BS, gnome-session goes to D-State in ps -aux, I have to reboot to get an X session again...
- strace (running in a screen) does no longer react to CTRL-C or SIGTERM. Thus, the trace does not look very useful, the last lines always seem to stall at fd 27 (which seems to be the socket under /tmp/.ICE-Unix/<pidof gnome-session>)

[Markus Kienast (elias1884)]

I can confirm this behavior. I can not start any apps but use the existing ones. After a while the apps I clicked start.

[Richard Theil (richard-theil)]

I've reported the issue (I see on a dist-upgraded Powerbook G3 running gnome) to another bug number yesterday, looks much like a duplicate:

https://launchpad.net/distros/ubuntu/+bug/58382

[dirk (dirk-kuijsten)]

This problem is widespread, it also has more duplicate bugs in: #52200, #56140 and #61924.
Finally this bug is now acknowledged by being in confirmed status and of high importance.

[Martin Emrich (emme)]

Hello!

Are there any updates on this? This bug still appears here, with a fresh install of edgy.

[Jan (jan23)]

With an upgrade to Edgy the bug seems not to happen any more on my system.

[Richard Hult (richard-imendio)]

I still see this problem every now and then (on an uptodate edgy).

[Martin Emrich (emme)]

Ok, I kept my home directory, containing all the .gnome2, .gconf* etc.
Maybe the source of the bug is contained therein. Grepping for "gnome-session" there did not dig up something "interesting".

[Fedor Isakov (fisakov)]

I does still happen on Edgy albeit significantly less often than it used to on Dapper.

[Bastanteroma (bastanteroma)]

I had this problem on two computers. On one it was still a problem after a fresh install of edgy (maybe with a held over /home? I forget). On the other it was a problem almost every time I suspended after an upgrade (before the upgrade suspend didn't work at all), but then it disappeared on a fresh install with a new graphics card. Of course, the graphics card is an unknown variable, and I have no idea if it might affect this. Though this is most likely unrelated, to get suspend working at all with the nvidia card I had to add "NvAgp" as an Option under the Device section in my xorg.conf.

[Frank Groeneveld (frankgroeneveld)]

Same problem happens to me. (Using up-to-date Edgy).

[Josh Burdick (jburdick-gradient)]

I have this problem too, on an MSI 270, Sempron, i386. I've certainly had the problem in Dapper, possibly before, now in Edgy. I didn't report it, because I figured my report would surely be a duplicate...

Blacklisting "psmouse" doesn't help; furthermore IIRC the pointer is consistent about moving after suspend. So I don't think it's a driver issue. Also keyboard works, I can switch VTs, etc. Furthermore, in Edgy at least, it's sometime inconsistent; once today for instance I could switch tabs in Firefox, but nothing else. That suggests it's not X.

Does the time get reset every time you resume? My guess, talking through my hat, is that GNOME discards events with late-enough time stamps (as it probably should; if the system were so busy that it's getting ten-second-old mouseclicks, probably best to discard them.)

But if the clock gets updated by ntpdate or hwclock, there might be a significant timeslip that's bolloxing things up. Just guessing.

Indeed, I'll try commenting out the business end of /etc/acpi/resume.d/50-time.sh , (that is, the hwclock call), and see if that helps.

(I am of course amazed that suspend-to-RAM works as well as it does; the fact that it does is probably why this sort of thing is actually evident :)

[Martin Emrich (emme)]

Upgraded to feisty i386 yesterday, and it is still there (happening more often than ever).

[Josh Burdick (jburdick-gradient)]

I just resumed from suspend today. Some things were slightly odd; for instance, the screensaver didn't start up. I'm not sure why... At any rate, I resumed from suspend, and could click on stuff fine.

Then I went to network-manager, which was actually listing the nearby networks (possibly due to my whitelisting the ipw2200 driver, but that's a separate issue.) I selected a WPA network, it connected within 10-15 sec, but after I closed the "You are now connected..." yellow message, I couldn't click on anything, in any session.

However, the keyboard worked, and after logging into a VT and killing "x-session-manager", I could log in fine through gnome-display-manager, and type this message.

Presumably ntpdate got run (through the /etc/network/if-up.d/ntpdate script) when the wireless connected. So I believe this still supports my working theory that sudden clock changes lock up some daemon; my offhand guess is gnome-session or something dbus-related.

When I'm feeling daring, I'll try causing a lockup by drastically messing with the time by hand. More as it develops...

[Josh Burdick (jburdick-gradient)]

Setting the date to 2008 didn't reproduce the bug. Which is a strike against my theory that clock-shifts are causing the problem.

[Scott Robinson (scott-ubuntu)]

I can confirm this is occurring in feisty too. For whatever reason, gnome-session is not writing back a response to connections. The connections are being accepted, which means the gdk mainloop (as the g_io_add_watch is driven by it) is still running.

I'm going to examine the source code more, as this is a very annoying bug.

[Scott Robinson (scott-ubuntu)]

My current investigation indicates the issue is related to the Ubuntu custom login/logout dialog.

Specifically, the 13_smoother_fading patch. I'm still investigating, but I believe it is related to the time jumping during the fade event.

*grumbles about how bloated gnome-session has become*

[Sebastien Bacher (seb128)]

Might be the same problem than bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406608. Do people still have the socket pointed by SESSION_MANAGER in place when they get that problem?

[DaveR (djrpublic)]

I have no idea what you may mean here. Is there some way I can help?
Some file I can read or send to you to answer the question?

Sebastien Bacher wrote:
> Might be the same problem than bug http://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=406608. Do people still have the socket pointed by
> SESSION_MANAGER in place when they get that problem?
>
>

[André Carezia (carezia)]

Em Fri, 16 Feb 2007 14:21:02 -0000
Sebastien Bacher <email address hidden> escreveu:

> Might be the same problem than bug http://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=406608. Do people still have the socket pointed
> by SESSION_MANAGER in place when they get that problem?

Occurred here in one of our workstations (Ubuntu 6.10, last updates
applied). After resuming from suspend:

ana@constantinopla:~$ echo $SESSION_MANAGER
local/constantinopla:/tmp/.ICE-unix/5017

ana@constantinopla:~$ ls -l /tmp/.ICE-unix/
total 0
srwxrwxrwx 1 ana ana 0 2007-02-16 16:45 5017

ana@constantinopla:~$ ps -ef |grep 5017
ana 5017 4270 0 Feb16 ? 00:00:00 /usr/bin/gnome-session
ana 5068 5017 0 Feb16 ? 00:00:00 /usr/bin/ssh-agent
/usr/bin/ssh-agent /usr/bin/dbus-launch
--exit-with-session /usr/bin/gnome-session
ana 5069 5017 0 Feb16 ? 00:00:00 /usr/bin/ssh-agent
/usr/bin/dbus-launch --exit-with-session /usr/bin/gnome-session

So, in my case the SESSION_MANAGER seems to be ok. Also, .ICE-unix is
not deleted.

--
André Carezia
Eng. de Telecomunicações
Carezia Consultoria - www.carezia.srv.br

[André Carezia (carezia)]

Also, in my case, I can fix the problem issuing the commands below:

  sudo /etc/init.d/networking stop
  sudo /etc/init.d/networking start

As I use network manager, these commands affect only loopback interface. I didn't check loopback interface before restarting it. Will do next time.

[Richard Hult (richard-imendio)]

Stopping/starting networking does not help for me (also using network manager).

[André Carezia (carezia)]

Occurred again. This time, I checked loopback interface before restarting it:

lo Encapsulamento do Link: Loopback Local
          inet end.: 127.0.0.1 Masc:255.0.0.0
          endereço inet6: ::1/128 Escopo:Máquina
          UP LOOPBACK RUNNING MTU:16436 Métrica:1
          pacotes RX:21960 erros:0 descartados:0 excesso:0 quadro:0
          Pacotes TX:21960 erros:0 descartados:0 excesso:0 portadora:0
          colisões:0 txqueuelen:0
          RX bytes:10323875 (9.8 MiB) TX bytes:10323875 (9.8 MiB)

Seems OK. Again, restarting loopback interface solves the problem until next suspend ;-)

[Joachim Noreiko (jnoreiko)]

The networking stop/start commands don't fix it for me either.

[Scott Robinson (scott-ubuntu)]

If the gnome-session freezing issue occurs, please note the following:

  * Did you start the suspend via the Logout Dialog?
  * After waiting 5 - 15 minutes (depends on the initial conditions) did the Logout Dialog appear?

I'm reasonably certain I have tracked down the bug in 13_smoother_fading, but would like more information from other people who have the issue.

(This same fade bug exists in libgksu, but due to suspends not typically occurring in that use case, it hasn't cropped up.)

[Martin Emrich (emme)]

Yes, I always start suspend via the logout dialog (the red "Standby Logo" button in the panel, then the yellow standby button in the lower left corner). I'm not certain what you mean by waiting, as the logout dialog always appears directly here.

[Bastanteroma (bastanteroma)]

Suspend isn't working for me in Feisty, but in Edgy I always suspended using the logout menu. I noticed that deleting the files in /tmp/.ICE-unix/ on a funky resume allowed me start apps but not to immediately reopen the logout menu.

[Conrad Knauer (atheoi)]

FYI, there are more details by Scott Robinson in a thread on the ubuntu-devel-discuss ML ("[Bug 49221] How to solve it, and why I'm not fixing it.")

https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-March/000422.html

[Joachim Noreiko (jnoreiko)]

Does that email also imply that the workaround for this is to wait until the fade-out effect behind the logout dialog has finished before choosing 'Hibernate'?

[Bastanteroma (bastanteroma)]

That's how I understood it, but I'm the opposite of an expert. Running compiz or beryl in feisty, the logout fade is simply gone, though the same old choppy fade is still used for gksudo.

[Sitsofe Wheeler (sitsofe)]

Joachim:

The brief tests that I've done seem to suggest that is the case (but this is entirely empirical evidence).

[Scott Robinson (scott-ubuntu)]

Fixed with #12389

[Clement Lefebvre (clementlefebvre)]

Hi,

We're seeing this problem in Linux Mint 4.0 Daryna BETA021 (Gutsy based) with gnome-session 2.20.0-0ubuntu2.
--> https://bugs.launchpad.net/linuxmint/+bug/158984

[exploder (dcosner)]

Same problem here with Gutsy based LinuxMint Daryna. I can log off and back on the system but can not shut down after log off and back on. I have to Ctrl, Alt, Backspace restart the system and then shut down.

[Clement Lefebvre (clementlefebvre)]

More info about this: Apparently (thanks exploder for finding this out) removing compizconfig-settings-manager and python-compizconfig fixes the problem.