Re: Daemons in schroot or how to start chroot automatically
On Mon, 2012-07-23 at 10:25 +0100, Roger Leigh wrote:
> On Sun, Jul 22, 2012 at 05:27:14PM +0200, Ramon Hofer wrote:
> > On Son, 2012-07-22 at 15:58 +0100, Roger Leigh wrote:
> > > On Sun, Jul 22, 2012 at 03:25:49PM +0200, Ramon Hofer wrote:
> > > > On Sam, 2012-07-21 at 22:05 +0100, Roger Leigh wrote:
> > > > > I would also check the return status of schroot. If sid-sab
> > > > > already exists, then session creation will fail, and you'll
> > > > > reuse the old session. That might not be incorrect, but
> > > > > in the general case, I'd recommend checking.
> > > >
> > > > I was thinking about this too. But I saw no need to create a new session
> > > > if the old is still there.
> > > > What could be drawbacks of doing so?
> > >
> > > None really; they can even persist across reboots. (That's what
> > > the "recover-session" action is for.)
> >
> > Hmm, then maybe I should check if there'are lost sessions upon the start
> > of the script?
> > Or will either schroot -b or -r work with such a lost session?
>
> By default, the schroot init script will automatically recover any
> sessions at boot (see /etc/default/schroot). So you shouldn't have
> to worry about that. It's basically just running the setup scripts
> again to ensure that all filesystems are mounted, etc.
Ok, great!
I now changed the stop function to (added the if test) to get rid of
error messages when running `sid-sabnzbdplus stop` twice:
stop_sab() {
if [ -f /var/lib/schroot/session/sid-sab ]; then
schroot -rq -c $NAME /etc/init.d/sabnzbdplus stop
schroot -eq -c $NAME
else
echo "SABnzbd+ not running, not stooped" 2>&1
fi
}
Or is there a better way to test if a session is still available?
`schroot -l -c $NAME` didn't work because it returns the same error
message as e.q. `schroot -eq -c $NAME` when the session isn't running
anymore.
Cheers
Ramon
Reply to: