Description of problem: Dell xps13 9360 laptop running Mga6 with sddm. The laptop is set to shutdown after an hous of inactivity. If the lid is shut, that apparently starts and then pauses. If I open the lid, say 2 days later, the power button is still lit and the sddm greeter comes on. But before I can do anything, the shutdown sequence starts, and the machine shuts down.This is the worst of all possibilities. he machine has been running for 2 days, draining the battery,and when I want to use it, I have to wait for the shutdown to complete--which "unsatisfied jobs have to time out first, making the shutdown last even longer. Version-Release number of selected component (if applicable):latest updates installed. sddm 0.14.0-13.2.mga6 How reproducible: Steps to Reproduce: 1. 2. 3.
Can you have a look at your power management settings? According to those settings, which action will be perform when you close the lid? Btw, you didn't say which desktop environment you're using ;-)
Summary: when laptop shut, shudown never starts => when laptop lid is closed, shutdown never startsWhiteboard: (none) => NEEDINFOCC: (none) => marja11
(In reply to Marja Van Waes from comment #1) > Can you have a look at your power management settings? > > According to those settings, which action will be perform when you close the > lid? > > Btw, you didn't say which desktop environment you're using ;-) Can you please reply, so that this bug report can be correctly processed?
Sorry thought I had replied. I am using sddm as the display manager, and kde plasma as the desktop environment. Lid closing should have nothing be done on any case (AC, battery, low battery) On battery, dim screen after 15min, screen switchoff aftr 50 min, shutdown after 126 min. On low battery dim, 1 min, screen after 2 min, shutdown after 5 min.
(In reply to w unruh from comment #3) > Sorry thought I had replied. No problem :-) > > I am using sddm as the display manager, and kde plasma as the desktop > environment. > Assigning to KDE team, then > Lid closing should have nothing be done on any case (AC, battery, low > battery) > On battery, dim screen after 15min, screen switchoff aftr 50 min, shutdown > after 126 min. > On low battery dim, 1 min, screen after 2 min, shutdown after 5 min.
Whiteboard: NEEDINFO => (none)Assignee: bugsquad => kde
*** Bug 24132 has been marked as a duplicate of this bug. ***
I don't agree that the settings for lid closing are unrelated, if there the setting is "suspend", then I expect the behaviour you see to happen. Why don't you change that to "Shut down"?
I do not want the computer to shut down when I close the lid. I want it shut down after its usual timeout time with no activity. But, if the lid is closed, it hangs, and then when I open the lid, it is there with the sddm logon screen, but it immediately goes into its shutdown process. Ie, it has been sitting there in my computer bag loosing power, with the shutdown process stalled. Under Advanced Power Management I have At critical level Shutdown. But if it reaches critical (5%) when the lid is shut, it does not shutdown. It does seem to log out, but then sits there until I open the lid, at which point it shuts down.
This is still happening. The system as mentioned is set to shut down after a certain period of inactivity. But if the lid is closed, that never happens, or rather it starts, and only completes when the lid is opened again. This is of course a disaster as the low power shutdown does not occur and the battery gets drained to 0, which is horrible for an Li battery. What information can I give people to determine what is happening.
Can you see something in the journal? BTW, the battery module is protected internally against too deep discharge, the thing to worry about is filesystem and open files - lost work.
CC: (none) => fri
Looking at the journal in the most recent case,it seems that the system goes into sleep mode. When the lid opens, it comes out of sleep and promptly shuts down. But nowhere do I have anything which tells it to go to sleep. I tell it to shutdown in Settings. Where is the behaviour stored? (ie not the kde GUI but the file which actually tells the system what to do on low battery or on "machine on too long". Ie, SystemSettings->EnergySaving tells it to SuspendSession by shutdown. And LidClosed is Do Nothing.
(In reply to w unruh from comment #10) > Looking at the journal in the most recent case,it seems that the system goes > into sleep mode. When it's asleep, it can't start shutdown, so it'll start that when it wakes up If you made sure that systemsettings is not set to suspend when the lid is closed, then it might be a feature of your laptop, a windows user of a Dell XPS13 9360 reported https://www.reddit.com/r/Dell/comments/6rpu2c/laptop_power_settings_ignored_dell_xps13_9360/ : > I want the laptop to stay awake when I close the lid, so I changed the power > settings to ensure the laptop 1. never goes to sleep, and 2. no action is > taken when the lid is closed. Unfortunately the laptop still goes to sleep a > couple of minutes after the lid is closed. Running the default version of > Windows 10 that came installed on the laptop. Can you have a look at your BIOS settings, in case there's a related setting, there? Do you run the latest BIOS firmware for that laptop?
I think it is a Mageia thing not a Dell one. The system goes into a deep S3 after the poweroff In SystemSettings->PowerManagement I have the fifth button checked SuspendSession with a time of 12 min (for testing). Beside the time, I have Shutdown" selected. But with the lid closed, in /var/log/messages I have the sleep session starting Apr 5 12:12:44 planet autossh[1406]: ssh exited with error status 255; restarting ssh Apr 5 12:18:29 planet plasmashell[3214]: trying to show an empty dialog Apr 5 12:18:29 planet krunner[3211]: "There are still \"-1\" items in the process of being created at engine destruction." Apr 5 12:18:29 planet korgac[3286]: QObject::disconnect: Unexpected null parameter Apr 5 12:18:29 planet korgac[3286]: QCoreApplication::postEvent: Unexpected null receiver .... Apr 5 12:18:29 planet kscreenlocker_greet[5370]: kf5.kpackage: No metadata file in the package, expected it at: "/usr/share/mga/backgrounds/" Apr 5 12:18:29 planet systemd[1]: Reached target Sleep. Apr 5 12:18:29 planet systemd[1]: Starting Suspend... Apr 5 12:18:29 planet kernel: [ 1553.838594] PM: suspend entry (deep) Apr 5 12:18:29 planet systemd-sleep[5377]: Suspending system... Then at 13:14 when I open the lid again, the sddm greeter screen came up and after about 3 sec the shutdown started, and the system closed. In /var/log/syslog I have Apr 5 12:12:44 planet autossh[1406]: ssh exited with error status 255; restarting ssh Apr 5 12:16:28 planet org_kde_powerdevil[3282]: powerdevil: Kbd backlight brightness value: 0 Apr 5 12:18:23 planet org_kde_powerdevil[3282]: powerdevil: Can't contact ck Apr 5 12:18:23 planet org_kde_powerdevil[3282]: powerdevil: Suspend session triggered with QMap(("GraceFade", QVariant(bool, true))("Type", QVariant(uint, 8))) Apr 5 12:18:28 planet org_kde_powerdevil[3282]: powerdevil: Can't contact ck Apr 5 12:18:28 planet org_kde_powerdevil[3282]: powerdevil: Suspend session triggered with QMap(("SkipFade", QVariant(bool, true))("Type", QVariant(uint, 8))) Apr 5 12:18:28 planet ksmserver[3180]: ksmserver: Shutdown called with confirm 0 type 2 and mode -1 Apr 5 12:18:28 planet ksmserver[3180]: ksmserver: After modifications confirm is 0 type is 2 and mode 3 Apr 5 12:18:28 planet org_kde_powerdevil[3282]: powerdevil: Scheduling inhibition from ":1.7" "ksmserver" with cookie 1 and reason "Shutting down system" ... Apr 5 12:18:29 planet ksmserver[3180]: CreateNotify: 33554448 Apr 5 12:18:29 planet ksmserver[3180]: CreateNotify: 33554450 Apr 5 12:18:29 planet ksmserver[3180]: MapNotify: 33554448 Apr 5 12:18:29 planet ksmserver[3180]: ksmserver: completeShutdownOrCheckpoint called Apr 5 12:18:29 planet ksmserver[3180]: MapNotify: 29360144 Apr 5 12:18:29 planet systemd[1]: Reached target Sleep. Apr 5 12:18:29 planet systemd[1]: Starting Suspend... Apr 5 12:18:29 planet kernel: [ 1553.838594] PM: suspend entry (deep) Apr 5 12:18:29 planet systemd-sleep[5377]: Suspending system... ... Apr 5 12:18:29 planet kscreenlocker_greet[5370]: kf5.kpackage: No metadata file in the package, expected it at: "/usr/share/mga/backgrounds/" Apr 5 12:18:29 planet ksmserver[3180]: CreateNotify: 33554452 Apr 5 13:14:38 planet kernel: [ 1553.838596] PM: Syncing filesystems ... done. So, it is definitely the system that is instituting the sleep, not the hardware. If you wnat the rest of the sleep shutdown session between 12:18:29 and the shutdown at 13:14:38 I can supply that. It seems that it is powerdevil that is somehow instituting sleep rather than shutdown when the lid is closed.
This kde power management is insane. In .config/powermanagementprofilerc it seems to be where the powermanagement is set. But there is nowhere that the contents of this file are explained, and the settings are idiotic-- just some numbers (it seems to be flags since the numbes seem to be powers of 2) Thus in my system I have [Battery] icon=battery-060 [Battery][DPMSControl] idleTime=600 [Battery][DimDisplay] idleTime=300000 [Battery][HandleButtonEvents] lidAction=64 powerButtonAction=16 triggerLidActionWhenExternalMonitorPresent=false [Battery][KeyboardBrightnessControl] value=50 [Battery][SuspendSession] idleTime=720000 suspendType=8 Now, The SuspendSession should be what is triggering stuff, but all I have is "suspendType=8" which tells me nothing. What does "8" mean? Where can I find out what it means? It seems to mean "shutdown after you have gone to sleep" which of course makes no sense at all.
This problem is still there on my Dell XPS13 machine. If the laptop lid is closed the system times out and goes into shutdown mode, but never actually starts the shutdown. When the lid opens again, almost anything I do causes the shutdown to continue and the machine finally shuts down. Thus the machine IS running in the background, but something with the lid closed causes it to pause in the shutdown process until the lid is opened again.
What about the status of this bug?
Status: NEW => NEEDINFOCC: (none) => ouaurelienSource RPM: sddm? => (none)Assignee: kde => ouaurelien
On Mga7 it was still a problem. I just installed Mga8 and have not tested it yet.
It was still present in Mga7 a couple of weeks ago, when I determined that the machine went into sleep mode before it had a chance to shutdown with the lid closed. I have just upgraded to Mga8 and will find out soon if the problem is still there.
The problem seems to be solved in Mga8-- both the auto-shutdown with the lid closed and the shutdown completing if the lid is closed immediately after selecting shutdown.
As Mageia 7 will reach end of support soon, closing as fixed since it ok in 8.
Status: NEEDINFO => RESOLVEDCC: (none) => davidwhodginsResolution: (none) => FIXED