Bug#712023: initscripts: wait for child to exit during shutdown/reboot

[Pierre Ynard]

tags 712023 moreinfo
thanks

> I have made a script to readout the vm's that are running and save
> there state one by one. This takes some time. At the beginning no vm
> was saved right. I did some tunning with the scripts and have now 5-10
> sec's before the other vboxservices are terminated. So i can bring 3
> maybe 4 syetems the rightway down.
>
> I did look in the documentation, and i didnot found a usefull option ,
> that could ensure me that the vm is brought down the rightway. (wait
> for child to terminated)

I'm not sure I understand correctly. Does your script run outside the
VMs to list and save them one by one, or does it run inside each VM?
What does it do? How do you launch your script? What terminates the VMs
in the wrong way? What would be the right way?

> I am looking for a manner that the system will wait for the proces to
> terminated and not be killed. Because killing running vm's might lead
> top dataloss.

You can write an init script to save and stop your VMs waiting all the
time it takes, and set proper dependencies for that init script to
ensure the shutdown sequence waits for it to have completed, with all
your VMs properly saved, before all remaining processes on the system
are killed. Is there any reason why that wouldn't work in your case?

> I'm thinking about some tag in the initscripts - to place if a proces
> has to be waited for. Maybe with the possibillity to set a maxtime,
> so it is guaranted that the machine will not hang for waiting on a
> process that will not terminated.

Considering that you should be able to do this in the way I mentioned
above, I don't think it's necessary to add such a mechanism - but maybe
I misunderstood your problem.

-- 
Pierre Ynard

Bug#712023: initscripts: wait for child to exit during shutdown/reboot

[erik]

Package: initscripts
Version: 2.88dsf-41
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
I use virtualbox. I have virtualmachines on my box and want to bring them down
or save the state there in, before the system is going down.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I have made a script to readout the vm's that are running and save there state
one by one. This takes some time. At the beginning no vm was saved right. I did
some tunning with the scripts and have now 5-10 sec's before the other
vboxservices are terminated. So i can bring 3 maybe 4 syetems the rightway
down.
I did look in the documentation, and i didnot found a usefull option , that
could ensure me that the vm is brought down the rightway. (wait for child to
terminated)

   * What was the outcome of this action?

   * What outcome did you expect instead?
I am looking for a manner that the system will wait for the proces to
terminated and not be killed. Because killing running vm's might lead top
dataloss.

I'm thinking about some tag in the initscripts - to place if a proces has to be
waited for. Maybe with the possibillity to set a maxtime, so it is guaranted
that the machine will not hang for waiting on a process that will not
terminated.

Thanks


*** End of the template - remove these lines ***



-- System Information:
Debian Release: 7.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages initscripts depends on:
ii  coreutils   8.13-3.5
ii  debianutils 4.3.2
ii  libc6   2.13-38
ii  lsb-base4.1+Debian8
ii  mount   2.20.1-5.3
ii  sysv-rc 2.88dsf-41
ii  sysvinit-utils  2.88dsf-41

Versions of packages initscripts recommends:
ii  e2fsprogs  1.42.5-1.1
ii  psmisc 22.19-1+deb7u1

initscripts suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org