chill wrote:
> Thanks for taking a look in that much detail. I'd love to agree with
> your final statement, but I've been very careful to make sure that the
> pidfile and the process stay in sync. My current test script avoids the
> init.d script altogether - it starts Squeezelite manually (it doesn't
> use 'sudo', but since it's called by udev the process is owned by root
> anyway), and the pidfile is created with 'sudo bin/echo...' (perhaps the
> sudo isn't necessary for the same reason that the script is run under
> udev).
>
Just a nit. This line, from your script, does _not_ create the pidfile
using sudo:
Code:
--------------------
sudo /bin/echo "$PID" > $PIDFILE
--------------------
The echo runs as sudo, but the redirection into the pidfile is done as
the non-sudoed script. In the shell language, redirections belong to
the shell, not the command that they're redirecting. There are various
workarounds, but the most popular I think is to use tee to write the
file for you. (It turns out there aren't that many programs which will
simply take stdin and put it into a file. Using tee for this is
convenient, even if you have to discard the output from tee itself.)
Code:
--------------------
echo $PID | sudo tee $PIDFILE >/dev/null
--------------------
As you say, the distinction should be moot, if it's being run from udev,
so as I said, this is just a nit, and an FYI.
>
>
> So with everything in sync, the default 'kill' is NOT able to kill the
> process, whereas /bin/kill IS. In both cases, the kill command is being
> called directly by the udev script (i.e. without invoking the
> start-stop-daemon) in response to the DAC being unplugged,
>
> And of course there's the other thorny little complication that the
> behaviour of 'start-stop-daemon stop' is different on my Pi4B, where it
> works.
I still don't believe that "kill" will do anything different than
/bin/kill, given the two are running in an identical environment. (I
also don't believe you should be using "-9" everywhere. Squeezelite
dies perfectly happily with a plain "kill". Using -9 is a bad habit.)
I do have a couple of other comments on and questions about your script,
if you don't mind. Not that I see anything explicitly wrong, but maybe
they can be simplified, and simpler code is easier and safer.
First:
Code:
--------------------
# Set DAEMON to the actual binary
[ -f $TCEMNT/tce/squeezelite ] && DAEMON=`readlink $TCEMNT/tce/squeezelite`
|| DAEMON=/usr/local/bin/squeezelite
# Legacy check, incase this is the binary instead of symlink.
[ "$DAEMON" = "" ] && DAEMON=$TCEMNT/tce/squeezelite
--------------------
Is there any reason not to just use the shell to find the binary? And,
why does it matter if it's a symlink.
Code:
--------------------
DAEMON=$(which squeezelite)
--------------------
Second:
Code:
--------------------
$DAEMON -n "$NAME" ..... &
sleep 1
local PID=$(/bin/busybox pgrep $DAEMON | /usr/bin/awk '{print $1}')
sudo /bin/echo "$PID" > $PIDFILE
--------------------
Anything wrong with letting the shell tell you the PID? That's what $!
is for. It always contains the pid of the last process put into the
background.
Code:
--------------------
$DAEMON -n "$NAME" .... &
echo $! >$PIDFILE
--------------------
Lastly, even though you're no longer using the init.d script to
start/stop the daemon, you're still using it to check the daemon's
status. But all it does when you ask, is checks to see if the pidfile
exists. You should also also check to see if the process represented by
that pidfile exists. You can do that with the "-0" option to kill:
Code:
--------------------
if [ -e $PIDFILE ] && kill -0 $(cat $PIDFILE)
then
echo process is running
else
echo no process found
fi
--------------------
Anyway, I'm sure you'll figure out your problem. You set yourself a
lofty goal when you started this project, and you've done well so far!
paul
------------------------------------------------------------------------
pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510
View this thread: http://forums.slimdevices.com/showthread.php?t=113661
_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix
