v252 backports #251
v252 backports #251
Conversation
(cherry picked from commit 3d23df0)
(cherry picked from commit d812e10)
(cherry picked from commit 2ed56af)
Before v252, HibernateDelaySec= specifies the maximum timespan that the system in suspend state, and the system hibernate after the timespan. However, after 96d662f, the setting is repurposed as the default interval to measure battery charge level and estimate the battery discharging late. And if the system has enough battery capacity, then the system will stay in suspend state and not hibernate even if the time passed. See issue #25269. To keep the backward compatibility, let's introduce another setting SuspendEstimationSec= for controlling the interval to measure battery charge level, and make HibernateDelaySec= work as of v251. This also drops implementation details from the man page. Fixes #25269. (cherry picked from commit 4f58b65)
(cherry picked from commit 3c3f460)
- use device_get_sysattr_int(), - drop redundant log message. (cherry picked from commit 3d9ca76)
Also, rename get_battery_identifier() to siphash24_compress_device_sysattr(). This also makes any errors in sd_id128_get_machine() or id128_get_product() ignored. For the machine ID, the failure should not be significant unless the file stored in the discharge level is reused by another system, which is quite unusual. For the product ID, if the firmware provides useless ID (all zero or all 0xFF), then loading/storing the discharge rate becomes completely broken, that should be avoided. Note, now sysattrs are used instead of properties in uevent files, but both provide the same information, hence no functionality should be changed. (cherry picked from commit a7795a4)
(cherry picked from commit 3332cfe)
The enumerator is now mostly consistent with on_ac_power() in udev-util.c. (cherry picked from commit fe8e0f8)
|
This is a new option, and we don't add new options to stable releases usually? |
|
The merge request from main branch (systemd/systemd#25374) has the |
|
I know this his been debated at length, in systemd/systemd#25269. But most people seem to believe it to be a breaking change to an existing option, which would warrant a backport IMO. The new option being introduced is part of the fix. i.e. the original functionality is restored, but the new (previously breaking) behaviour is not removed, but instead being made available in a new option. As the new option is part of the "fix", wouldn't a backport be appropriate regardless? |
|
Pfff, this is tough. But I think we're better off merging this. For people upgrading from v251, this is clear: we maintain compatibility. People who were already on v252 and adjusted to the new behaviour would see a disruption. But I think that the amount of such people will be small. There were many people who commented in #25269, so the change in v252 was clearly causing problems. |
No description provided.