Nicolas Williams wrote: > On Wed, Nov 11, 2009 at 01:44:31PM -0800, Rob Johnston wrote: >> Nicolas Williams wrote: >>> But it will retain euid == 0, yes? >> Yes. > > It doesn't need to after opening log files. > >> Also, won't this mean that the >>> daemon itself will not be able to rotate logs? >> Yes - though the only log that the daemons will currently create is a >> debug log, which is not enabled by default. And there is no support >> in the daemons for rotating the debug logs. The other intention >> behind retaining uid 0 was to allow it to dump it's cores under >> /var/fm/notify/. > > On the phone you characterized this debug log as a private interface. > Is that right?
Yes - it's private and disabled by default. > To me that seems like a poor reason to complicate > process credentials setup of the daemon, though there's nothing fatally > wrong with doing that. For a private debug logging facility I'd just > make the daemon take SIGUSR1/2 to enable/disable debug logging to > syslog, and be done. Yes, good point - and this seems like a reasonable way to go. I will make this change. > As for core dumping... > > Why should a service set its process core pattern? Why not use global > coreadm settings? That seems like an architecturally significant > detail. This is how fmd(1m) has always behaved (it sets it's core pattern to drop it's cores in /var/fm/fmd/), so there's precedence for this. From experience looking at a lot of fmd issues on customer systems, it has helped us to know where the fmd cores are going to be and to know that all of the fmd cores have been preserved and not overwritten. Based on that we'd like snmp-notify and smtp-notify to behave in a similar fashion. rob
