[pkg-discuss] Re: [review] graceful SIGTERM / SIGHUP handling for pkg(1)
- From: Edward Pilatowicz <
- To: Shawn Walker <
- Subject: [pkg-discuss] Re: [review] graceful SIGTERM / SIGHUP handling for pkg(1)
- Date: Thu, 15 Aug 2013 13:35:14 -0700
On Thu, Aug 15, 2013 at 01:08:23PM -0700, Shawn Walker wrote:
> On 08/15/13 12:58, Edward Pilatowicz wrote:
> >On Sun, Aug 11, 2013 at 04:20:43PM -0700, Shawn Walker wrote:
> >>The following webrev contains changes for the following:
> >> 17230751 pkg execution should gracefully handle SIGTERM and SIGHUP
> >i hate signals and singal handling. is there any reason that we don't
> >just write a "start" history entry before starting an operation, and
> >then write a "end" history entry when we've finished? if we did this we
> >wouldn't need signal handling (which won't work for things like SIGKILL,
> >SIGSEGV, etc). i'm guessing the answer is "this would require
> >re-writing how the history mechanism works", but i thought i'd ask
> For history, each operation is recorded within a single file (XML),
> what you suggest would mean writing each history file twice (at
> start of operation and at end) or writing two separate files.
> That's a pretty substantial change in behaviour.
> Although, I'd note that the History module needs to be rewritten at
> some point anyway, so this should be considered then.
> However, I think we still want to handle the signal if only to avoid
> the spurious output that Python currently produces. Bart also
> suggested that we may want to consider ignoring SIGHUP/SIGTERM
> during specific critical sections in which case we'd end up doing
> some signal handling anyway.
> With that in mind, do the proposed changes look right?
the changes seem pretty strait forward.
- i don't know much about how python does signal handling, so i was
wondering what happens if the abort() call in the signal handler
generates an exception. that led me into history.py`abort() to see
what kind of exceptions it might generate, and when i got to the
highly magical history.py`__setattr__() i realized i didn't want to
know the answer that badly.
- in image.py, i'm annoyed by the fact that we keep repeating the names
of the cache files everywhere instead of having a define for each
file. that said, your code matches the current conventions, so it's
- do we want a test case for this functionality? (the pkg client could
check for some debug value and send itself a SIGHUP or SIGTERM in the
middle of plan execution, then we could check if there is a history
entry and if all the cache files have been deleted.)