-
If I establish signal handlers prior to invoking an RPM function then when I return from that function the signal handlers are no longer "active". For example,
If I move the I installed Is there a call I should be making to clean up the RPM environment that would restore my signal handler? Thanks... Neale |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Sorry for the late response. The question is somewhat rpm version dependent: rpm versions >= 4.18 do not mess with signal delivery, but older versions indeed do due to Berkeley DB requirements. Various signals get hijacked by rpm at the time of rpmdb open, and should be returned to previous state when the db and all cursors are closed. What it comes down to is basically ensuring match iterators (mi in your example) or transaction sets linger around. The former is best ensured by avoiding placing them in variables in the first place, eg use this instead:
The database connection is hidden behind the ts object, it'll get garbage collected and closed when it goes out of scope but if you can manually achieve that with either |
Beta Was this translation helpful? Give feedback.
Sorry for the late response.
The question is somewhat rpm version dependent: rpm versions >= 4.18 do not mess with signal delivery, but older versions indeed do due to Berkeley DB requirements. Various signals get hijacked by rpm at the time of rpmdb open, and should be returned to previous state when the db and all cursors are closed. What it comes down to is basically ensuring match iterators (mi in your example) or transaction sets linger around.
The former is best ensured by avoiding placing them in variables in the first place, eg use this instead:
The database connection is hidden behind the ts object, it'll get garbage collect…