8000 Make reboot_on_exit=false work? · Issue #2 · NiLuJe/kfmon · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Make reboot_on_exit=false work? #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
baskerville opened this issue Mar 15, 2017 · 30 comments
Closed

Make reboot_on_exit=false work? #2

baskerville opened this issue Mar 15, 2017 · 30 comments

Comments

@baskerville
Copy link
Contributor

I've tried reboot_on_exit=false on my Glo HD (with firmware 4.3.8945) and it seems to produce a crash while Nickel is relaunching but I'm not sure on how to debug.
@NiLuJe
Copy link
Owner
NiLuJe commented Mar 16, 2017

A description of what leads you to think it's a crash would be nice ;).

(i.e., what exactly happens, when, what's on screen or not; that kind of thing ;)).

Also, which version/build of KOReader are you running?

That said, I haven't had time to check how everything behaves on FW 4.x in general, so, here be dragons ;).

@baskerville
Copy link
Contributor Author

Thanks, well after quitting KOReader, I can see Nickel's progress bar starting to fill, but the home screen is never reached: the progress bar stays frozen at 3 filled bars out of 5.

I'm using KOReader version v2015.11-896-g4316284.

I witnessed the same behavior when I tried with the latest 3.x firmware.

@NiLuJe
Copy link
Owner
NiLuJe commented Mar 17, 2017

I vaguely recall fixing at least one apparent cause of this (IIRC, making sure WIFi was disabled before restarting Nickel), but apparently that wasn't enough ;).

I'll hopefully have more free time available in a few weeks to try and dig into that again, but, as you said, debugging those issues is kind of annoyingly hard...

@pazos
Copy link
pazos commented Apr 8, 2017

Yes, It happens to me too. I mentioned elsewhere, but seems related to https://github.com/koreader/koreader/blob/master/platform/kobo/koreader.sh#L48:L57.

@NiLuJe I think siphon nickel full environment should be safe on fmon side, but produces the same crash in fmon returning to nickel.

@baskerville: you can try deleting those lines https://github.com/koreader/koreader/blob/master/platform/kobo/koreader.sh#L49:L53

nickel environment should be handled by nickel.sh in https://github.com/koreader/koreader/blob/master/platform/kobo/nickel.sh#L10:L27 and https://github.com/koreader/koreader/blob/master/platform/kobo/nickel.sh#L62:L70

@baskerville
Copy link
Contributor Author

@pazos I tried: I tought nickel was caught into an infinite loop because the black squares kept being filled and emptied, but after about 15 seconds the home screen finally appeared but it was displayed in a tiny region of the screen and there was a critical error dialog box with only one button: sign off!

@NiLuJe
Copy link
Owner
NiLuJe commented Apr 9, 2017 via email •
edited
Loading

@baskerville
Copy link
Contributor Author

I found something that sounds related https://www.mobileread.com/forums/showpost.php?p=3403689&postcount=266.

@NiLuJe
Copy link
Owner
NiLuJe commented Apr 9, 2017 via email

@pazos
Copy link
pazos commented Apr 10, 2017 •
edited
Loading

@baskerville: sorry to hear that!

@NiLuJe: yes, siphoning the whole environment makes imposible to return to nickel (It gets stuck on the third square, like baskerville).

I'm not sure what causes this but fmon works really nice loading the minimum environment. Returning from koreader to nickel is less than 3 seconds in my KA1

@baskerville
Copy link
Contributor Author

@pazos Can you provide a link to the fmon archive?

@pazos
Copy link
pazos commented Apr 10, 2017

here is the updated one I proposed for the new instructions. I'm waiting for the fix to this bug and upload kfmon instructions in koreader wiki too.

Look at the lastest comment in
koreader/koreader#2575. It clashes with kfmon, so you'll need to remove kfmon first

@pazos
Copy link
pazos commented Apr 11, 2017

@NiLuJe: I do understand why you launch kfmon via udev hook, but I think I'm going to try to start it from inittab and see what's happen. As you pointed out maybe the environment is different and could cause issues.

kfmon is a good improvement over fmon, with documentation, readable sources and a lot of checks. The missing feature is returning without reboot, which I've been doing since 2012 with fmon.

@baskerville:
The only bug that I can find in nickel without rebooting is:

on returning to nickel: the first sync fails (udhcpcd ins't able to get a lease). Nickel itself seems to handle it in less than a minute. So the next sync will work.

steps to reproduce:
-- enable wifi in nickel
-- run koreader
-- sleep the device
-- back from sleep
-- connnect to wifi again
-- return to nickel

@baskerville
Copy link
Contributor Author

@pazos Thanks, fmon works great (as long as nickel isn't killed while syncing). I wrote a C version of fmon and I improved the shell scripts (wrapping the call inside the loop in on-animator.sh is unnecessary).

@pazos
Copy link
pazos commented Apr 13, 2017

cool!!!!

Please create install instructions and we're done :)

I think is better to move further fmon development to your repo and leave this issue open here.

@NiLuJe
Copy link
Owner
NiLuJe commented Apr 24, 2017

Okay, term & finals are nearly done, I'll be able to take a good look at this Real Soon now! :).

@xpirad
Copy link
xpirad commented Apr 27, 2017

@NiLuJe That is awesome!!!

@xpirad
Copy link
xpirad commented Jun 14, 2017

@NiLuJe How are things going now? Are you still working on this?

@NiLuJe
Copy link
Owner
NiLuJe commented Nov 26, 2017

I just pushed updated binaries to the MR thread, with basically a shot in the dark at playing with the env on kfmon's side.

This should hopefully more closely match fmon? Or not, I still don't have time to investigate all that properly...

On the plus side, that also means the OS X fix finally made it to a binary release... Ooops. ^^.

@NiLuJe
Copy link
Owner
NiLuJe commented Apr 12, 2018 •
edited
Loading

Oookay, that crap was always bugging me, and I needed an excuse to procrastinate, so I took another stab at this...

My current assumption is that all our woes are indeed caused by being started via udev.
Not necessarily because of the env (although that wasn't terribly neat), but because it messes with stdin/stderr/stdout (as it should, given the documented use-cases of the the RUN token).

So, after fixing the same kind of mess on my end (i.e., a crappy env, and fucked up std* fds), it looks sane-ish:

When started from udev, everything points to /dev/null (because of udev, c.f., https://github.com/gentoo/eudev/blob/master/src/udev/udev-event.c#L409), and when started otherwise, everything looks as it should (AFAICT).

Started from udev:

ls -lash /proc/$(pidof kfmon)/fd
total 0
     0 dr-x------    2 root     root           0 Apr 12 04:40 .
     0 dr-xr-xr-x    6 root     root           0 Apr 12 04:39 ..
     0 lrwx------    1 root     root          64 Apr 12 04:40 0 -> /dev/null
     0 lrwx------    1 root     root          64 Apr 12 04:40 1 -> /dev/null
     0 l-wx------    1 root     root          64 Apr 12 04:40 2 -> /usr/local/kfmon/kfmon.log
     0 lrwx------    1 root     root          64 Apr 12 04:40 3 -> /dev/null
     0 lrwx------    1 root     root          64 Apr 12 04:40 4 -> /dev/null
     0 lrwx------    1 root     root          64 Apr 12 04:40 5 -> /dev/null
     0 lr-x------    1 root     root          64 Apr 12 04:40 6 -> anon_inode:inotify

Restarted from an ssh shell:

total 0
     0 dr-x------    2 root     root           0 Apr 12 05:07 .
     0 dr-xr-xr-x    6 root     root           0 Apr 12 05:07 ..
     0 lrwx------    1 root     root          64 Apr 12 05:07 0 -> /dev/null
     0 lrwx------    1 root     root          64 Apr 12 05:07 1 -> /dev/null
     0 l-wx------    1 root     root          64 Apr 12 05:07 2 -> /usr/local/kfmon/kfmon.log
     0 lrwx------    1 root     root          64 Apr 12 05:07 3 -> /dev/pts/0
     0 lrwx------    1 root     root          64 Apr 12 05:07 4 -> /dev/pts/0
     0 lrwx------    1 root     root          64 Apr 12 05:07 5 -> /dev/pts/0
     0 lr-x------    1 root     root          64 Apr 12 05:07 6 -> anon_inode:inotify

(fds 3/4/5 are what will end up as 0/1/2 in a child, i.e., stdin/out/err).

FWIW, nickel:

total 0
     0 dr-x------    2 root     root           0 Apr 12 04:42 .
     0 dr-xr-xr-x    6 root     root           0 Apr 12 04:39 ..
     0 lr-x------    1 root     root          64 Apr 12 04:42 0 -> /dev/null
     0 lrwx------    1 root     root          64 Apr 12 04:42 1 -> /dev/console
     0 lrwx------    1 root     root          64 Apr 12 04:42 10 -> anon_inode:[eventfd]
     0 lrwx------    1 root     root          64 Apr 12 04:42 11 -> /dev/ntx_io
     0 lrwx------    1 root     root          64 Apr 12 04:42 12 -> /tmp/nickel-hardware-status
     0 lr-x------    1 root     root          64 Apr 12 04:42 13 -> /dev/input/event0
     0 lr-x------    1 root     root          64 Apr 12 04:42 14 -> /dev/urandom
     0 lrwx------    1 root     root          64 Apr 12 04:42 15 -> /mnt/onboard/.kobo/KoboReader.sqlite
     0 lrwx------    1 root     root          64 Apr 12 04:42 16 -> /mnt/onboard/.kobo/KoboReader.sqlite-wal
     0 lrwx------    1 root     root          64 Apr 12 04:42 17 -> /mnt/onboard/.kobo/KoboReader.sqlite-shm
     0 lrwx------    1 root     root          64 Apr 12 04:42 18 -> socket:[1567]
     0 lrwx------    1 root     root          64 Apr 12 04:42 19 -> anon_inode:[eventfd]
     0 lrwx------    1 root     root          64 Apr 12 04:42 2 -> /dev/console
     0 lrwx------    1 root     root          64 Apr 12 04:42 20 -> /mnt/onboard/.kobo/BookReader.sqlite
     0 lrwx------    1 root     root          64 Apr 12 04:42 21 -> socket:[1582]
     0 lrwx------    1 root     root          64 Apr 12 04:42 22 -> /mnt/onboard/.kobo/BookReader.sqlite-wal
     0 lrwx------    1 root     root          64 Apr 12 04:42 23 -> /mnt/onboard/.kobo/BookReader.sqlite-shm
     0 lrwx------    1 root     root          64 Apr 12 04:42 24 -> anon_inode:[eventfd]
     0 lr-x------    1 root     root          64 Apr 12 04:42 25 -> /dev/urandom
     0 lrwx------    1 root     root          64 Apr 12 04:42 26 -> /mnt/onboard/.kobo/KoboReader.sqlite
     0 lrwx------    1 root     root          64 Apr 12 04:42 27 -> /mnt/onboard/.kobo/KoboReader.sqlite-wal
     0 lrwx------    1 root     root          64 Apr 12 04:42 28 -> anon_inode:[eventfd]
     0 lrwx------    1 root     root          64 Apr 12 05:07 29 -> anon_inode:[eventfd]
     0 lrwx------    1 root     root          64 Apr 12 04:42 3 -> /dev/fb0
     0 lr-x------    1 root     root          64 Apr 12 04:42 30 -> /dev/input/event1
     0 lrwx------    1 root     root          64 Apr 12 04:42 31 -> anon_inode:[eventfd]
     0 lrwx------    1 root     root          64 Apr 12 05:07 32 -> anon_inode:[eventfd]
     0 lrwx------    1 root     root          64 Apr 12 05:07 33 -> socket:[2783]
     0 lrwx------    1 root     root          64 Apr 12 04:42 34 -> anon_inode:[eventfd]
     0 lrwx------    1 root     root          64 Apr 12 05:07 37 -> /mnt/onboard/.kobo/KoboReader.sqlite
     0 lrwx------    1 root     root          64 Apr 12 04:42 4 -> anon_inode:[eventfd]
     0 lrwx------    1 root     root          64 Apr 12 05:07 41 -> /mnt/onboard/.kobo/BookReader.sqlite
     0 lr-x------    1 root     root          64 Apr 12 04:42 5 -> pipe:[1322]
     0 l-wx------    1 root     root          64 Apr 12 04:42 6 -> pipe:[1322]
     0 lrwx------    1 root     root          64 Apr 12 04:42 7 -> socket:[1324]
     0 lrwx------    1 root     root          64 Apr 12 04:42 8 -> anon_inode:[eventfd]
     0 lrwx------    1 root     root          64 Apr 12 04:42 9 -> anon_inode:[eventfd]

So, tomorrow: actually switching to the animator patch approach, and see how that fares...

@NiLuJe
Copy link
Owner
NiLuJe commented Apr 12, 2018 •
edited
Loading

And... success?!

First initial test w/ Plato...
Nickel takes an ungodly amount of time to restart, but the device doesn't reboot! Yay?

Thing is, it takes so much time that I'm wondering if that actually wasn't already working yesterday... Probably not, because I managed to hit the frontlight timeout yesterday without anything happening :D.

Looking at it over SSH, it seems to be blocking on a bunch of pselect() calls to some pipes until they timeout a couple of times...

So, quick necromancy: pinging @baskerville @pazos & @xpirad : Does that sound remotely familiar with your experience w/ @baskerville's fmon & Plato?

FWIW, I'm on a H2O on FW 4.7.

@baskerville
Copy link
Contributor Author

I can also get a long delay, from time to time, with fmon. But, most of the time, Nickel restarts in less than 2 seconds.

@NiLuJe
Copy link
Owner
NiLuJe commented Apr 12, 2018 •
edited
Loading

I'm wondering if my SIGCHLD handler isn't potentially what's confusing nickel, since those pipes & pselect calls relate to clone()'ed processes...

Going to rip it out and see what happens \o/

EDIT: Going to try something first, I may have fucked up the blocking...

I'm learning (and failing to understand :D) way too much about the unix process lifecycle... Also, signals make my brain hurt >_<".

@NiLuJe
Copy link
Owner
NiLuJe commented Apr 12, 2018 •
edited
Loading

Yup, works as it should without the SIGCHLD handler -_-".
Still not sure if it's having one or blocking (or badly blocking) the signal that Nickel didn't like, but I utterly failed at handling the blocking sanely anyway, so, there you have it :D.

That means I had to abandon a few neat things I quite liked (in theory) about having one, but that, truthfully, weren't terribly useful in practice.

I guess that's the price of not actually having any background in C (or programming in general). You have an idea, you get excited because stuff actually seems to be doable, and then a few hours and LOCs down the line, you realize that it's either a huge mess to design it that way, a terrible idea, has an unknown amounts of weird corner-cases, or it just plain doesn't work. :D.

@NiLuJe
Copy link
Owner
NiLuJe commented Apr 12, 2018

Now to polish things up a bit, and simplify the KOReader scripts I had to mangle in the first place :D.

@NiLuJe
Copy link
Owner
NiLuJe commented Apr 13, 2018

And I managed to spend another night trying something which works neeeeeaaaarly just as I want it, but still manages to mysteriously fail in some circumstances for unknown reasons.

Still, it behaves properly with a bit of a workaround plugged in, and I like it, so, meh.
< 8000 /form>
@NiLuJe
Copy link
Owner
NiLuJe commented Apr 13, 2018 •
edited
Loading

That said, one thing I'm still reliably reproducing on my H2O is the IR grid not waking up after a suspend (from a timeout, and also from the power button if you wait a bit before waking it) once we restart nickel.

FWIW, that happens as soon as we kill nickel, because I initially had to work it around in KOReader...
(Via echo 'a' >| /sys/devices/virtual/input/input1/neocmd).

Keep in mind that this is not new, and sometimes (although somewhat rarely) also happens with only nickel, (i.e., a freshly booted nickel, and never having run anything else besides it during that boot session).

I think at one point I tweaked my KOReader startup script to just SIGSTOP/SIGCONT nickel, because this was horribly annoying when debugging stuff on device...

@NiLuJe
Copy link
Owner
NiLuJe commented Apr 13, 2018 •
edited
Loading

Eureka! Take three appears to behave properly... (On the reaping child process front, I mean).

If all else fails, add threads?!

sigh.

@NiLuJe
Copy link
Owner
NiLuJe commented Apr 14, 2018 •
edited
Loading

It's alive! \o/

I'm sorry it took me so long to fix this, and I'm sorry I managed to miss @baskerville's fmon fork for so long (despite you mentioning it in this very thread, don't know how I managed that o_O. I only ended up looking it up purely randomly, because I happened to be checking out the MR KoboDev forum on a whim, and even then, only in KSM's credits, not even Plato's thread :D).

Anywaaaaay. Will roll a release and close this.

Please shout at me if I broke something else ^^.

@NiLuJe
Copy link
Owner
NiLuJe commented Apr 14, 2018

Done \o/.

@NiLuJe NiLuJe closed this as completed Apr 14, 2018
@NiLuJe
Copy link
Owner
NiLuJe commented Apr 14, 2018 •
edited
Loading

Sneaked in a minor (but long-standing) fd leak fix w/ 3881d72

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@NiLuJe @baskerville @pazos @xpirad
0