On Fri, Jul 15, 2011 at 4:05 PM, Ankit Chaturvedi < ankit.chaturv...@gmail.com> wrote:
> On Fri, Jul 15, 2011 at 3:49 PM, Anupam Jain <ajn...@gmail.com> wrote: > > > On Fri, Jul 15, 2011 at 3:13 PM, Ankit Chaturvedi < > > ankit.chaturv...@gmail.com> wrote: > > > >> > >> On Fri, Jul 15, 2011 at 2:29 PM, Anupam Jain <ajn...@gmail.com> wrote: > >> > >>> Hi all, > >>> > >>> I originally posted this question on > >>> stackoverflow< > >>> > http://stackoverflow.com/questions/6624622/what-happens-in-bash-when-you-do-ctrl-c-hint-its-not-simply-sending-a-sigint > >>> >, > >>> > >>> but did not receive a satisfactory response. Any ideas? > >>> <snip> > >>> > >> Heard of signal handlers? SIGINT (Ctrl-C) is trapped by libdpkg, which > >> then performs cleanup and saves index state before exiting. apt-get is > only > >> a frontend for dpkg. > >> > > > > You are misunderstanding the question. I know that something (I guess > dpkg) > > catches the signal and then saves state. The question is why the same > thing > > would not happen when I send SIGINT manually. > > > > The problem I am trying to solve is as follows - I would like to > interrupt > > the apt-get install process *from a script* and then have it resume > again. I > > assumed that sending a SIGINT would be exactly the same as a Ctrl-C. > > Apparently it's not. Why? > > > > Ah, my bad. In that case you should be using "apt-get -d" to first download > the package (with resume) and then install it later. As mentioned in the > last mail, these caveats would still apply: > > > "the size of package (if it's too small, it may be kept in tmpfs instead > of /var/cache/apt/archive), or if the remote timestamp/checksum changes, or > server may not support http-resume method for binaries, or if it's a source > download. > > The last case would fail to resume is you change directory before calling > apt-get after interrupt. > Also, I think SIGINT would be delivered to sudo instead of apt-get in your > script. Try running your script with sudo instead of using sudo within > script and you should see the desired result. Or use pidof, as suggested on > stackoverflow. > > > > > > > -- AJ > > > > > > These are different signals. * SIGKILL * SIGSTOP * SIGINT * SIGTERM SIGKILL and SIGSTOP cannot be caught and overriden, as well as cannot be skipped. So, if a process gets SIGKILL, it cannot trap it, and cannot do cleanup actions performed inside its signal HANDLER (wrapper). You can send SIGKILL with: $ kill -9 <processid> $ kill -KILL <processid> But if you say: $ kill <processid> $ kill -TERM <processID> then the process can catch it and perform its own actions. Regards, - Ravi Kumar > > -- > -- > Ankit Chaturvedi > GPG: 05DE FDC5 468B 7D9F 9F45 72F1 F7B9 9E16 ECA2 CC23 > <http://www.google.com/profiles/ankit.chaturvedi> > _______________________________________________ > Ilugd mailing list > Ilugd@lists.linux-delhi.org > http://frodo.hserus.net/mailman/listinfo/ilugd > _______________________________________________ Ilugd mailing list Ilugd@lists.linux-delhi.org http://frodo.hserus.net/mailman/listinfo/ilugd
