Eek – sorry! Guess I assumed too much. I’ll try again
I presume you have a copy of the script already in ~/config/settings/boot/launch. In the ‘boot’ folder itself, there should be a ‘UserBootScript’, which includes the lines from my last post. I’d think that would be present in all the nightlies; if not that’s another nasty. If it isn’t there, just create it with those lines. (Doesn’t seem to have to be executable.)
If things still don’t work, I suggest backing up a bit. Maybe move or copy the script to ‘home’ or somewhere where it’s convenient to work on it. I actually built up the script from bare bones, so I could be sure each step was working, starting with:
#! /bin/sh
notify "Test notify"
And ran that from a Terminal, to see that the notify message appears (and no error message in the Terminal). You should also be able to just double-click on the script to see it execute.
Then I expanded it to something like:
#! /bin/sh
while true; do
sleep 1m
notify "Test notify"`
done
with a 1 minute sleep time so I could check I had the loop correct.
Finally I changed the sleep argument to “15m”, added in the “sync” command line, edited the notify, and manually made that run for one cycle. Finally knowing it worked, I moved it to the launch folder and rebooted.
That was just for (my) convenience. The default is for the notification to appear for just 10 secs, and I figured I’d probably not be paying enough attention to catch that. So I boosted it up to 30 secs with that option.
It indeed happens automatically, but not very aggressively. Ie. when copying large amounts of data, it’s possible that the last minute or so is missing if Haiku crashes.
However, if several hours are missing, then I’d rather suspect a drive internal cache to be the cause of this failure: even if Haiku says “sync”, the drive might not have written back the data, but only to its internal cache (depending on how it’s implemented). There is usually a capacitor to avoid losing the data in case of a power loss, but capacitors don’t live forever.
That’s weird, yeah with journaling, isn’t it supposed to save anything that you do? I remember pulling the plug on BeOS R5 a few times and it def came back up exactly where I pulled it.
“Depending on the actual implementation, a journaling file system may only keep track of stored metadata, resulting in improved performance at the expense of increased possibility for data corruption.”
My puzzlement is in why it happens at all. I mean the voltage doesn’t fall off a cliff — the hardware just decides that it’s too low to continue safely, and shuts things off. Why can’t it just send a signal to the OS to initiate a normal shutdown (which of course has never lost me any data)?
And maybe I’ve just never been alert enough to see it but there doesn’t seem to be any alert from the battery monitor when power is low. In the Battery Info details there’s a “Design Capacity Low Warning” value, so I guess it detects it.
[And why has the display formatting suddenly gone crazy on this site? This input panel is full width, and I couldn’t scroll to the’Reply’ button until I adjusted the separator to give me the full window…
EDIT: definitely not right. (I’m using Qupzilla – the only one that works for me.) I logged out after hitting Reply, and came back in. It still had my in-progress edit! Had to cancel it – but my post still shows. Hmm – there was a crash yesterday, wasn’t there? And now I have to make the window bigger than the screen to get to the ‘Save’ button!]
There is a BNotification when the battery gets low, and the icon in deskbar becomes yellow, then red. This only works if PowerStatus is installed in DeskBar.
The hardware can’t really “send a signal”, for this, it’s up to the OS to monitor the battery state and shutdown itself when it decides the battery is getting low. Which would be annoying in the cases where we misread the battery state and thinks it is almost empty, when it’s not
As for the forum, we had an update to comply with new european regulations. Maybe the new version has some new rendering problems?
That seems like hubris to me, Haiku is very thinly tested whereas drive firmware will have a tremendous number of users banging on it. Probably more people own the specific model of drive in question than have ever run Haiku in its entire history.
As I understand it, Haiku relies on a “page writer” to periodically write back modified pages from file caches. This mechanism seems especially fragile against frequently written pages because it doesn’t end up tracking how long it has been since anything was written, but only how long it has been between the most recent change and now. My impression (not tested) is that a page which is written to once per second to an otherwise quiescent machine with the intent that either it results in writes once per second (so you never lose more than a second of work) or at worst with a cadence determined by the operating system, in Haiku instead is simply never written until either the program exits, or RAM gets tighter.
Why don’t you just read the source to prove you wrong? The page writer mechanism in Haiku works pretty similar to any other operating system out there. Of course, there might be a bug in there you don’t find in other systems. But losing hours of work is simply impossible; it either must be caused by a bug, or by a hardware failure. As you correctly mention Haiku’s alpha status, you might know that it also crashes more often than other operating systems. A power failure is very rare, on the other hand. From the point of data integrity, though, the two are pretty much the same thing. I’ll let you do the math.
I reported a loss of several minutes on the developer mailing list (see https://www.freelists.org/post/haiku-development/Failing-unit-tests,2), though that was 2 years ago. Perhaps that has been fixed in the meantime, but I have had enough file system corruption on Haiku to not store anything important on it.
Hah just happened again to me, fortunately didn’t lose any work.
I think in such situations, a subtle color change in the deskbar is not enough (I didn’t see any notification), and a prominent system dialog should pop up so it cannot be missed (at least when things get serious, e.g. at 10% battery).
This is common in other OS’s and really warranted since a sudden power off has a serious effect.
Is this something that could be done for beta 3, if we agree?
Yeah – it’s been a somewhat regular unfortunate for me!
The problem is I almost invariably run from external power, but when something goes wrong I notice nothing until sudently my screen goes off! Once or twice the connector has slipped just far enough out of its socket that there’s no power, but not enough to be obvious. Other times I’ve simply forgotten to turn on the power strip! Like you, I’ve been fortunate not to lose anything (since that first time…!).
This functionality could easily be implemented in the power_daemon I believe. The daemon could watch the battery percentage through the acpi_battery driver (api here: https://github.com/haiku/haiku/blob/master/headers/private/device/power_managment.h) , and easily emit a BNotification when the percentage falls below a certain threshold (I’d say about 10% remaining, or should be configurable) and a emit a warning sound using the system_beep() function (which users could choose to have an associated sound or not). Maybe around 2-3%, the power_daemon could start a countdown in a BNotification before attempting to shutdown the computer automatically to prevent damage.
On my MacBook Pro, I dont have battery status support, but when power is < 5%, I immediately feel slow down in responsiveness and disk I/O, indicating that system is in low power state and CPU runs at fraction of speed. That’s my shutdown clue. With Apple firmware, thats 5% of battery power.
Its not perfect, but it works 100%, and with Haiku you feel the speed drop. With other systems on this laptop, I got caught out.
As far as I know, battery-low cetection is already implemented. I think it pops up an alert. The problem is, I never actually see it! As I leave my machine on while I do other things, as likely as not I’m not even looking at the screen when the alert appears!
What I think it needs is some kind of non-standard alert that is persistent until dismissed. Whether a beep would help me I’m not sure. Unless the computer is connected to my audio system I don’t hear much.
Which I can now attest to, having actually seen it for once!
I turned everything off earlier this evening (trying to track down some bad TV reception) and forgot to turn the power strip on again. The alert came up at about 18% power. I wonder if this isn’t a bit high – my Android PDA alerts (with a red bar on the battery) at 12%, I think. The Android reminder is persistent though, which helps a lot. (The whole screen border goes red at 5%.)
Two levels of alerts might be useful. An early warning at maybe 15% or so, and an urgent (and persistent!) one at say 5%.
There are already two levels of warning. Yes, both are currently non-persistent notifications. Also, the second one may be at a too low level since the system may power off before its reached, depending on your battery calibration.
Converting the notifications to alerts sounds like a good idea.
So I boosted it up to 30 secs with that option.