Skip to content

Commit

Permalink
Same pkill trick as the Kobo scripts
Browse files Browse the repository at this point in the history 
Only here to satisfy my OCD ;p
  • Loading branch information
@NiLuJe
NiLuJe committed Apr 26, 2015
1 parent 6f815e2 commit a736a57
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion platform/kindle/koreader.sh
View file
Original file line number Diff line number Diff line change
Expand Up @@ -208,7 +208,7 @@ fi
./reader.lua "$@" 2> crash.log

# clean up our own process tree in case the reader crashed (if needed, to avoid flooding KUAL's log)
if pidof reader.lua > /dev/null 2>&1 ; then
if pkill -0 reader.lua ; then

This comment has been minimized.

Sign in to view

Copy link
@Markismus

Markismus Apr 28, 2015

Why is this different from pkilling an sh-script? Or was this earlier than your discussion with Tshering?

This comment has been minimized.

Sign in to view

Copy link
@NiLuJe

NiLuJe Apr 28, 2015

Author Owner

pidof matches the whole commandline, while pkill only checks the actual name of the 'master' binary.

[At least in the busybox case, which is what we're concerned about, I haven't actually checked if that behavior deviates from procps]

Since ksm is a shell script, and called as an argument to sh, and not via a shebang, its full commandline is actually

/bin/sh /blah/blah/ksmhome.sh

and not

/blah/blah/ksmhome.sh

In the first case, pkill would only 'see' /bin/sh, which is why it failed ;).

In the same vein, and to illustrate the shebang case, KOReader itself runs via a Lua script (reader.lua) interpreted via luajit, but we do it through a shebang (#!./luajit), so it appears to run as /blah/blah/reader.lua; which is while the pkill -0 reader.lua done in the Kindle scripts is functional ;).
logmsg "Sending a SIGTERM to stray KOreader processes . . ."
killall -TERM reader.lua
fi
Expand Down

11 comments on commit a736a57

@Markismus
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, still don't get it.

I understand the reason why ksmhome.sh fails.

However, I still don't see why starting a script with #!/bin/sh is different from starting it with #!.luajit other than apparently luajit isn't seen as the master binary, but reader.lua is. Both use the shebang syntax, so both call a binary and are added as interpreter directive.

The only real difference that I see, is that the path passed is identical to the path of the binary in the case of luajit.

Got it Thanks

@NiLuJe
Copy link
Owner Author

@NiLuJe NiLuJe commented on a736a57 Apr 28, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, pkill & pidof both behave the same way, so this is still broken.

Thanks for making me look at this again.

We need to use pgrep -f to match the full command-line, since we don't have the -x flag of procps's pidof to do that.

Utterly confused a to why it also fails to catch it when using a shebang, though, which means I need to double-check how my Kindle behaves.

@Markismus
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just read ksmhome.sh and it starts with a shebang, too. I assumed it would have been called via /bin/sh ksmhome.sh, because then your explanation made sense, but now it doesn't anymore.

Ah, but I just refreshed and see that there is another problem...

Based on the wiki I assume it fails, because of the shebang. There is no other way those scripts are called. Just read that the whole shebang was introduced to let the scripts appear when you run a ps command.

@NiLuJe
Copy link
Owner Author

@NiLuJe NiLuJe commented on a736a57 Apr 28, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guys, *nix is weird.

#!/bin/sh

echo "pidof test.sh: $(pidof test.sh)"
pkill -0 test.sh &>/dev/null
echo "pkill -0 test.sh: $?"
echo "pgrep -f test.sh: $(pgrep -f test.sh)"

echo "Wheee."

->

[root@kindle root]# sh test.sh 
pidof test.sh: 
pkill -0 test.sh: 1
pgrep -f test.sh: 11905
Wheee.
[root@kindle root]# ./test.sh 
pidof test.sh: 11909
pkill -0 test.sh: 1
pgrep -f test.sh: 11909
Wheee.

Vs.

# !/bin/sh

echo "pidof test.sh: $(pidof test.sh)"
pkill -0 test.sh &>/dev/null
echo "pkill -0 test.sh: $?"
echo "pgrep -f test.sh: $(pgrep -f test.sh)"

echo "Wheee."

[Notice the space between # and !]

->

[root@kindle root]# sh test.sh 
pidof test.sh: 
pkill -0 test.sh: 1
pgrep -f test.sh: 12304
Wheee.
[root@kindle root]# ./test.sh 
pidof test.sh: 
pkill -0 test.sh: 1
pgrep -f test.sh: 12308
Wheee.

TL;DR: spaces are evil. I remember being told that that shebang syntax with an extra space was more portable (and I happened to be using it since that's what my VIM config automagics when creating a .sh), but that's sneaky as fuck.

TL;DR²: pkill is a terrible idea to check for interpreted scripts, shebang or not.

@NiLuJe
Copy link
Owner Author

@NiLuJe NiLuJe commented on a736a57 Apr 28, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since I have no idea how ksmhome.sh is actually run, I'll switch to pgrep, it appears to be less prone to fuckery ;).

@Markismus
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amen to that.

You left me confused as hell, but that's how I started, so that's no biggie.

@NiLuJe
Copy link
Owner Author

@NiLuJe NiLuJe commented on a736a57 Apr 28, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's because I managed to paste the same script twice, ooops. Edited the post, it should make (slightly) more sense now ;).

@NiLuJe
Copy link
Owner Author

@NiLuJe NiLuJe commented on a736a57 Apr 28, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And thanks for the wiki link, that sheds some light on my portability comment regarding that extra space (spoiler: it's horseshit, or at the very least no-one has needed to care about it since the 1980s ;p).

@NiLuJe
Copy link
Owner Author

@NiLuJe NiLuJe commented on a736a57 Apr 28, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fun fact:

#! /bin/sh

behaves properly.

@NiLuJe
Copy link
Owner Author

@NiLuJe NiLuJe commented on a736a57 Apr 28, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the meantime, I'll go fix my VIM config ;).

@houqp
Copy link

@houqp houqp commented on a736a57 Apr 29, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So are you going with "#!/wtf" or "#! /wtf" :P

Please sign in to comment.