times out too early, stuck in PrepareForSleep, causing network and other services to not resume

Bug #1184262 reported by Steve Langasek on 2013-05-26
This bug affects 362 people
Affects Status Importance Assigned to Milestone
systemd-shim (Ubuntu)
High
Unassigned
Saucy
High
Unassigned
Trusty
High
Unassigned

Bug Description

After a suspend/resume, network-manager claimed that wireless was not available and would not let me reconnect to the wireless here. 'iwlist wlan1 scan' would also not work; so thinking that it was a driver problem, I rebooted the system. When it came back up, nm-applet in lightdm claimed that networking was disabled, and the option to enable it was greyed out. It could also not be enabled by nmcli. I ended up stopping network-manager, bringing up the interface via /etc/network/interfaces, and logging in... at which point, restarting network-manager *did* let me enable networking from my logged-in session.

So there are several problems here:
 - after a reboot, network-manager claimed networking was disabled.
 - nm-applet is not letting me enable networking from the lightdm session.
 - the networking was failing after a suspend/resume cycle, and could not be enabled even from inside the user session.

The last issue probably *was* a kernel driver problem; but the first two issues are network-manager problems of some kind.

SRU INFORMATION:
----------------
Reproducer:
- Force suspend to take very long by adding a sleep:
  echo -e '#!/bin/sh\nsleep 15\nexit 1' | sudo tee /usr/lib/pm-utils/sleep.d/00break
  (this will also make suspend fail, which eases testing)
- Suspend from the menu or with
  sudo gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.Suspend true
- With the 13.10 final version, systemd-shim will (often) time out, and the next Suspend call from above will fail with "Operation already in progress" and the network does not come back up. With the fixed version, network should be back up and the Suspend() call can be issued many times.

Fix:
  https://github.com/desrt/systemd-shim/commit/136ed1143077d13c2
  https://github.com/desrt/systemd-shim/commit/16a7fdc0652ad78f4

Regression potential: Errors in this code could potentially break suspend/shutdown completely, so for verification both of these functionalities ought to be tested on real hardware.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: network-manager 0.9.8.0-0ubuntu8
ProcVersionSignature: Ubuntu 3.9.0-2.7-generic 3.9.3
Uname: Linux 3.9.0-2-generic x86_64
ApportVersion: 2.10.2-0ubuntu1
Architecture: amd64
Date: Sat May 25 21:38:31 2013
InstallationDate: Installed on 2010-09-24 (974 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
IpRoute:
 default via 192.168.1.1 dev wlan1
 10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1
 169.254.0.0/16 dev wlan1 scope link metric 1000
 192.168.1.0/24 dev wlan1 proto kernel scope link src 192.168.1.106
 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
MarkForUpload: True
NetworkManager.state:
 [main]
 NetworkingEnabled=false
 WirelessEnabled=true
 WWANEnabled=true
SourcePackage: network-manager
UpgradeStatus: Upgraded to saucy on 2013-05-06 (19 days ago)
WifiSyslog:

nmcli-con:
 Error: command ['nmcli', '-f', 'all', 'con'] failed with exit code 9:
 ** (process:11977): WARNING **: Could not initialize NMClient /org/freedesktop/NetworkManager: The name org.freedesktop.NetworkManager was not provided by any .service files
 Error: nmcli (0.9.8.0) and NetworkManager (unknown) versions don't match. Force execution using --nocheck, but the results are unpredictable.
nmcli-dev: Error: command ['nmcli', '-f', 'all', 'dev'] failed with exit code 8: Error: NetworkManager is not running.
nmcli-nm:
 RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
 not running unknown unknown unknown unknown unknown unknown unknown

Steve Langasek (vorlon) wrote :
Changed in network-manager (Ubuntu):
importance: Undecided → High
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status: New → Confirmed
Sameer Morar (smorar) wrote :

A work around that works for me is killing the NetworkManager process using "sudo killall NetworkManager". The daemon re-starts and the network is restored.

Jimmy Sjölund (jimmy-sjolund) wrote :

Sameer Morar's workaround worked like a charm on my Ubuntu Studio 13.10.

Evan Huus (eapache) wrote :

I still see this fairly frequently, and it is strictly a network-manager problem. "sudo restart network-manager" causes it to reconnect gracefully without any problems or kernel magic.

I suspect a race condition, since it only happens about 1/3 of the time I suspend.

FWIW, I have a totally different network card (atheros).

Evan Huus (eapache) wrote :

First I ran "sudo stop network-manager" then ran "sudo NetworkManager --no-daemon --log-level=DEBUG >nm.log 2>&1" and then I reproduced the issue. I have attached the complete log output of network-manager from the initial receive of the "suspend" signal to the point I ctrl-C'ed it after experiencing this bug.

For context, this system has two ethernet ports (eth0, eth1) that had no attached cable during the experiment, and one atheros wifi card (wlan0) which was connected.

Hopefully something in here (or the lack of something in here) will be helpful.

Tom Cameron (drdabbles) wrote :

Not sure why my comment on my report of this bug didn't get merged into this one.

The work-around is to issue

nmcli nm sleep false

This tells NetworkManager to leave "sleep" mode. Restarting NetworkManager _happens_ to do this, but only by chance. I'd actually argue that restarting NetworkManager should _not_ reset sleep status, because you may actually want that to persist for lots of reasons over a restart.

Evan Huus (eapache) wrote :

Interesting, so it's not even a NetworkManager bug - whatever is supposed to be sending that signal to nm isn't sending it sometimes, or is sending it before nm can receive it or something?

Dimitri John Ledkov (xnox) wrote :

Maybe network-manager should ship shell snippet in pm-utils configuration directory to issue sleep false on resume/thaw?

Ritesh Khadgaray (khadgaray) wrote :

We can send such signals using pm-utils . Needs testing .

<xnox> ritz: right, so pm-utils package has direcotries with scripts that are executed on suspend/resume, hibernate/thaw.
<ritz> aah, thanks
<xnox> ritz: so network-manager or user should just add scripts there.
 ritz: see /usr/share/doc/pm-utils/README and /usr/share/doc/pm-utils/HOWTO.hooks.gz and etc.
 ritz: you can ship things in /usr/lib/pm-utils/sleep.d/ (for packages) or in /etc/pm/sleep.d (for administrator).
<xnox> I think.<xnox> ritz: yeap, see $ man 8 pm-suspend.

Evan Huus (eapache) wrote :

What component is *supposed* to be sending it that signal? I have noticed that in cases where this bug appears, other power management options also fail - trying to suspend again from the gear menu does nothing, I have to run pm-suspend from the cli. This indicates to me that some whole underlying subsystem is getting confused, and that other components may also need to be kicked - NetworkManager is just the most obvious one people notice right away.

It looks like bug 1234469 might be a duplicate of this one.

Evan Huus (eapache) wrote :

Yes, looks like a dupe.

Julien Olivier (julo) wrote :

I had the exact same bug a few months ago. The issue was that NetworkManager is supposed to work with systemd, but Ubuntu chose to implement its own replacement to systemd instead (libsystemd-daemon0 I think). The issue I had previously was caused by libsystemd-daemon0 not sending the "resume" event to NetworkManager. I'd bet this is tre same issue here...

Julien Olivier (julo) wrote :

I've just found it: it's probably this bug: https://bugs.launchpad.net/ubuntu-gnome/+bug/1187005

While inspecting the logind D-Bus object I've noticed that "PreparingForSleep" is still set to "true" after the suspend/resume cycle.

$ gdbus introspect --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1

1 comments hidden view all 189 comments
KoRnKloWn (kornklown) wrote :

Somebody marked this as a duplicate to bug 1234469, which simply isn't the case, bug 1234469 is a duplicate of this one (as others already stated), just look at the creation dates, this one is the original, so, people need to use launchpad correctly ;) And why is it that everyone (like me) has the power to delete/set duplicate status and other things???

Anyways, I fixed the duplicate status, removed it from this one and set bug 1234469 as a duplicate of this bug.

Martin Pitt (pitti) on 2013-10-20
summary: - network-manager has decided that networking is disabled, cannot be re-
- enabled from lightdm
+ [logind] stuck in PrepareForSleep, causing network and other services to
+ not resume
Changed in systemd (Ubuntu):
status: New → Incomplete

I can confirm that the command 'sudo nmcli nm sleep false' works as a temporary fix (it only works when running it using sudo).

Pablo180 (paultait22) wrote :

I'd just like to add that I have this problem, not on suspend (which I haven't tried since upgrading) but each and every time I resume from hibernate. I have to 'killall NetworkManager' to get networking back - every time.

nmcli nm sleep false - didn't work for me.

On 10/22/2013 05:50 PM, Pablo180 wrote:
> I'd just like to add that I have this problem, not on suspend (which I
> haven't tried since upgrading) but each and every time I resume from
> hibernate. I have to 'killall NetworkManager' to get networking back -
> every time.
>
> nmcli nm sleep false - didn't work for me.
>
Did you run it with sudo?

Ian, just checked and no I didn't! I'll try it again next resume.

Craig Setera (craigjunk) wrote :

I've just validated that

sudo nmcli nm sleep false

works for me after suspend

I am also having this issue after upgrading from Lubuntu 13.04 to 13.10. However, I have my power settings to just turn off the screen when my laptop is closed. Sleep and hibernate are disabled unless I manually select them from the logout menu. But the logout menu is having its own issues on another bug report.

The only solution for me is to run

sudo shutdown -P now
or
sudo reboot

I haven't tried:

sudo nmcli nm sleed false. Will attempt save my files, close my lid and see if this is a temp fix for me.

Toshiba Satellite A135-S4427

I'm also having issues with shutdown/reboot. Menu doesn't work at times;
have to run shutdown or reboot -- and even that doesn't always work.

On 10/23/2013 09:27 AM, Alfredo Pacheco Jr wrote:
> I am also having this issue after upgrading from Lubuntu 13.04 to 13.10.
> However, I have my power settings to just turn off the screen when my
> laptop is closed. Sleep and hibernate are disabled unless I manually
> select them from the logout menu. But the logout menu is having its own
> issues on another bug report.
>
> The only solution for me is to run
>
> sudo shutdown -P now
> or
> sudo reboot
>
> I haven't tried:
>
> sudo nmcli nm sleed false. Will attempt save my files, close my lid and
> see if this is a temp fix for me.
>
> Toshiba Satellite A135-S4427
>

--
Dan Gillmor
dangillmor.com/about
+1.650.868.7528

Ok. I closed my lid and quickly opened it back up. The network was disabled and I was unable to open it.

Running | sudo nmcli nm sleep false | does infact work as a temp fix.

sdowney717 (sdowney717) wrote :

I have found a serious issue now with the suspend.
The video card's fan (it is an x1300) will sometimes not spin up again!
I was using the PC and was getting video corruption then I looked down and the video fan is off.
It is free spinning so not stuck. I have the cover off as I was setting up 13.10 on the drive for another PC.

I can not use ubuntu if it is going to ruin my hardware. I certainly CAN NOT trust the suspend feature. It is totally random, sometimes following suspend the fan comes on, sometimes it does not.

Mark Whitley (mark-k-whitley) wrote :

I started experiencing this same problem immediately after upgrading to saucy. Happens like clockwork every time my netbook wakes from suspend.

Hardware: MSI WIND U230
Ubuntu version: 13.10
Network driver: rt2800pci

I found a workaround on this thread:
http://askubuntu.com/questions/362933/network-disabled-on-some-wake-ups-on-saucy-laptop

I was not able to use the "sudo service network-manager restart" fix because I do not have a 'network-manager' script in /etc/init.d/. I only have a 'networking' script and calling 'restart' on that locks up the system hard. I am able to use the "sudo killall NetworkManager" workaround.

General question: since Ubuntu seems to not support reverting dist-upgrades, is there any collection of packages I can restore to their pre 13.10 working state to avoid this horrible problem? (If not I'll seriously consider switching distribution; this is just too much)

Pablo180 (paultait22) wrote :

I don't know whether this means anything, but thought that it was worth mentioning. When using 13.04 I had previously had some problems with a kernel update and had gone back to using 3.8.0-30.44-generic. I noticed today however that despite upgrading to 13.10 several days ago, the kernel wasn't updated, I was still using 3.8.0-30.44-generic.

I manually updated to 3.11.0-12-generic, restarted, hibernated and resumed and networking was working fine. That's the first resume since upgrading in which networking has been working normally. I've since done it again to double check and it worked the second time too, so it looks like problem solved for me. Updating the kernel is the only change I have made today.

I don't know whether my problem is different to everyone else's, I only hibernate I don't suspend, but the same workarounds worked for me, so maybe this is relevant.

sdowney717 (sdowney717) wrote :

I created an executable desktop file. Click on it and network comes up for me
Single line in the file says " gksu restart network-manager". I think putting "gksu nmcli nm sleep false" would also work.

For my video card fan not respinning from suspend, I unplugged fan wire from video card board and hardwired to a system fan plug on the motherboard. Now it spins up everytime the system awakens.

On 10/23/2013 11:27 AM, Alfredo Pacheco Jr wrote:
> Toshiba Satellite A135-S4427
That's funny, I have a Satellite L875D-S7111.

I occasionally have another suspend-related proble that might be related to this one somehow: after opening my lid, sometimes the laptop resumes, then suspends again automatically after a few seconds. If I then press the power button to resume again, it does the same again and again. And, after 3 or 4 suspend-resume loops, it finally settles down and resumes correctly. I guess some internal value is randomly stuck to the "suspended" state...

@Pablo180 (paultait22) #30: I'm already running 3.11.0-12-generic, so changing to that can't be the fix.

@Julien Olivier (julo) #33: I also have this probably related problem, and so far I found no workaround for that, other than trying to resume again and again until it eventually works. I've already mentioned this in one of the duplicates (1234469), but I'll repeat the log I get from systemd-logind for a case in which the first 3 resumes failed, but the fourth one succeeded.
Lid closed.
Suspending...
Failed to execute operation: Message did not receive a reply (timeout by message bus)
Suspending...
Failed to execute operation: Message did not receive a reply (timeout by message bus)
Suspending...
Failed to execute operation: Message did not receive a reply (timeout by message bus)
Suspending...
Lid opened.
Operation finished.

Other problems I encountered that seem also related: sometimes the computer fails to suspend and sometimes even fails to shutdown. Everything worked fine before this crappy Ubuntu upgrade. I'm on a Dell Latitude 6400.

little jo (littel-jo) wrote :

Hello,

I have the same bug. But there is no problem of network if you activate XMIR.

Pablo180 (paultait22) wrote :

@Catalin you're right, it happened again. That is one in five resumes that the network fails to resume though, rather than every time like it did before, but still annoying.

Sicco van Sas (sicco) wrote :

I have the same problem as #33 (julo), where my laptop automatically goes back to suspend after waking up. I can reproduce this as follows:

I start up my laptop, suspend it the first time, wake it up again and I can work on it just fine (except for this bug causing me to have no internet connection). The second time I then suspend and wake up, my laptop will automatically go back to suspend within 30 seconds (whether I log in or not). This cycle then continues and I'm forced to reboot in order to fix it. Note that this happens whether I do or do not use temporary internet connection fix 'sudo nmcli nm sleep false'.

Is this bug related, or should I (and julo) start a new bug report?

Alexander List (alexlist) wrote :

I observed the same bug with current Saucy. Hardware is Lenovo TP x201 using iwlwifi.

After resume from suspend, networking is disabled. Enabling it in nm-applet has no effect.

This does work for me, every time:

sudo nmcli nm sleep false

On 10/24/2013 06:14 PM, Alexander List wrote:
> I observed the same bug with current Saucy. Hardware is Lenovo TP x201
> using iwlwifi.
>
> After resume from suspend, networking is disabled. Enabling it in nm-
> applet has no effect.
>

***UPDATE***
Yesterday morning I decided to re-install Lubuntu. I spent a good time prepping/reformatting an HDD to backup all the files I wanted to save.

I burned the Lubuntu 13.10 ISO in preparation to perform a fresh install seeing as how the upgrade from .04 to .10 had plagued me with many bugs. I rebooted, reformatted and partitioned the HDD and successfully installed Lubuntu 13.10.

As of now, 13.10 has been running with no issues. I did have the issue with Xfce4 power manager not running the first time, but that has since resolved itself.

I would also like to announce that network services resumes after I close and open the laptop. In power manager, I set my settings to "Do Nothing' when the lid is closed. The network icon does indicate no connection for a few seconds, but then restarts/resumes or establishes the saved WiFi connection.

This has resolved many issues that I have had and may work for others as well. Could I ask if anyone else having issues with the upgrade from 13.04 to 13.10 without a fresh install attempt a fresh install and also report if this solves the issue?

TOSHIBA SATELLITE A135-S4427
Lubuntu 13.10
3.11.0-12-generic (#19-Ubuntu SMP Wed Oct 9 16:12:00 UTC 2013)

Changed in systemd (Ubuntu):
status: Incomplete → Confirmed
Martin Pitt (pitti) on 2013-10-30
affects: network-manager (Ubuntu) → systemd-shim (Ubuntu)
Changed in systemd-shim (Ubuntu):
status: Confirmed → Incomplete
description: updated
Martin Pitt (pitti) on 2013-11-04
summary: - [logind] stuck in PrepareForSleep, causing network and other services to
- not resume
+ [logind] times out too early, stuck in PrepareForSleep, causing network
+ and other services to not resume
Changed in systemd (Ubuntu):
status: Confirmed → Invalid
Changed in systemd-shim (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
status: Incomplete → In Progress
Martin Pitt (pitti) on 2013-11-04
Changed in systemd (Ubuntu Saucy):
status: New → Invalid
Changed in systemd-shim (Ubuntu Saucy):
status: New → Triaged
importance: Undecided → High
Martin Pitt (pitti) on 2013-11-11
description: updated
Martin Pitt (pitti) on 2013-11-11
Changed in systemd-shim (Ubuntu Trusty):
status: In Progress → Fix Committed
description: updated
Martin Pitt (pitti) on 2013-11-12
Changed in systemd-shim (Ubuntu Saucy):
importance: High → Undecided
status: Triaged → In Progress
importance: Undecided → High
assignee: nobody → Martin Pitt (pitti)
summary: - [logind] times out too early, stuck in PrepareForSleep, causing network
- and other services to not resume
+ times out too early, stuck in PrepareForSleep, causing network and other
+ services to not resume
Changed in systemd-shim (Ubuntu Trusty):
status: Fix Committed → Fix Released
Martin Pitt (pitti) on 2013-11-13
Changed in systemd-shim (Ubuntu Trusty):
milestone: none → ubuntu-13.11
Changed in systemd-shim (Ubuntu Saucy):
status: In Progress → Fix Committed
tags: added: verification-needed
Rafael Levi (rlevi66) on 2013-11-15
tags: added: verification-failed
removed: verification-needed
Martin Pitt (pitti) on 2013-11-15
tags: added: verification-needed
removed: verification-failed
109 comments hidden view all 189 comments
Martin Pitt (pitti) wrote :

Thanks everyone for testing and your patience! We got sufficiently many verification results now. Let's move this to -updates after the 7 days are over, and close this bug report which already got way out of hand. Remaining network failures after resume should be discussed on bug 1252121, I left some debugging questions there.

tags: added: verification-done
removed: verification-needed
Martin Pitt (pitti) wrote :

For the record: anyone who is still affected by this particular symptom (network not coming up after suspend), please subscribe to and have a look at bug 1252121. I put a fix into my https://launchpad.net/~pitti/+archive/sru-test PPA (systemd-shim version 5-0ubuntu0.0pitti1). This is the only package in the PPA, so it's safe to just dist-upgrade. This really ought to fix this problem properly. Please let me know positive and negative results in bug 1252121.

If you have another suspend problem (some people reported that suspend takes very long), please file a new bug.

Thanks!

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package systemd-shim - 4-0ubuntu0.13.10

---------------
systemd-shim (4-0ubuntu0.13.10) saucy-proposed; urgency=low

  * New upstream release:
    - Flush bus before exiting on idle to avoid a race where a message is
      queued up but not yet sent. (LP: #1184262, part 1)
    - Adjust the definition of "inactivity" to be 10 seconds after done
      processing the last request instead of 10 seconds after we started.
      This matters for long-running tasks like suspend. (LP: #1184262, part 2)
    - Don't exit-on-idle while shutting down to avoid losing the flag that
      tells us we are in the middle of a shutdown. (Necessary, but not
      sufficient for LP #1211514)
 -- Martin Pitt <email address hidden> Tue, 12 Nov 2013 09:31:19 +0100

Changed in systemd-shim (Ubuntu Saucy):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for systemd-shim has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Changed in systemd-shim (Ubuntu Saucy):
assignee: Martin Pitt (pitti) → nobody
Changed in systemd-shim (Ubuntu Trusty):
assignee: Martin Pitt (pitti) → Gruia Catalin (catalynn-nr1)
Anton Statutov (astatutov) wrote :

I still have this issue. The system is up-to-date.

My network controller:
44:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)

Linux kernel:
Linux stant-laptop 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:07:40 UTC 2013 i686 i686 i686 GNU/Linux

Package version:
ii systemd-shim 4-0ubuntu0.13.10

Can someone hint me what have I missed?

Anton Statutov, if you still have this issue, than this report doesn't cover your problem as it is marked Fix Released. Please file a new report via a terminal:
ubuntu-bug systemd-shim

Changed in systemd-shim (Ubuntu Trusty):
assignee: Gruia Catalin (catalynn-nr1) → nobody

This bugs keeps affecting me even with the latest version. Can I do something to get this fixed?

Sergei Solo (solomatkins) wrote :

In latest version of Ubuntu 14.04 this bug not fixed!
I can't enable wireless networking after my laptop resumed from suspend.

p.s. suspend turning with some errors too:
1) It take more time (in Ubuntu 12.04 laptop suspend faster)
2) before display turns off and laptop become full suspended - I see Ubuntu lock screen and hear Ubuntu notice sound.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1184262

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Changed in linux (Ubuntu Saucy):
status: New → Incomplete
Changed in linux (Ubuntu Trusty):
status: New → Incomplete

ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: cif 2063 F.... pulseaudio
CurrentDesktop: Unity
DistroRelease: Ubuntu 14.04
HibernationDevice: RESUME=UUID=78205ef1-1270-4794-b8c5-647151a38a07
InstallationDate: Installed on 2014-04-15 (16 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Beta amd64 (20140326)
MachineType: Dell Inc. Dell System XPS L322X
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic root=UUID=457285fa-1fe0-4723-88de-4f3c0a9aaebe ro video=eDP1:d quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-24-generic N/A
 linux-backports-modules-3.13.0-24-generic N/A
 linux-firmware 1.127
Tags: trusty trusty trusty
Uname: Linux 3.13.0-24-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare scanner sudo
_MarkForUpload: True
dmi.bios.date: 01/22/2013
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A07
dmi.board.name: 0WG38X
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: 0.1
dmi.modalias: dmi:bvnDellInc.:bvrA07:bd01/22/2013:svnDellInc.:pnDellSystemXPSL322X:pvr:rvnDellInc.:rn0WG38X:rvrA00:cvnDellInc.:ct8:cvr0.1:
dmi.product.name: Dell System XPS L322X
dmi.sys.vendor: Dell Inc.

tags: added: apport-collected trusty

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Joao Natali / Carlos A., please do not add bug tasks nor apport collect to this report, as it is closed. If you are having a bug in Ubuntu, so your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

no longer affects: linux (Ubuntu)
no longer affects: linux (Ubuntu Saucy)
no longer affects: linux (Ubuntu Trusty)
Anton Statutov (astatutov) wrote :

Christopher M. Penalver, Carlos A., there is already a continuation of this bug #1252121.

sayth (flebber-crue) wrote :

This bug exists in 14.04. I can manually reconnect to wireless by typing

sudo service network-manager restart

Yanpas (yanpaso) wrote :

Have somebody tried to install the latests kernel versions? Will it fix the trouble?

Pavel Roskin (proski) wrote :

I'm on fully up-to-date Ubuntu 14.04 with the latest kernel 3.13.0-36-generic, and I got this error. I have a Lenovo ThinkPad W530. I use it either with the internal monitor or with an external monitor connected to displayport. I don't remember what I did today. I think I connected the display cable, closed the lid and then logged in. I do it every day, but something must have been slightly different today.

I got "network disabled". I clicked on "Enable Networking" several times, but it didn't help. There was no error message and no change in the menus shown on left-click or right-click on the nm-applet.

This didn't work:

# service network-manager restart
stop: Unknown job: network-manager
start: Unknown job: network-manager

This worked:

# nmcli nm
RUNNING STATE WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
running asleep enabled enabled enabled enabled
# nmcli nm sleep false

nm-applet should show the sleep state and should wake up NetworkManager if requested by the user.

Ideally, it would be great not to put the network to sleep if the computer is not going to sleep. And the computer should not go to sleep if the lid is being closed but there is a display connection.

information type: Public → Public Security
information type: Public Security → Public

@ madmin314:

If you are sure this is a security bug, please:

 1. Explain why do you think so.
 2. Mark it as "Public Security" again.

Pavel Roskin (proski) wrote :

I got the problem with "sleeping network" again. This time I'm absolutely sure I wasn't doing anything that could provoke the sleep. The computer was with the lid closed, HDMI connected to the external monitor. I left for lunch. When I returned. the network was "sleeping", the crescent shaped LED on the lid was blinking.

The last messages from "dmesg -T":

[Thu Sep 11 07:57:39 2014] type=1400 audit(1410436608.790:58): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/cupsd" pid=12685 comm="apparmor_parser"
[Thu Sep 11 10:14:42 2014] perf samples too long (2523 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[Thu Sep 11 12:13:22 2014] PM: Syncing filesystems ... done.
[Thu Sep 11 12:13:22 2014] PM: Preparing system for mem sleep

I was away at 12:13.

I am on Ubuntu 14.04 and am still experiencing this issue.

Chris Morris, if you are experiencing an issue still, then this bug report had nothing to do with your problem. Please file a new report.

Pablo180 (paultait22) wrote :

There's no need to file another bug report, it will only be marked as a duplicate. This bug has not been fixed for everyone and continues on here:-
https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1252121

Changed in systemd-shim (Ubuntu Trusty):
milestone: ubuntu-13.11 → none
no longer affects: systemd (Ubuntu Trusty)
no longer affects: systemd (Ubuntu Saucy)
no longer affects: systemd (Ubuntu)

still present in Xenial

Displaying first 40 and last 40 comments. View all 189 comments or add a comment.