#668 Nothing is logged into the sssd log after the log is rotated
Closed: Fixed None Opened 13 years ago by dpal.

I think I have seen it before and reported but could not find it among open or closed tickets.

The issues is:
- The machine was on VPN
- The log got rotated while on VPN connected to the central server
- I suspended machine
- Moved to a different network
- Woke system up
- Experienced a delay before the prompt came up for about 90 seconds (reported and ticket #664).
- Went to look at the log and observed that the log is not being written.
- Tried to lock unlock still nothing goes into the log


Dmitri,
have you checked if the logs ended up in the old file ?
If the sighup failed to reach the logging process it may still be logging to the rotated file.

Steve looked on the system so I am not dreaming. The situation is the following:

- All new files are created but size 0
- All old files are compressed
- SSSD still holds old files open

The assessment is that the SIGHUP was in some way ignored or fclose operation failed.

I'm pretty sure that what happened is that fclose() failed on the old files for some reason, so SSSD continued to try to write to those files, despite the fact that logrotate had subsequently deleted them.

My best guess is that we received a signal during the flush portion of fclose() and it caused an EINTR return. I have submitted a patch to the list to retry on EINTR or report better information to the syslog to help us identify the problem further.

General question: if we fail to close the existing file descriptor, should we log it and just open a new file anyway? I know that in this is a resource leak, but I'm somewhat concerned about not having debug logs available if other things are going wrong.

If the old files have been compressed than it means the data is going to the (now deleted) original uncompressed file.

I see the problem with the resource leak but we shouldn't fail to reopen files if fclose() fails. But we need to save the information and log it as the first thing in the new files at level 0 I think. So that admins are warned that we are leaking there.
File descriptors are not infinite after all, and if it keeps happening, at some point the process will run out of file descriptors.
If that happens we may have no other option but abort.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.5.0

Fields changed

owner: somebody => sgallagh

Fixed by 999d925

fixedin: => 1.5.0
resolution: => fixed
status: new => closed

Fields changed

rhbz: => 0

Metadata Update from @dpal:
- Issue assigned to sgallagh
- Issue set to the milestone: SSSD 1.5.0

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1710

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata