#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)
Change History (15)
comment:1 Changed 9 years ago by jordan
- Keywords patch-needed added
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: ↓ 8 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
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.