In the last few days, pm-powersave is being called roughly once per second, which is logging to /var/log/pm-powersave.log until there's no disk space left. I don't think I have any custom configuration of pm-utils or related software. I've worked around the issue by installing a script that sleeps 600 seconds into /etc/pm/power.d/zzzsleep, but this obviously isn't a real solution... It appears to be getting called by acpid, so maybe the problem really lies there: ├─acpid │ └─sh -c /etc/acpi/power.sh │ └─power.sh /etc/acpi/power.sh │ └─pm-powersave /usr/sbin/pm-powersave false │ └─zzzsleep /etc/pm/power.d/zzzsleep false │ └─sleep 600 One iteration loop in /var/log/pm-powersave.log looks like this: Running hook /usr/lib/pm-utils/power.d/95hdparm-apm false: /usr/lib/pm-utils/power.d/95hdparm-apm false: success. Running hook /usr/lib/pm-utils/power.d/anacron false: /usr/lib/pm-utils/power.d/anacron false: success. Running hook /usr/lib/pm-utils/power.d/disable_wol false: Setting Wake On Lan for enp2s0 to enable...Done. /usr/lib/pm-utils/power.d/disable_wol false: success. Running hook /usr/lib/pm-utils/power.d/intel-audio-powersave false: Setting power savings for snd_hda_intel to 0...Done. /usr/lib/pm-utils/power.d/intel-audio-powersave false: success. Running hook /usr/lib/pm-utils/power.d/laptop-mode false: Laptop mode disabled. /usr/lib/pm-utils/power.d/laptop-mode false: success. Running hook /usr/lib/pm-utils/power.d/pci_devices false: Setting Host Bridge 0000:00:00.0 to on Setting Audio device 0000:00:03.0 to on Setting Audio device 0000:00:1b.0 to on Setting Ethernet device 0000:02:00.0 to on Setting Wireless device 0000:03:00.0 to on /usr/lib/pm-utils/power.d/pci_devices false: success. Running hook /usr/lib/pm-utils/power.d/pcie_aspm false: sh: echo: I/O error /usr/lib/pm-utils/power.d/pcie_aspm false: success. Running hook /usr/lib/pm-utils/power.d/sata_alpm false: Setting SATA ALPM on host0 to max_performance...Done. Setting SATA ALPM on host1 to max_performance...Done. /usr/lib/pm-utils/power.d/sata_alpm false: success. Running hook /usr/lib/pm-utils/power.d/sched-powersave false: **sched policy powersave OFF /usr/lib/pm-utils/power.d/sched-powersave false: success. Running hook /usr/lib/pm-utils/power.d/usb_bluetooth false: /usr/lib/pm-utils/power.d/usb_bluetooth false: success. Running hook /usr/lib/pm-utils/power.d/wireless false: Turning powersave for wlp3s0 off...Error for wireless request "Set Power Management" (8B2C) : SET failed on device wlp3s0 ; Operation not supported. Failed. /usr/lib/pm-utils/power.d/wireless false: success. Running hook /usr/lib/pm-utils/power.d/xfs_buffer false: /usr/lib/pm-utils/power.d/xfs_buffer false: not applicable. Any sugestions for further debugging appreciated! live well, vagrant
Control: tags -1 +moreinfo unreproducible I'm trying to reproduce this on every x86 piece of hardware I have, without success. Could you say more especially about "in the last few days"? What did change? I assume you don't reboot daily, so the real reason is time shifted. Still, because of the freeze, changes don't happen often, so the packaged I'd suspect are systemd and the kernel, with a strong hunch about the former. If the bug is readily reproducible for you, would you care to downgrade either systemd or the kernel and check then? This may be the issue: systemd has a NIH implementation of pm stuff, which might be fighting with that of pm-utils. Generally, on systemd machines, keeping pm-utils is kind of pointless, while it is vital on any x86 box that gets suspended and uses other inits. As you filed this bug just days before the total freeze, there's rather little time to find out what might be wrong -- especially that no one else seems to have this problem. Meow!
It's a little hard to know, because there are no timestamps in the pm-powersave.log file, it just gradually grew without me noticing until it was multiple gigabytes... so I have no real idea how long it's been an issue. Correct. Will give some systematic downgrading a try... Ah, that would explain things a bit if two things are fighting over resume events somehow... Understood; will try to find out more... live well, vagrant
Hi, I am not sure how to register or log in on https://bugs.debian.org/ -- so here is my email with the text which you are welcome to publish on the website (or tell me how I can do this). Kind regard, Bruno !!! MESSAGE !!! Sorry, I'm not familiar with the policies here at bugs.debian.org and I'm also quite new to GNU-Linux -- so please be indulgent! Package: pm-utils Version: 1.4.1-17 Severity: critical On trying to install pm-utils on a pretty new system without many changes (firmware-9.1.0-amd64-DVD-1.iso with kernel 4.9.0-3) on an ASUS laptop, Synaptic gives the following message: "»critical Fehler von pm-utils (? 1.4.1-17) <Ausstehend> b1 - #863679 - /usr/sbin/pm-powersave: repeatedly runs until /var/log/pm-powersave.log fills up disk" As a novice, I rather would not like to downgrade systemd or the kernel -- as suggested -- since the system does not run troublefree yet (there are still a lot of hardware issues and I don't want to open another can of worms). You further write that "on systemd machines, keeping pm-utils is kind of pointless" -- does this mean that I can do without it or should I install an alternative? Suspend and hibernate do not work yet on the machine ... Thanks for your help and input! kalamazoo !!! END OF MESSAGE !!!
Control: severity -1 important To comment on a bug, you mail 863679@bugs.debian.org, like you just did. The tool you're using is warning you about high-severity bugs someone reported. However, this one seems to be spurious -- no one else has managed to reproduce it, and the original reporter hasn't responded either. Thus, I've just downgraded the report; I'll ping the reporter to see if he has any new information. About every user of Debian who runs a GUI system has pm-utils installed, and most also have systemd (which is somewhat controversial, but not let's go into that here) -- thus it's very likely the failure on the original reporter's machine was unique. Thus, I'd say you should be safe. Of course, if you happen to see this particular symptom (/var/log/pm-powersave.log growing without bounds) it'd be nice if you could tell us so. systemd can trigger suspend and hibernate by itself, and most GUIs know how to do this via systemd. pm-utils are useful for scripting, but it doesn't sound like you have this particular need. As for suspend and hibernate not working on your machine, this is a notorious pile of issues, with which I'm not in a position to really help you. Meow!
Hi! On 29 May 2017 you reported: I then tried reproducing this on a bunch of machines, in different configurations -- without success. pm-utils also has a quite big popcon, yet no one else mentioned this problem either. It's not good to have a Severity:critical bug left alone -- it spooks users who don't know what "unreproducible" means, not to mention anyone who looks at QA. Thus, I've just downgraded the severity -- but, could you tell if you had any luck reproducing it? Meow!
sure. It has never gone away for me on this system, so in that sense, I can reproduce it. It is so tremendously disruptive that I've just used the workaround of putting "sleep 600" in /etc/pm/power.d/zzzsleep, which makes the system useable; I haven't really had the energy to try downgrading systemd or the kernel... as the system otherwise works. Not sure where to go with this... live well, vagrant
Hi, TL;DR: This thing hit me, too, and I'd say it's not (directly) a bug of pm-utils and it should be closed here. Longer version: When it happened and my logs got filled up (I actually noted it because for a continuous stream of "Anacron 2.3 started on ..." lines in syslog), I service stop-ed acpid and ran acpid -dl instead. That showed me that what triggered the behaviour (for me) was a flood of acpid: received netlink event "battery PNP0C0A:01 00000080 00000001" messages coming in at about one per second or so. I've not checked, but I suspect it's something like battery-full messages. They are always identical, though, and I don't think the ACPI BIOS (or the EC) should be sending them, at least not at that rate. If it had any sense, I'd put the bug there. For the record: This is on a Thinkpad X240. Current resolution: I believe the root of the trouble is that I accidentally set charge limits like this: sudo tpacpi-bat -s ST 2 0 sudo tpacpi-bat -s SP 2 0 (tpacpi-bat is a perl hack that's not packaged AFAIK; see http://www.thinkwiki.org/wiki/Tpacpi-bat). This should have meant that the EC should charge that particular battery unconditionally to 100% but instead probably made the EC shout something like "Battery charged" or "Charging now" all the time (too lazy to decode the message now). I'm now setting the charge limits like this: sudo tpacpi-bat -s ST 2 0 sudo tpacpi-bat -s SP 2 1 and the flood of messages has stopped. Btw, I'm running sysvinit, and the behaviour observed certainly will affect systemd as well as pm-utils (though perhaps differently). Now, given that the code that generates the ACPI messages on the EC is rumored to be not necessarily always a model of great software engineering, one could argue that either acpid or pm-utils could introduce some rate-limiting functionality for repeated or flapping events. But that'd be a wishlist item, and I'm not even sure that'd be a good idea.
Dear submitter, as the package pm-utils has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/1058701 The version of this package that was in Debian prior to this removal can still be found using https://snapshot.debian.org/. Please note that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Thorsten Alteholz (the ftpmaster behind the curtain)