DR800 Shutdown mode - proof of concept

[Shaggy]

Before I start, standard warnings. I'm just messing around with this. I have no idea yet if there are any serious side effects (assume there are until we learn otherwise). Mostly this is just theoretical for now, so TRY AT YOUR OWN RISK

OK, on to the interesting part. Given some recent discussions about the DR800 only having a sleep mode and not a real "off" available to the user, I decided to play around on my device with some scripts.

I created myShutdown.desktop in the Personal Documents folder with this:

[Desktop Entry]
Name=myShutdown
Type=Application
Exec=/media/mmcblk0p1/Programs/myShutdownScript.sh

Then I created myShutdownScript.sh in the SD card's Programs folder with this:

#!/bin/sh
shutdown -h -P now >> /media/mmcblk0p1/Programs/myShutdownLog.txt 2>&1

When you click on the desktop item, after 5 seconds the screen goes blank. The next press on the power switch causes a complete bootup sequence.

So, I'm assuming that the device does not just go to sleep, but actually shuts down.

The questions still remaining:

1. Do running applications react badly to this? This should cause a SIGTERM to be sent to them and potentially a SIGKILL if they don't stop within 5 seconds (that interval can be adjusted), but is this going to have any serious side effects? IE will viewers not save correctly before stopping, etc. I'm assuming they will gracefully stop after a SIGTERM, but I don't know.
2. Is the device really going to a poweroff state, or is it just halting the kernel (and still drawing power somewhere)? The -P flag theoretically tells it to poweroff when it halts, but it depends on the version of linux and whether or not it honors that flag. I did notice that after it went blank, plugging in the power connector caused it to boot without pressing the switch. Not sure if that normally happens when the device is really off.
3. There is no indication to the user that anything is happening. You click on the icon, and then 5 seconds later the screen goes blank. That's it. It would be nice to figure out a way to get a popup "Device is shutting down" displayed. That's further down the road though.
4. Anything else I'm not thinking of. Does iRex want to step in and say this is a really bad idea, or should I keep going with it?

In theory (once it's completed and fully tested), what this will let people do is choose to power off the device instead of put it into sleep mode. The benefits are that if you know it's not going to be used for awhile, it will (theoretically, but not proven yet) preserve battery. The drawback is that when you do want to use it again you have to do a full boot, which takes 40-50 seconds.

[pauli]

you can use the rxvt terminal program from GregorRichards:
see this post

to give this command manually and see what the device does. I don't think yours is a harmful script. It's just the regular shutdown command from Linux.

By the way... don't use the reboot attributes (-f -F), these seem to freeze my DR800

[Gertjan]

Originally Posted by Shaggy

1. Do running applications react badly to this? This should cause a SIGTERM to be sent to them and potentially a SIGKILL if they don't stop within 5 seconds (that interval can be adjusted), but is this going to have any serious side effects? IE will viewers not save correctly before stopping, etc. I'm assuming they will gracefully stop after a SIGTERM, but I don't know.
2. Is the device really going to a poweroff state, or is it just halting the kernel (and still drawing power somewhere)? The -P flag theoretically tells it to poweroff when it halts, but it depends on the version of linux and whether or not it honors that flag. I did notice that after it went blank, plugging in the power connector caused it to boot without pressing the switch. Not sure if that normally happens when the device is really off.
3. There is no indication to the user that anything is happening. You click on the icon, and then 5 seconds later the screen goes blank. That's it. It would be nice to figure out a way to get a popup "Device is shutting down" displayed. That's further down the road though.
4. Anything else I'm not thinking of. Does iRex want to step in and say this is a really bad idea, or should I keep going with it?

Interesting idea. Though shutting down like this may work, the system is not designed to this way. When you look into SYSD (system.c) you'll see that DR1000 does various things before turning off. Most importantly, it unmounts the volume (/media/mmcblk0p1). This triggers running applications to commit changes and close their files. Doing this before calling shutdown will probably make it safer.

A cleaner approach would be to follow the path of SYSD's API call "sysShutdown". For DR1000 this triggers the shutdown, on DR800 it goes to standby mode. With a bit of juggling, a call could be added to do the complete shutdown for DR800.

[Iñigo]

You could also use the lua-based Toolbox from https://www.mobileread.com/forums/showthread.php?t=79273 (2nd. message).

By the moment, it's the same base code as Iliad, but it does work on DR.

[Shaggy]

Originally Posted by Gertjan

When you look into SYSD (system.c) you'll see that DR1000 does various things before turning off. Most importantly, it unmounts the volume (/media/mmcblk0p1). This triggers running applications to commit changes and close their files. Doing this before calling shutdown will probably make it safer.

Yeah, that's what I suspected. I figured there were probably additional things done other than init stopping running processes before the device is safely shutdown. I would assume that the current script I have is killing the applications first, and then unmounting the volume.

I'll look into SYSD some more. This was just such a tempting shortcut though, that I couldn't resist trying it to see what would happen. Oh well.

[GregorRichards]

The standard shutdown process will synchronize and unmount filesystems. After SIGTERM'ing apps of course. I would certainly hope that any builtin apps that depend on their runtime state would catch SIGTERM properly. With a quick look of the sources I happened to already have downloaded, erbrowser does in fact catch SIGTERM and handle it. I don't have the content browser or document viewer source.

[Shaggy]

Originally Posted by Gertjan

A cleaner approach would be to follow the path of SYSD's API call "sysShutdown". For DR1000 this triggers the shutdown, on DR800 it goes to standby mode. With a bit of juggling, a call could be added to do the complete shutdown for DR800.

I know you probably don't have time to really look into this too far, but does it sound like I'm on the right track? I can figure out more of the details if this sounds like the right approach. BTW, I only looked at this for about 30 minutes, so if I'm completely clueless and need to spend more time looking at it just let me know, no need to try to explain it further.

I see there's a sysclient that can be called with sysShutdown. This in turn leads to sys_standby(). That's where we have the branch between the DR800 and DR1000. The DR800 goes to prepare_standby() and the DR1000 goes to do_poweroff().

If we add a new argument to sysclient like userShutdown, and make a clone of sys_standby(), something like user_standby() that doesn't do the branch based on the device, but just goes to do_poweroff()... I think that's what we're looking for.

The only thing I've seen in do_poweroff() that is a little bit of a concern is where it unlocks/enables the DR1000 sensors. I haven't look into it deep enough to know if calling that will cause any issues on the DR800, or if we should modify on_poweroff_continue() to check for DR800 vs DR1000.

Assuming all that works, we can then create a .desktop file that calls "sysclient userShutdown".

[Shaggy]

Originally Posted by GregorRichards

The standard shutdown process will synchronize and unmount filesystems. After SIGTERM'ing apps of course. I would certainly hope that any builtin apps that depend on their runtime state would catch SIGTERM properly. With a quick look of the sources I happened to already have downloaded, erbrowser does in fact catch SIGTERM and handle it. I don't have the content browser or document viewer source.

Doing it through sysd, it tells the apps that it's going to unmount the filesystem (which I assume causes them to gracefully save), and also tells the configuration tool to export it's settings. Then it waits for them to finish before it really does the unmount. After that it continues with the shutdown sequence.

The problems with doing it outside of sysd are:
1) Do the apps handle a SIGTERM in the same manner as being told by sysd that it is preparing an unmount.
2) Will they finish quick enough, or will the system shutdown send them a SIGKILL while they're still trying to gracefully exit. The system shutdown only waits X seconds before it kills them, it can't sync up with the apps like sysd does.

As Gertjan says, doing it through sysd is a lot cleaner.

[Gertjan]

Originally Posted by Shaggy

I see there's a sysclient that can be called with sysShutdown. This in turn leads to sys_standby(). That's where we have the branch between the DR800 and DR1000. The DR800 goes to prepare_standby() and the DR1000 goes to do_poweroff().

If we add a new argument to sysclient like userShutdown, and make a clone of sys_standby(), something like user_standby() that doesn't do the branch based on the device, but just goes to do_poweroff()... I think that's what we're looking for.

The only thing I've seen in do_poweroff() that is a little bit of a concern is where it unlocks/enables the DR1000 sensors. I haven't look into it deep enough to know if calling that will cause any issues on the DR800, or if we should modify on_poweroff_continue() to check for DR800 vs DR1000.

Assuming all that works, we can then create a .desktop file that calls "sysclient userShutdown".

Excellent breakdown, that is exactly what I meant. Unlocking the sensors does not apply to DR800 but it won't hurt calling the function. The standby micro of DR800 just does not support the command.

[Shaggy]

Originally Posted by Gertjan

Excellent breakdown, that is exactly what I meant. Unlocking the sensors does not apply to DR800 but it won't hurt calling the function. The standby micro of DR800 just does not support the command.

Thanks for the confirmation.

Now I just need to setup a development environment.

[GregorRichards]

Presumably it's preferable to avoid modifying sysd ... there is an IPC command to unmount the filesystem, I'm sure if you were careful to use daemon(3) first you could survive it (the shutdown app would have to be in C to do this of course). Without having the time right now to look through sysd, does it send all the same cleanup signals when it's asked explicitly to unmount the card, or only when it's shutting down?

[GregorRichards]

Here's a super-quick gross program that replicates sysd's shutdown procedure without requiring changes to sysd. It "seems" to work, in that it appears to shut down my DR800SG and doesn't leave it in some horrible unbootable state. This was just a quick hack

[Shaggy]

Originally Posted by GregorRichards

Presumably it's preferable to avoid modifying sysd ... there is an IPC command to unmount the filesystem, I'm sure if you were careful to use daemon(3) first you could survive it (the shutdown app would have to be in C to do this of course). Without having the time right now to look through sysd, does it send all the same cleanup signals when it's asked explicitly to unmount the card, or only when it's shutting down?

The changes required to sysd are pretty simple. I wouldn't modify any of the existing functions, but clone one that will only be called by the new userShutdown. That way any existing code that is using sysd shouldn't be effected.

[Shaggy]

Originally Posted by Shaggy

The changes required to sysd are pretty simple. I wouldn't modify any of the existing functions, but clone one that will only be called by the new userShutdown. That way any existing code that is using sysd shouldn't be effected.

The other reason I'm leaning this way is that, in my mind, calling it from a link on the SD card is only a first step. The goal I have in mind is to have the power switch configurable between the long press either doing a restart or a shutdown.

[Shaggy]

Originally Posted by GregorRichards

It "seems" to work, in that it appears to shut down my DR800SG and doesn't leave it in some horrible unbootable state.

Using the original simple script I did, it was 92% when I did the shutdown, and 18 hours later when I booted it back up it was still at 92%. So that's good news. Your version is a lot safer than the script I had, but the results should be similar.

I'm going to keep going down the path of putting it into sysd though, mostly just for the fun of doing it.