On Wed, Sep 11, 2013 at 4:51 PM, martin f krafft <madd...@debian.org> wrote: > also sprach Joe Healy <joehe...@gmail.com> [2013.09.11.0815 +0200]: >> Running: >> >> salt '*' pkg.install salt-minion >> >> will result in the minion (and the dpkg) process being killed part >> way through the upgrade and requiring manual interverntion. > > Isn't this a fundamental problem in Salt, which should be fixed > there? I don't think that using at(1) for this is really a solution, > but a gross hack, which still requires the admin to know what's > going on and to wait up to 1:59 minutes.
I agree using at (and this) is a hack. The principle I was working off when doing the original update of the init.d script was that /etc/init.d/salt-minion stop should stop the minion and all child processes. I still think this is the right thing. Doing this has ended up in a situation where it is difficult to upgrade the minion without manually going around to each one. I agree with the point about it being fixed in salt. I think they should probably handle signals differently when they are updating packages (maybe even a special case for salt itself). In the end I decided that it was best to relax the killing all processes until this can be resolved properly. Ending up in a situation where each minion needs "dpkg --configure -a && apt-get -f install" to be run manually after someone seemed to be the worst situation possible. I'm yet to file a bug upstream, but will do so. In the mean time, I have already uploaded a package with the change reverted. I believe it would be possible for me to either stop that package (possibly dcut). If you have any advice, it would be much appreciated. Thanks, Joe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
