Systemd now provides {{ic|systemd-rkfill.service}}. If you use {{ic|rfkill block}} to disable bluetooth, {{ic|systemd-rfkill.service}} will remember this and restore this state on next boot -- [[User:robtaylor|robtaylor]] ([[User talk:robtaylor|talk]]) Wed 18 May 16:10:05 BST 2016

Systemd now provides {{ic|systemd-rkfill.service}}. If you use {{ic|rfkill block}} to disable bluetooth, {{ic|systemd-rfkill.service}} will remember this and restore this state on next boot -- [[User:robtaylor|robtaylor]] ([[User talk:robtaylor|talk]]) Wed 18 May 16:10:05 BST 2016

+

+

== A "sensible value" for the laptop mode ==

+

+

The vast amount of specific information carried in this part, I find it a bit surprising. It seems "A sensible value for the laptop mode 'knob' is 5 seconds." could be heard in the mouth of a politician kicking the ball into touch.

+

+

From Documentation/laptops/laptop-mode.txt:

+

+

> The value of the laptop_mode knob determines the time between the occurrence of disk I/O

+

and when the flush is triggered. A sensible value for the knob is 5 seconds. Setting the knob

+

to 0 disables laptop mode.

+

+

So "5 (seconds)" is related to the virtual memory subsystem (in direct relation to ''vm.dirty_writeback_centisecs''). Then "0" turns laptop mode off, aha. It'd be cool to know *what* is laptop_mode is in the first place: Is it the whole vm configuration settings that are described in the docs? I believe not, as e.g. the conf files are not to be seen in present Arch (nor in other distros I know of).

+

+

A few things changed a bit since the Documentation/laptops/laptop-mode.txt was last edited, in 2004. I've searched extensively which part of it might still be up to date, without success so far. ''TLP'' has many if not most of the settings the doc explains. And so looks as an evolution of ''laptop_mode''. Would a guru or someone with knowledge about that be kind enough to specify the effect of ''vm.laptop_mode''? [[User:Kozaki|kozaki]] ([[User talk:Kozaki|talk]]) 23:33, 1 September 2016 (UTC)

+

+

:The effect of the {{ic|vm.laptop_mode}} is described in the kernel docs in "The Details" section. The scripts that the docs talk about are probably [[Laptop Mode Tools]] nowadays. They are needed only to switch settings based on the current power source (and as a "bonus" they integrate most of the things in the [[Power_management#Power_saving]] section), but I bet the kernel settings are mostly the same as in 2004. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:41, 2 September 2016 (UTC)

+

+

:: I now see that, thank you Lahwaacz. Now as we may increase flush time to disk (to, say, ten minutes) via {{ic|vm.dirty_writeback_centisecs}}, delaying the flush up to five seconds via the {{ic|vm.laptop_mode}} knob doesn't make much sense regarding the ''disk'' power-savings... But it may help the ''cpu'' staying idle longer. Hence, whether set via [[laptop-mode-tools]], [[tlp]] or proper self-made [[udev]] rules. I.e. {{ic|vm.laptop_mode}} and {{ic|vm.dirty_*}} together help delaying and grouping system's activity ''as a whole'', allowing for longer power-saving efficient idle times. Please correct me if I'm wrong. [[User:Kozaki|kozaki]] ([[User talk:Kozaki|talk]]) 19:37, 4 September 2016 (UTC)

+

+

::: True, but the delay via {{ic|vm.laptop_mode}} makes sense also for other reasons. Let's say {{ic|vm.dirty_writeback_centisecs}} is set to something like 10 minutes and the disk is spun down due to inactivity and stays like that for e.g. 8 minutes, when it spins up due to user activity. Flushing all the cummulated dirty pages to the disk immediately might delay the request which caused the disk to spin up, so it's better to wait couple of seconds until there is chance that small high-priority requests have been serviced. Also, it might take couple of seconds to spin up the disk. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:14, 4 September 2016 (UTC)

+

+

== xss-lock ==

+

+

First of all I'm wondering why we are linking {{AUR|xss-lock-git}} instead of {{AUR|xss-lock}}. Secondly I wonder why we recommend the {{ic|-n}} flag; don't we want it to fork if we are closing the lid so presumably putting the computer into suspend/hibernate?

:xss-lock-git is used because the release version has some bugs such as 100% CPU with certain window managers (for details, see upstream). The -n option is as used in the man page; a separate option is provided if you want to use the i3lock forking mode. The computer should however suspend regardless. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:57, 25 April 2017 (UTC)

+

+

== suspend to hibernate require fix ==

+

+

Rather than overriding the <code>suspend.target</code>, I think we should just add <code>RequiredBy=suspend.target</code> in the <code>[Install]</code> section of the service. It works for me, and I think this is cleaner. Can anyone else confirm that this works?

At least a few other wiki pages point to this rule for how an example of how to turn off power management, because power mananagement breaks some current cards using the iwlwifi driver. Unfortunately the given udev rule does not work due to persistent device names. There is a note here about persistent device names, but it is really confusing. It stresses the importance of the number in the file name, but then states that it actually wont work anyway and to use the persistent name instead of the wildcard?? However even that won't work because the udev rule above has ACTION="add". At least in my case, that ACTION clause causes the rule to only trigger for the original device name (wlan0), and not the persistent name (wlp5s0). So if I use wlan0 everywhere, it triggers but has no effect. If I use wlp5s0 everywhere it never triggers. One solution is to remove the ACTION="add" clause and use the persistent name everywhere. Another solution is to continue using a wildcard in KERNEL, such as KERNEL="wl*", and then use the persistent name instead of %k in the RUN command. I chose the second solution and my full udev rule was this:

Note that I also tried using 99 instead of 70 for the filename with the original udev rule, but that did not work. [[User:Lllars|Lllars]] ([[User talk:Lllars|talk]]) 23:10, 5 August 2017 (UTC)

+

+

:What the note tries to say is that you can't "use wlan0" everywhere as you did. In any case, the command is run ''after'' the interface gets a persistent name, so you need to run {{ic|iw dev wlp5s0 set power_save off}} (or, as the note says, {{ic|iw dev $name set power_save off}} to make it generic). As for the matching, {{ic|KERNEL}} is the "old name" and {{ic|NAME}} is the "new name", which is assigned in {{ic|80-net-setup-link.rules}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:57, 6 August 2017 (UTC)

+

+

::Ok. In a way it's nice to have so much detail about how udev manages the initial and persistent names. But the way this is currently written is still very confusing. Thanks to $name, it sounds like we could just change the given udev rule to:

::with a note about how some people will need to use "eth*" instead of "wl*", or off instead of on. Then the whole section about persistent names is unnecessary extra info, and could either be ommitted or clarified and kept as an informational side note.[[User:Lllars|Lllars]] ([[User talk:Lllars|talk]]) 02:22, 7 August 2017 (UTC)

+

+

:::Note that there are people who [[Network_configuration#Revert_to_traditional_device_names|don't use the persistent names]] at all. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:17, 7 August 2017 (UTC)

+

+

== RTC drift bug in suspend-to-hibernate script ==

+

+

For some time now I have been trying to figure out an issue with my laptop that seems to happen when I use the suspend-to-hibernate script: the laptop would immediately wake up after hibernating.

+

+

I took some more time to investigate today, and I think (unfortunately not confirmed 100% yet - the issue was fairly rare) that there is a race in the script that causes the RTC to immediately wake up the computer after it gets suspended. Specifically, the RTC is reset after the hibernate has started, so it is possible that the reset does not happen before the computer hibernates.

+

+

Further, the source for the current time is the command {{ic|date}}, whereas the RTC's idea of time might be a little different. I confirmed this by outputting {{ic|/sys/class/rtc/rtc0/since_epoch}} at the same time as {{ic|date +%s}} and saw delays as large as 4 seconds, but I suppose it could also get larger.

+

+

Combining the RTC drift and the fact that the RTC wakealarm reset happens after the hibernate has started, it is possible for the computer to immediately wake up from hibernation right after it hibernates if that happens quickly enough. This was especially noticeable in my case as it would then wait for me to enter my encryption password and drain my battery, overheating the CPU and the insides of my backpack.

+

+

I have two proposed changes to the script to make it better, but I suppose either one would fix the issue:

+

+

# Use {{ic|/sys/class/rtc/rtc0/since_epoch}} as a base for the wakeup time, rather than {{ic|date}};

+

# Reset the RTC wakealarm before hibernating (right after reading it would be ideal).

+

+

+

I will keep investigating to see if I don't get the issue anymore (as I said, it was fairly rare and thus hard to confirm that it has definitely stopped happening), but if I don't see it in the next week, I'll submit an edit to the wiki.

Delayed hibernation service

I have found that the service file given in this section does not work. My laptop hibernates immediately after resuming from suspend. I have also found that the older version of this service found in the forum post does indeed work perfectly. Does anyone know why this is?
Aouellette (talk) 16:16, 30 May 2015 (UTC)

Resume file does not work after resuming from hibernation

The systemd unit User resume actions presented on this page only worked for me after resuming from sleep, not from hibernate.
After adding hibernate.target to the After and WantedBy lines it works both ways.
However this is the first time I've done anything with such service files so I ain't sure if this is the optimal way.
Can anyone confirm?

Actually, the suspend@.service in Power_management#Suspend.2Fresume_service_files binds to sleep.target, but resume@.service binds to suspend.target. They are not synonyms, systemd triggers suspend.target and sleep.target when the system is suspended to RAM, and hibernate.target and sleep.target when it is suspended to disk. This way you can bind your service to either one or both suspend methods using just a single target. -- Lahwaacz (talk) 19:17, 12 October 2015 (UTC)

Bluetooth rfkill

Systemd now provides systemd-rkfill.service. If you use rfkill block to disable bluetooth, systemd-rfkill.service will remember this and restore this state on next boot -- robtaylor (talk) Wed 18 May 16:10:05 BST 2016

A "sensible value" for the laptop mode

The vast amount of specific information carried in this part, I find it a bit surprising. It seems "A sensible value for the laptop mode 'knob' is 5 seconds." could be heard in the mouth of a politician kicking the ball into touch.

From Documentation/laptops/laptop-mode.txt:

> The value of the laptop_mode knob determines the time between the occurrence of disk I/O
and when the flush is triggered. A sensible value for the knob is 5 seconds. Setting the knob
to 0 disables laptop mode.

So "5 (seconds)" is related to the virtual memory subsystem (in direct relation to vm.dirty_writeback_centisecs). Then "0" turns laptop mode off, aha. It'd be cool to know *what* is laptop_mode is in the first place: Is it the whole vm configuration settings that are described in the docs? I believe not, as e.g. the conf files are not to be seen in present Arch (nor in other distros I know of).

A few things changed a bit since the Documentation/laptops/laptop-mode.txt was last edited, in 2004. I've searched extensively which part of it might still be up to date, without success so far. TLP has many if not most of the settings the doc explains. And so looks as an evolution of laptop_mode. Would a guru or someone with knowledge about that be kind enough to specify the effect of vm.laptop_mode? kozaki (talk) 23:33, 1 September 2016 (UTC)

The effect of the vm.laptop_mode is described in the kernel docs in "The Details" section. The scripts that the docs talk about are probably Laptop Mode Tools nowadays. They are needed only to switch settings based on the current power source (and as a "bonus" they integrate most of the things in the Power_management#Power_saving section), but I bet the kernel settings are mostly the same as in 2004. -- Lahwaacz (talk) 08:41, 2 September 2016 (UTC)

I now see that, thank you Lahwaacz. Now as we may increase flush time to disk (to, say, ten minutes) via vm.dirty_writeback_centisecs, delaying the flush up to five seconds via the vm.laptop_mode knob doesn't make much sense regarding the disk power-savings... But it may help the cpu staying idle longer. Hence, whether set via laptop-mode-tools, tlp or proper self-made udev rules. I.e. vm.laptop_mode and vm.dirty_* together help delaying and grouping system's activity as a whole, allowing for longer power-saving efficient idle times. Please correct me if I'm wrong. kozaki (talk) 19:37, 4 September 2016 (UTC)

True, but the delay via vm.laptop_mode makes sense also for other reasons. Let's say vm.dirty_writeback_centisecs is set to something like 10 minutes and the disk is spun down due to inactivity and stays like that for e.g. 8 minutes, when it spins up due to user activity. Flushing all the cummulated dirty pages to the disk immediately might delay the request which caused the disk to spin up, so it's better to wait couple of seconds until there is chance that small high-priority requests have been serviced. Also, it might take couple of seconds to spin up the disk. -- Lahwaacz (talk) 20:14, 4 September 2016 (UTC)

xss-lock

First of all I'm wondering why we are linking xss-lock-gitAUR instead of xss-lockAUR. Secondly I wonder why we recommend the -n flag; don't we want it to fork if we are closing the lid so presumably putting the computer into suspend/hibernate?

xss-lock-git is used because the release version has some bugs such as 100% CPU with certain window managers (for details, see upstream). The -n option is as used in the man page; a separate option is provided if you want to use the i3lock forking mode. The computer should however suspend regardless. -- Alad (talk) 21:57, 25 April 2017 (UTC)

suspend to hibernate require fix

Rather than overriding the suspend.target, I think we should just add RequiredBy=suspend.target in the [Install] section of the service. It works for me, and I think this is cleaner. Can anyone else confirm that this works?
--Svvac (talk) 14:16, 28 May 2017 (UTC)

network interfaces: udev rule does not work

At least a few other wiki pages point to this rule for how an example of how to turn off power management, because power mananagement breaks some current cards using the iwlwifi driver. Unfortunately the given udev rule does not work due to persistent device names. There is a note here about persistent device names, but it is really confusing. It stresses the importance of the number in the file name, but then states that it actually wont work anyway and to use the persistent name instead of the wildcard?? However even that won't work because the udev rule above has ACTION="add". At least in my case, that ACTION clause causes the rule to only trigger for the original device name (wlan0), and not the persistent name (wlp5s0). So if I use wlan0 everywhere, it triggers but has no effect. If I use wlp5s0 everywhere it never triggers. One solution is to remove the ACTION="add" clause and use the persistent name everywhere. Another solution is to continue using a wildcard in KERNEL, such as KERNEL="wl*", and then use the persistent name instead of %k in the RUN command. I chose the second solution and my full udev rule was this:

Note that I also tried using 99 instead of 70 for the filename with the original udev rule, but that did not work. Lllars (talk) 23:10, 5 August 2017 (UTC)

What the note tries to say is that you can't "use wlan0" everywhere as you did. In any case, the command is run after the interface gets a persistent name, so you need to run iw dev wlp5s0 set power_save off (or, as the note says, iw dev $name set power_save off to make it generic). As for the matching, KERNEL is the "old name" and NAME is the "new name", which is assigned in 80-net-setup-link.rules. -- Lahwaacz (talk) 14:57, 6 August 2017 (UTC)

Ok. In a way it's nice to have so much detail about how udev manages the initial and persistent names. But the way this is currently written is still very confusing. Thanks to $name, it sounds like we could just change the given udev rule to:

with a note about how some people will need to use "eth*" instead of "wl*", or off instead of on. Then the whole section about persistent names is unnecessary extra info, and could either be ommitted or clarified and kept as an informational side note.Lllars (talk) 02:22, 7 August 2017 (UTC)

RTC drift bug in suspend-to-hibernate script

For some time now I have been trying to figure out an issue with my laptop that seems to happen when I use the suspend-to-hibernate script: the laptop would immediately wake up after hibernating.

I took some more time to investigate today, and I think (unfortunately not confirmed 100% yet - the issue was fairly rare) that there is a race in the script that causes the RTC to immediately wake up the computer after it gets suspended. Specifically, the RTC is reset after the hibernate has started, so it is possible that the reset does not happen before the computer hibernates.

Further, the source for the current time is the command date, whereas the RTC's idea of time might be a little different. I confirmed this by outputting /sys/class/rtc/rtc0/since_epoch at the same time as date +%s and saw delays as large as 4 seconds, but I suppose it could also get larger.

Combining the RTC drift and the fact that the RTC wakealarm reset happens after the hibernate has started, it is possible for the computer to immediately wake up from hibernation right after it hibernates if that happens quickly enough. This was especially noticeable in my case as it would then wait for me to enter my encryption password and drain my battery, overheating the CPU and the insides of my backpack.

I have two proposed changes to the script to make it better, but I suppose either one would fix the issue:

Use /sys/class/rtc/rtc0/since_epoch as a base for the wakeup time, rather than date;

Reset the RTC wakealarm before hibernating (right after reading it would be ideal).

I will keep investigating to see if I don't get the issue anymore (as I said, it was fairly rare and thus hard to confirm that it has definitely stopped happening), but if I don't see it in the next week, I'll submit an edit to the wiki.