Opened 11 years ago

Closed 9 years ago

Last modified 9 years ago

#4162 closed Enhancement (fixed)

daemon should reopen logfile on SIGHUP

Reported by: bugmenot Owned by: gvdl
Priority: Normal Milestone: 2.60
Component: Daemon Version: 2.22
Severity: Normal Keywords: patch-provided
Cc: gvdl@…

Description

After switching log file to a new one, compressing it, etc. tools like logrotate, newsyslog need for daemon to reopen the file, so they send SIGHUP by default. This can be worked around by using syslog.

Attachments (3)

4162RecycleLogs.patch (2.1 KB) - added by gvdl 9 years ago.
4162-RecycleLogs.2.patch (2.2 KB) - added by gvdl 9 years ago.
recyle-logs.3.patch (2.1 KB) - added by jordan 9 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 10 years ago by jordan

  • Keywords patch-needed added

There's a plausible use case for this feature, but it's not one that will affect very many people IMO.

This probably isn't going to be added unless someone submits a patch.

comment:2 Changed 9 years ago by gvdl

  • Cc gvdl@… added
  • Owner set to gvdl
  • Status changed from new to assigned

Changed 9 years ago by gvdl

comment:3 Changed 9 years ago by gvdl

Fixed waiting for commit

Note: #4895 SIGHUP race must be applied before this patch.

comment:4 Changed 9 years ago by gvdl

  • Keywords patch-provided added; patch-needed removed

comment:5 Changed 9 years ago by gvdl

Fixed patch to live onto of modified #4895.

Changed 9 years ago by gvdl

comment:6 Changed 9 years ago by jordan

  • Probably shouldn't use optarg in gotsig()'s error message
  • It would be better to key fropen off of logfileName instead of logfile -- it handles the stderr case automatically, and if a freopen fails, the next SIGHUP will still try to reopen.
  • The "NULL != foo" is reasonable for avoiding accidental assigns, but I really don't like it. Instead of using "foo != NULL", I've split the difference and used "foo" here to avoid both accidental assigns and the non-lvalue-first idiom. :)

Changed 9 years ago by jordan

comment:7 follow-up: Changed 9 years ago by jordan

gvdl, any thoughts with recycle-logs.3.patch?

comment:8 in reply to: ↑ 7 Changed 9 years ago by gvdl

Replying to jordan:

gvdl, any thoughts with recycle-logs.3.patch?

Sorry, I've been changing over my development system and getting a DS1512 setup as a Linux machine. That has distracted me. I'll try to look at it tonight.

comment:9 Changed 9 years ago by gvdl

Reviewed recycle-logs.3.patch : No problems with me. BTW I agree with the NULL != idiom is horrible, It seemed that Roman coding (when in Rome...) required some sort of NULL comparison, I personally loath NULL comparisons. I've seen too many things go wrong with =/== and avoid them when comparing anything against zero.

I'm trying to work out how I got my patch to even compile and let alone run. There was no optarg parameter for the stderr printf in gotsig() weird as I really did test it believe it or not ;-). Anyway your patch is fine.

comment:10 Changed 9 years ago by cfpp2p

I'm trying to work out how I got my patch to even compile and let alone run. There was no optarg parameter for the stderr printf in gotsig() weird as I really did test it believe it or not ;-). Anyway your patch is fine.

gotsig() is only called from main() where optarg parameter was defined, so that's why it compiled and ran OK.

comment:11 Changed 9 years ago by jordan

  • Milestone changed from None Set to 2.53
  • Resolution set to fixed
  • Status changed from assigned to closed

Landed in r13330

comment:12 Changed 9 years ago by livings124

  • Milestone changed from 2.53 to 2.60
Note: See TracTickets for help on using tickets.