Thank you for your answer, I made a little experiment to show my point:
I made a simple script:
-----------------------------------------------------------------------
#!/bin/bash
function cleanup () {
while true
do
sleep 0.1;
echo "sigint received" >> /home/ubuntu/shutdown.txt;
done
}
trap cleanup SIGHUP SIGINT SIGTERM
sleep 2000
-----------------------------------------------------------------------
This script is launched using an upstart script. Basically, it listens for
the SIGINT signal and when received it output something in a file. The
upstart script to launch it is simple:
----------------------------------------------------------------------
description "testing shutdown behaviour"
kill timeout 100
exec bash /home/ubuntu/shutdown.sh
-----------------------------------------------------------------------
When I start this script and stop it manually (sudo stop shutdowntesting),
I see that a SIGINT signal is being trapped (for 100 seconds). However,
when I do not stop it manually but rather shutdown the entire container
(using lxc-shutdown), I don't see any SIGINT trapped, that is why I assume
this process is not stopped gracefully.
Let me know if I'm not clear,
Thanks for your help.
2014-03-19 18:25 GMT+01:00 Tamas Papp <[email protected]>:
>
> On 03/19/2014 06:21 PM, Robin Monjo wrote:
> > Hello,
> >
> > I'm using LXC 0.7.5 with the stock ubuntu template. My containers are
> > running ruby processes that are managed by upstart (launched by
> > upstart scripts).
> >
> > I need these processes to be gracefully stopped when shutting down a
> > container, i.e send the SIGTERM signal and wait for it to be done
> > before fully shutting down my container.
> >
> > I see that inside a container, upstart listen for the SIPWR signal and
> > execute "shutdown -h now "SIGPWR received"", is it safe to remove this
> > in order to achieve my goal ? Or is there any other alternatives ?
>
>
> If you send sigpwr, it stops services gracefully.
> If you remove that, it doesn't.
>
> So what do you want exactly? I may misunderstand something.
>
> tamas
> _______________________________________________
> lxc-users mailing list
> [email protected]
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
_______________________________________________
lxc-users mailing list
[email protected]
http://lists.linuxcontainers.org/listinfo/lxc-users
