better documentation regarding laptop power management
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.
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.
Updated by infinite_recursion 4 months 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.
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
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.
Updated by oaken-source 4 months 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.
Updated by bill-auger 4 months 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?
Updated by oaken-source 4 months 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.