Project

General

Profile

Housekeeping #2899

better documentation regarding laptop power management

infinite_recursion - about 1 month ago - . Updated about 1 month ago.

Status:
open
Priority:
discussion
Assignee:
-
% Done:

0%


Description

Suppose I have a file open in kate editor named file.py and an iceweasel instance running. If I forget to check the battery prompt and it suspends the session or shuts down, then the whole system files associated with file.py, kate files and iceweasel get corrupted. While restart there's a fs manual cleaning prompt and it forces to clear these files.

One time, I had to clear the site I had worked on and rework code for almost a day.

Point : Parabola is like a high maintenance girl wrt shutting down correctly. One wrong thing you say and immediate penalty. If you do anything wrong in that respect, the files get corrupted and they need to be removed.

Request : Please make parabola more stable wrt this. All (shutdown, suspend, poweroff) scripts (including display manager) should have the old state of files saved, close running processes safely and then shutdown.

P.S. Very 1st time I did fsck, I literally wiped off my whole system. Was glad I had backup of my data.

History

#1

Updated by freemor about 1 month ago

Does this corruption happen when you suspen correctly or only when the battery zeros out due to not having a ACPI watcher set up?

You haven't mentioned if you are using systemd or openrc.
Do you have any power manager/batery monitor application installed? If not, Why not?
Have you read through: https://wiki.archlinux.org/index.php/Power_management

Your "point: ..." line is sexist, derogatory, and has no place in a bug report as it is not useful way of presenting information. Although I inderstand you frustration please refrain from such in the future.

That line and the frustration it show has me wondering if you'd be happier with a less hands on system than an Arch based rolling release.

I had similar issues on my x200. If i didn't watch it it would zero out the battery and shut off hard. A simple ACPI watcher with a proper shutdown when the battery reached 20% fixed that right up. That wasn't a bug. That's Arch's "You set up the system the way you want" philosophy. It was Zeroing out because I had failed to set thing up correctly.

#2

Updated by freemor about 1 month ago

  • Subject changed from [high-priority] fs problems when forced shutdown or suspend due to battery problems to File system corruption when forced shutdown or suspend due to battery problems
#3

Updated by oaken-source about 1 month ago

this is literally just how file systems work.

voting to close as not a bug.

#4

Updated by infinite_recursion about 1 month ago

Nope, it doesn't happen when I suspend correctly. I use openrc, I have power-management in plasma, not in lxqt.

It's a proper problem @oaken-source. Mistakes happen. I have absolutely no battery prompts in virtual terminal. Say if I'm using virtual terminal and I forget to plugin the charger, it shouldn't mess up things. 99% I do things right but that 1% shouldn't harm me. It's called stability. I have never experienced such problem in any other OS.

This should be the default system settings.

#5

Updated by infinite_recursion about 1 month ago

That's how fs work but OSes work this way, once they detect very low battery levels, they safely close all processes and prevent corruption of fs from human errors.

#6

Updated by freemor about 1 month ago

Ok, Zeroing out in a VT is exactly the issue I had on my X200.

look into acpid. It is easy to set up and will save your code/file system/etc after some simple set-up

https://wiki.archlinux.org/index.php/Acpid

looks like there isn't an acpid-openrc yet. So you'll have to take steps to make sure it is launched at start-up.

#7

Updated by freemor about 1 month ago

Forgot to mention above if you don't know that the ACPI battery messages for your system are yoo can run

acpi_listen

and monitor its output as you you the system. :nce identified just add an appropriate hanlder for when the battery goes < xx%

#8

Updated by freemor about 1 month ago

Perhaps this should be bumped over to a Documantation issue. Perhaps the installation guide should include info about making sure the user had proper power management set up. Especially WRT OpenRC.

#9

Updated by oaken-source about 1 month ago

sigh.

Operating Systems 101:

There are several layers in play in such a situation. There is the operating system, the file system, the application. In an emergency situation, such as a power failure, the system will be interrupted by the hardware, which will cause an exception in the kernel. the exception handler for the power failure is responsible to shut down the system safely, meaning without permanent damage to hardware before the lights go out.

User data is not a priority in that situation.

Second, the file system. File systems are optimized for performance and are caching data prior to disk writes. as such, any data written by the application may not be on the disk when lights go out. to cope with that design decision, there is journaling, where the file system will keep a transaction log that is flushed periodically and that can be looked at during recovery to make sure that the file system metadata, so file structures, directory entries, these kinds of things, are recovered correctly. Generally, modern file systems flush the cached data to disk every 5 - 60 seconds.

Again, user data is not covered by the recovery provided by journaling.

Third, the application. Many applications write temporary files to recover from crashes or unexpected reboots. Some applications don't, and invite these kinds of troubles.

In summary, if you allow your system to run into a total power failure, you have to deal with any data corruption yourself. there is no sane default behaviour that could be applied here to somehow "fix" this. Power failure interrupts give the system very little room to maneuver, and it is impossible to define a general point for a graceful shutdown that works in all situations.

#10

Updated by infinite_recursion about 1 month ago

Okay, you are correct. I configured my LXQt to hibernate when power goes below 10%. Thanks. Very useful information!

freemor There is acpid-openrc package. However acpi_listen doesn't work.
Can't open socket : No such file or directory

#11

Updated by bill-auger about 1 month ago

  • Priority changed from bug to discussion
  • Status changed from unconfirmed to open
  • Project changed from Packages to Documentation
  • Tracker changed from Bug to Housekeeping

FWIW, kate always keeps a backup file, since forever, to restore any un-saved changes, just because these things happen - i have rarely ever lost work with kate - the same thing could happen with any computer if the power is interrupted, or if the system locks up and you need to hard reset - the standard way to avoid it, is to use a power supply with a battery backup; but even that will not help with hard resets

i will change this to a documentation issue - i dont think we want to make a battery watchdog service mandatory - perhaps there could be a 'parabola-laptop' package?

#12

Updated by bill-auger about 1 month ago

  • Subject changed from File system corruption when forced shutdown or suspend due to battery problems to better documentation regarding laptop power management
#13

Updated by oaken-source about 1 month ago

a parabola-laptop metapackage containing some battery watchdog daemon would certainly be useful. I think I might even use that myself on my parabola laptop.

This would be highly dependent on the init system though, so we would need a dedicated systemd and openrc version.

Then there's the problem of sane default limits. I think this is problematic because, as batteries age, the estimated charge percentage less and less reflects the actual remaining running time. I have had very old systems suddenly shut off at over 30% remaining charge, because of voltage drops. So these levels would have to be configurable. Also, if you were to implement any warning system before forcing a graceful shutdown, these would even be highly dependent on the desktop environment the user has installed, because some of them handle notifications differently than others.

Building this from scratch in a way that it is useful for a wide portion of our target audience could be very tricky. It would be a lot easier if such a thing already existed that we could just use. We should keep our eyes open and do some research.

Oh -- and even a "graceful" shutdown is dependent on the desktop environment. Just running "shutdown -h now" will not really care about foreground applications trying to save currently open documents. It will just terminate processes and continue.

Also available in: Atom PDF