[libvirt] [PATCH] util: Remove logging handlers in virExec
Cole Robinson
crobinso at redhat.com
Wed Jan 13 16:22:46 UTC 2010
On 01/13/2010 04:20 AM, Daniel P. Berrange wrote:
> On Tue, Jan 12, 2010 at 03:54:39PM -0500, Cole Robinson wrote:
>> On 01/12/2010 03:46 PM, Daniel P. Berrange wrote:
>>> On Tue, Jan 12, 2010 at 03:26:26PM -0500, Cole Robinson wrote:
>>>> This allows debug statements and raised errors in hook functions to
>>>> actually be logged somewhere (stderr). Users can enable debugging in the
>>>> daemon and now see more info in /var/log/libvirt/...
>>>>
>>>> Signed-off-by: Cole Robinson <crobinso at redhat.com>
>>>> ---
>>>> src/util/util.c | 6 ++++++
>>>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/src/util/util.c b/src/util/util.c
>>>> index 44a4b2f..23d781d 100644
>>>> --- a/src/util/util.c
>>>> +++ b/src/util/util.c
>>>> @@ -334,6 +334,7 @@ __virExec(virConnectPtr conn,
>>>> int pipeerr[2] = {-1,-1};
>>>> int childout = -1;
>>>> int childerr = -1;
>>>> + int logprio;
>>>> sigset_t oldmask, newmask;
>>>> struct sigaction sig_action;
>>>>
>>>> @@ -452,6 +453,11 @@ __virExec(virConnectPtr conn,
>>>> of being seen / logged */
>>>> virSetErrorFunc(NULL, NULL);
>>>>
>>>> + /* Make sure any hook logging is sent to stderr */
>>>> + logprio = virLogGetDefaultPriority();
>>>> + virLogReset();
>>>> + virLogSetDefaultPriority(logprio);
>>>> +
>>>
>>> I'm not sure that I understand this - surely the child process is already
>>> inheriting this setup from the parent libvirtd ?
>>>
>>> Daniel
>>
>> Problem is that virExec closes only the file descriptors it is using,
>> which means it will close the file descriptors for any nontrivial
>> logging handlers. I could add some internal logging API to get the
>> relevant fds and keep them from being closed, but not sure if we
>> necessarily want to preserve those for a daemonized process?
>
> Oh of course - can you put a comment to that effect in your patch as a
> reminder. ACK to the patch
>
> Daniel
Thanks, pushed with an updated comment.
- Cole
More information about the libvir-list
mailing list