hanging suspend job prevents shutdown

Bug #1441253 reported by Andreas Schultz
224
This bug affects 47 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

poweroff (systemd poweroff) and reboot no longer work

running sudo sytemd poweroff generates this:

Failed to start poweroff.target: Transaction is destructive.

journal log also shows:

Apr 07 18:30:12 alice polkitd(authority=local)[1088]: Registered Authentication Agent for unix-process:32412:2895609 (system bus name :1.194 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Apr 07 18:30:12 alice systemd[1]: Requested transaction contradicts existing jobs: Transaction is destructive.
Apr 07 18:30:12 alice polkitd(authority=local)[1088]: Unregistered Authentication Agent for unix-process:32412:2895609 (system bus name :1.194, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)

Output of systemctl list-jobs
 JOB UNIT TYPE STATE
6009 suspend.target start waiting
6010 systemd-suspend.service start running
6014 anacron-resume.service start waiting

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: systemd 219-6ubuntu1
ProcVersionSignature: Ubuntu 3.19.0-12.12-generic 3.19.3
Uname: Linux 3.19.0-12-generic x86_64
NonfreeKernelModules: fglrx
ApportVersion: 2.17-0ubuntu1
Architecture: amd64
Date: Tue Apr 7 18:32:27 2015
MachineType: Hewlett-Packard HP EliteBook 8560w
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-3.19.0-12-generic root=UUID=90fa42f5-708d-4432-9241-315b9c08ba98 ro nomodeset rootflags=subvol=@
SourcePackage: systemd
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: Upgraded to vivid on 2015-03-02 (36 days ago)
dmi.bios.date: 08/04/2014
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 68SVD Ver. F.50
dmi.board.name: 1631
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 01.3D
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvr68SVDVer.F.50:bd08/04/2014:svnHewlett-Packard:pnHPEliteBook8560w:pvrA0001D02:rvnHewlett-Packard:rn1631:rvrKBCVersion01.3D:cvnHewlett-Packard:ct10:cvr:
dmi.product.name: HP EliteBook 8560w
dmi.product.version: A0001D02
dmi.sys.vendor: Hewlett-Packard

Revision history for this message
Andreas Schultz (aschultz) wrote :
Revision history for this message
Martin Pitt (pitti) wrote :

There is a suspend job running, which collides with shutting down (you can only do one or the other). Do you know what triggered the suspend? (lid close, indicator, or you didn't request this explicitly). Can you reproduce this situation? Does suspend normally work for you?

The kernel log only shows that it's about to suspend, but doesn't actually do it. That smells suspicious.

Changed in systemd (Ubuntu):
status: New → Incomplete
summary: - poweroff no longer works
+ hanging suspend job prevents shutdown
Revision history for this message
Andreas Schultz (aschultz) wrote :

The system is a Laptop in a docking station, two external monitors, booted up with lid closed.

Last time I tried (a week ago) , the system suspended, but didn't wake up properly (external monitors didn't turn on). At that time I attributed that to the btrfs lookup that has been plaguing the system lately (probably the issue discussed here: http://www.spinics.net/lists/linux-btrfs/msg42637.html)

The suspend isn't running directly after a clean boot. I was able to trigger it by locking and unlocking the screen.

journal shows the suspend event, but not the reason why....

I did some more testing:

1. booted to clean state, no jobs running -> suspend from menu works, system resumes almost correctly (wired ethernet has neither IPv4 nor IPv6 address - both are normally present and working, disabled/reenable in network manager fixes that)

2. booted to clean state, no jobs running -> wait for idle screen or lock the screen from menu, screen blackens, takes two to three seconds to return from black screen to login screen, afterwards suspend jobs are running, poweroff is broken, manual suspend (from menu) leaves system in semi broken state (is alive, task switcher is reacting, but screen has a grey overlay and no window reacts to input, mouse is frozen as well)

Revision history for this message
Martin Pitt (pitti) wrote :

We don't want to shutdown while a suspend is running, and vice versa. This would be confusing and could lead to data loss in the worst case. Can you please instead file a bug against the kernel about the btrfs failure? We should fix suspend/the file system properly :-)

Note that you can still shutdown with "reboot -f" or "poweroff -f".

Changed in systemd (Ubuntu):
status: Incomplete → Won't Fix
Revision history for this message
Ville Ranki (ville-ranki) wrote :

I just experienced the same issue, but I don't have anything related to btrfs in logs. I also had a problem on a laptop (Thinkpad E540) with external HDMI monitor not waking up. I tried to wake up the monitor by closing and opening the lid. Finally I tried to shut down in the display manager but nothing happened. Journalctl showed the same "Failed to start poweroff.target: Transaction is destructive." error. Before this Suspend has never worked on the laptop.

Perhaps the issue is in non-working suspend hanging and not related to btrfs.

Revision history for this message
eotakos (eotakos) wrote :

Same here. I have this problem since I updated to 15.04 that goes with the 3.19 kernels.
With the previous series of kernels 3.16 it was working just fine.

My laptop is a sony vaio vgn-cs11z. In my case failing to sleep has nothing to do with external devices, it happens anyways.
Also after the failed sleep I cannot shutdown properly.

I confirm that I can still hard shut off everything with "reboot -f" or "poweroff -f".

Revision history for this message
Philosoft (philosoft) wrote :

Same here. Ubuntu 16.04 (as of today), asus laptop, no external monitors. cannot poweroff, suspend, hibernate and reboot. reboot -f and poweroff -f commands do NOT work

Revision history for this message
alvin (alvinshonggo) wrote :

Confirm same issue in Lubuntu 15.10, with same step to produce this bug.
Root[system] file is locked, can't write anything in /
but not happen if i change options for "When Laptop lid is close" to "Switch Off Display".
Confirm -f 'forcing' is work in reboot and poweroff.

Revision history for this message
Robin Winslow (nottrobin) wrote :

Same issue with Dell XPS 13 9350 and Ubuntu 15.10. The graphical "reboot" and "shut down" buttons don't do anything, and from the CLI I get:

$ reboot
Failed to execute operation: Transaction is destructive.

I imagine it's associated with closing the lid to suspend because when I first start the system it reboots fine. It resumes fine when I open the lid in the sense that I can enter my password and continue to use Ubuntu, but it would make sense if there's something hanging about in the background. I don't know how to check this.

Revision history for this message
Mick Clarke (mick-clarke) wrote :

Exact same issue for me also. Dell XPS 15 (9550) running Ubuntu 16.04.

The issue is ONLY reproducible after a suspend. Once the laptop is suspended UI controls do nothing; from commandline, reboot, halt or poweroff return the same error:

Failed to execute operation: Transaction is destructive

I haven't tried the -f flag on commandline.

Revision history for this message
Ambrose Li (ambrose-li) wrote :

Same issue with Ubuntu 15.04. Systemd just suddenly decides to refuse rebooting. System is not suspending.

Revision history for this message
Miguel A. Martinez (migmartri) wrote :

Same problem here, Ubuntu 16.04 on dell xps 13 9350 4.4.0-21-generic

After a suspend I can not shutdown nor reboot, getting the error mentioned.

Revision history for this message
roboguy (james-fitzsimons) wrote :

I also have this problem. After a suspend I can't shutdown or reboot either from Gnome/unity or a terminal.

I've got a clean install of Ubuntu 16.04 LTS running 4.4.0-21-generic on a Dell XPS 13 9350 laptop.

Revision history for this message
Robert Jansen (rj6603) wrote :

Same problem here. Xubuntu 14.04 through 16.04.
Suspend, reboot, shutdown.
All fail in some or other way on all the above versions.

On 16.04:

shutdown -h now

Failed to start poweroff.target: Transaction is destructive.

and

systemctl suspend

fails because a suspend process is already in progress. If I kill this process, the machine suspends immediately but is unusable after power on ( black screen or no networking etc ).

Revision history for this message
Ian Santopietro (isantop) wrote :

Had a couple of reports of this on System76 Machines. It appears this is manifests as an incomplete resume, where some job in the resume doesn't terminate, leading systemd to think the machine is still resuming, while at the same time the system appears to be up and running normally.

Revision history for this message
Ian Santopietro (isantop) wrote :

Had a couple of reports of this on System76 Machines. It appears this is manifests as an incomplete resume, where some job in the resume doesn't terminate, leading systemd to think the machine is still resuming, while at the same time the system appears to be up and running normally. This is a very frustrating problem for our users, because it prevents them from cleanly shutting down their computer.

Revision history for this message
Pierre.Bornancin (pierre-bornancin-gmail) wrote :

Same issue with XPS DE 9350 upgraded to 16.04.

Revision history for this message
fcole90 (fcole90) wrote :

pitti, please change the status of this bug as the problem is not related to btrfs but is bug by itself. I'm experiening this since 16.04 without any btrfs file system

Revision history for this message
Martin Pitt (pitti) wrote :

Indeed it isn't related to btrfs, but we still don't want to allow shutdown while the machine is suspending, and vice versa.

Revision history for this message
Robert Jansen (rj6603) wrote :

I think it is related to the monstrosity called systemd.

Using this command to suspend solves all suspend/resume problems here

echo mem> /sys/power/state

I guess this command directly tells the kernel to suspend, without relying on buggy systemd crap.

Revision history for this message
Alberto Santini (alberto.santini-deactivatedaccount) wrote :

I could not agree more with Robert Jansen, as I also think the problem is caused by the systemd plague. Steps to reproduce on a Thinkpad X1 Carbon 4th gen:

1) Turn on; shutdown -h now => no problem;
2) Turn on; sleep (e.g. close lid); wake up (e.g. open lid); shutdown -h now => problem!

Doing a ps aux | grep systemd, however, does not show any systemd-sleep process that might be hanging.

Revision history for this message
berend (berenddeboer) wrote :

Same here, also system76 laptop. I think I get it after a failed suspend. I.e. close laptop lid, and it won't suspend. When I open the lid again, I have no network. Then I can't reboot. Factors that may impact is that I have nfs directories mounted (using autofs, so hopefully not mounted), and a bluetooth headset.

I noticed that when typing "sync" the terminal hangs.

Revision history for this message
Eero (eero+launchpad) wrote :

This happened to me and I'm NOT using BTRFS. My partitions are EXT4 formatted.

Revision history for this message
Scarabol (scarabol) wrote :

Similar issue for me like, berend.

hanging "systemd-sleep suspend" process after wake up.
"reboot -f" does NOT work

Revision history for this message
Jeroen Ruigrok van der Werven (asmodai) wrote :

Xubuntu 16.04 user here on EXT4. I don't use suspend on my Dell Latitude laptop at all. Was just trying to reboot after noticing my network manager indicator icon was in limbo and 'lo and behold:

% sudo -H shutdown -P now
Failed to start poweroff.target: Transaction is destructive.
See system logs and 'systemctl status poweroff.target' for details.

% systemctl status poweroff.target
● poweroff.target - Power-Off
   Loaded: loaded (/lib/systemd/system/poweroff.target; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:systemd.special(7)

% ps ax | grep systemd
  359 ? Ss 0:00 /lib/systemd/systemd-journald
  412 ? Ss 0:00 /lib/systemd/systemd-udevd
 1187 ? Ss 0:00 /lib/systemd/systemd-logind
 1217 ? Ss 0:02 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
 2014 ? Ss 0:00 /lib/systemd/systemd --user
27605 ? Ss 0:00 /lib/systemd/systemd-sleep suspend

I work with the lid closed on a dual monitor system.

Digging through the journal is interesting due to:

dec 21 10:52:38 2-1b systemd-logind[1187]: Suspending...
dec 21 10:52:38 2-1b NetworkManager[1253]: <info> [1482313958.2467] manager: sleep requested (sleeping: no enabled: yes)
dec 21 10:52:38 2-1b NetworkManager[1253]: <info> [1482313958.2468] manager: sleeping...
dec 21 10:52:38 2-1b NetworkManager[1253]: <info> [1482313958.2468] device (wlp3s0): state change: unavailable -> unmanaged (reason 'sleeping') [20 10 37]
dec 21 10:52:38 2-1b NetworkManager[1253]: <info> [1482313958.2477] manager: NetworkManager state is now ASLEEP
dec 21 10:52:38 2-1b whoopsie[1255]: [10:52:38] offline
dec 21 10:52:38 2-1b obexd[2450]: Terminating
dec 21 10:52:38 2-1b polkitd(authority=local)[1433]: Unregistered Authentication Agent for unix-session:c2 (system bus name :1.46, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
dec 21 10:52:38 2-1b systemd[1]: Reached target Sleep.
dec 21 10:52:38 2-1b lightdm[1688]: pam_unix(lightdm:session): session closed for user jeroenr
dec 21 10:52:38 2-1b systemd[1]: Starting Suspend...
dec 21 10:52:38 2-1b systemd-sleep[27605]: Failed to connect to non-global ctrl_ifname: (nil) error: No such file or directory
dec 21 10:52:38 2-1b NetworkManager[1253]: <info> [1482313958.3907] dns-mgr: Writing DNS information to /sbin/resolvconf
dec 21 10:52:38 2-1b dnsmasq[1706]: setting upstream servers from DBus
dec 21 10:52:38 2-1b systemd-sleep[27613]: /lib/systemd/system-sleep/wpasupplicant failed with error code 255.
dec 21 10:52:38 2-1b dnsmasq[1706]: using nameserver 8.8.8.8#53
dec 21 10:52:38 2-1b systemd-sleep[27605]: Suspending system...
dec 21 10:52:38 2-1b dnsmasq[1706]: using nameserver 8.8.4.4#53
dec 21 10:52:38 2-1b kernel: PM: Syncing filesystems ... done.
dec 21 10:52:38 2-1b kernel: PM: Preparing system for sleep (mem)

Somehow the system was trying to go to sleep with me actually working on it.

Unless... I did log out and in again for fixing up my input methods. But why would systemd register a XFCE logout as a request to suspend?

Revision history for this message
mirak (mirak-mirak) wrote :

I have same issue on XUbuntu 16.04 on a Acer Aspire One ZA3.
When I close the screen to go to sleep, then after that I can't get back the wifi connection, and I can't shutdown.
Reboot -f works though.

Revision history for this message
mohtaw (mohtaw2-z) wrote :

 i have the same issue on 16.10 Dell Latitude E6430
i can't use the interface to shutdown or reboot and for

#shutdown -h
ubuntu Failed to power off system via logind: There's already a shutdown or sleep operation in progress

and only i can reboot or shutdown using the -f

# shutdown -f

$ uname -a
Linux XLAP 4.8.0-46-generic #49-Ubuntu SMP Fri Mar 31 13:57:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Revision history for this message
Michael Neuffer (neuffer) wrote :

This still exists in Ubuntu 18.04(alpha)
I have the additional fun effect that my Dell M4800 laptop (lid closed, with 2 external monitors attached via docking station) suspends immediately after logging into the display manager (doesnt matter if it is gdm3 or lightdm) on boot. Only after waking up the laptop again I can start working.

If the laptop sits idle for a little while, it will also suspend and them might or might now wake up again properly (the behaviour of gdm3 is worse here then lightdm).
The laptop is configured NOT to suspend ine the Gnome Power settings.

Revision history for this message
Michael Neuffer (neuffer) wrote :

This still exists in Ubuntu 18.04(alpha)
I have the additional fun effect that my Dell M4800 laptop (lid closed, with 2 external monitors attached via docking station) suspends immediately after logging into the display manager (doesnt matter if it is gdm3 or lightdm) on boot. Only after waking up the laptop again I can start working.

If the laptop sits idle for a little while, it will also suspend and them might or might now wake up again properly (the behaviour of gdm3 is worse here then lightdm).
The laptop is configured NOT to suspend ine the Gnome Power settings.

Revision history for this message
daniel CURTIS (anoda) wrote :

Hello.

I'm having the same problems with shutdown. Yesterday, I've choosed "menu/logout/halt" option instead of "menu/logout/shutdown". And problems started to happen: I could not even reboot or shutdown computer, because every time when I wanted to do this, there was a window to unblock session (I have had to enter my user password and there was not even internet connection - it could not be connected via NetworkManager! etc.) For now, a solution is: press "RESET" and next "POWER" button for a few seconds. That's the only way to shutdown computer now. I've decided to try shutdown system via shutdown(8) command but it did not work:

[~]$ shutdown now
Failed to power off system via logind: There's already a shutdown or sleep operation in progress

[~]$ systemctl list-jobs
No jobs running.

Anyway, there is not LightDM now! I have to login via "unblock" window mentioned above. And when I want to edit e.g. 'rtkit-daemon.service' file via 'mousepad', there is a WARNING message (** (mousepad:2869): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-*: Connection refused). It happens with every file, that I want to edit etc. Log files contains many entries related to the 'rtkit-daemon' (please see 1.) But this is not important here.

I apologize for such a comment, but shutdown issues, started to happen after described situation. I have no idea if it's important, but it started to happen when I choosed - by accident - 'halt' option instead of 'shutdown' during logout.

● Release: 16.04.4 LTS
● Xfce: 4.12 (according to 'xfce4-about' command)

Thanks, best regads.
____________________
1. https://bugs.launchpad.net/ubuntu/+source/rtkit/+bug/1547589 (comment #3)

Revision history for this message
Eugenio González (eugeagb) wrote :

Hello

I have same issue, I'd reported in https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1545188?comments=all

The file obtained with "journalctl -b > log.txt" is https://pastebin.com/LNX2B4Ye

Thanks a lot

Revision history for this message
jiojio (jiojio) wrote :

Same problem here.

I'm using
- system: Ubuntu Desktop 18.04 LTS
- machine: Lenovo Thinkpad X1 Extreme (Nvidia GeForce GTX 1050 Ti graphic card)
- Thinkpad Thunderbold 3 docking station
- external monitor (display port from docking station)

I'm booting with the lid closed.

Directly after clean boot, Wifi is not available and I am not able to shut down.

> systemctl list-jobs

outputs the following:

JOB UNIT TYPE STATE
2026 systemd-suspend.service start running
2027 suspend.target start waiting

After canceling both jobs, Wifi immediately starts working and I am able to shut down via
> shutdown -P now

Thanks for your support.

Revision history for this message
Jeet Sukumaran (jeetsukumaran) wrote :

Reporting exact same issue.

Running 18.04.1 on System76 Serval WS.

(1) On clean boot, (most times) no network connection. Have to run:

> sudo service network-manager restart

(2) Suspend/power off fails, and have to kill existing hanging suspend

Revision history for this message
Jeet Sukumaran (jeetsukumaran) wrote :

On some more investigation, the problem seems to be with operating with the laptop lid closed (while it is plugged in to an external monitor). This is a standard usage for me. Upon booting, I usually close the lid at the login screen or after logging in. The laptop display goes off, everything gets transferred to the external monitor and life goes on an usual. This has led me to previously think that the system is smart enough to recognize that, as the external monitor is plugged in, it should not suspend. This may nbe the case, but if so, there appears to be a split personality: the OS initiates a sleep command and suspends it. It is this that causes all the issues.

The workaround is to get the OS to ignore the laptop lid being closed.
Edit '/etc/systemd/logind.conf', and replace (or just simply add after) the line:

#HandleLidSwitch=suspend

the following:

HandleLidSwitch=ignore

And reboot or restart the service.

And voila! No more issues regardless of whether or not the laptop lid is open or closed. Power modes (shutdown, suspend etc.) all work, network manager is available from the get-go, etc. etc. etc.

Of course, I presume this means that you cannot expect the system to suspend when you close your laptop lid and it is not connected to any monitors OR when you disconnect all external monitors from the laptop as it used to (and which, arguably, is desirable and expected behavior). Perhaps if we could have the HandleLidSwitch execute a script which uses ``xrandr`` to see any external monitors are connected and only then suspend? But the difficulty then might be for the OS to know what the laptop native display ID is. In fact, I suspect that this could be the issue. If so, a prediction would be that everything Just Works (fine) for laptops which have standard ID (as given by xrandr,e.g. LVDS1), but not for others (e.g., my laptop display has "DP-0" for its output ID).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.