[Piuparts-devel] preparing feature/slave-run-join

Andreas Beckmann anbe at debian.org
Sat Feb 23 18:40:35 UTC 2013

so far we have here (on top of for-holger):

Andreas Beckmann (3):
      slave_run: do not run the screen as root
      use screen -ls to check for running screens
      slave_join: use 'script /dev/null' to get a writable tty

These three should already provide a better working solution.

But now I'm stumbling on this piece of code (maybe I asked this
before, but maybe I only wanted to do so)

trap "cat $SCREENLOG | mail -s 'slave abnormaly ended' piupartsm ; rm $SCREENLOG; exit" TERM EXIT
screen -L -d -m -S $SESSIONNAME @sharedir@/piuparts/piuparts-slave
trap - TERM EXIT

* what's that trap good for? we run screen as a daemon, so it
should fork away before it starts to run the payload (piuparts-slave)

* That trap is nothing that gets inherited by the screen or whatever ...

* if we just want to know whether it's running, we could sleep and
  screen -ls again

and that comment as well:

# run piuparts-slave in screen so that a screendump can be mailed via cron to monitor the slave

* who/what is sending screenlogs by mail?

and this, too:

rm -f $SCREENLOG    # used by ~piupartsm/bin/detect_slave_problems

What's this deletion good for? (Except of course for preventing
the logfile from growing infinitely.)
If it's deleted and not getting recreated, we can deduce that
the slave is not running. But then we should write something
like this in the comment.

And why do we this in detect_slave_problems:

... | mail -s "problem with piuparts-slave detected" piupartss

It's a cronjob, and instead of having cron mail us the output
if there is need for output we send it ourselves to us.
(only difference would be the Subject:)


More information about the Piuparts-devel mailing list