Make reboot_on_exit=false work? about kfmon HOT 30 CLOSED

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 ;).

from kfmon.

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.

from kfmon.

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...

from kfmon.

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

from kfmon.

@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!

from kfmon.

from kfmon.

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

from kfmon.

from kfmon.

@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

from kfmon.

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

from kfmon.

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

from kfmon.

@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

from kfmon.

@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).

from kfmon.

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.

from kfmon.

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

from kfmon.

@NiLuJe That is awesome!!!

from kfmon.

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

from kfmon.

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. ^^.

from kfmon.

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...

from kfmon.

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.

from kfmon.

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.

from kfmon.

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 >_<".

from kfmon.

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.

from kfmon.

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

from kfmon.

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.

from kfmon.

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...

from kfmon.

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

If all else fails, add threads?!

sigh.

from kfmon.

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 ^^.

from kfmon.

Done \o/.

from kfmon.

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

from kfmon.