On Mon, Jul 26, 2010 at 11:02:45AM +0100, John Levon wrote: > On Sun, Jul 25, 2010 at 09:17:00PM -0700, Liane Praza wrote: > > > To workaround this problem this project will create a new > > directory in /etc/logadm.d and an SMF service > > svc:/system/logadm-upgrade. A pkg wanting to add entries > > in /etc/logadm.conf can drop a file with the entries in that > > directory. The start method of the service will look for > > logname for the entry, as defined in logadm.conf(4), in > > /etc/logadm.conf. If the logname is not found, the entry from > > the file will be appended to /etc/logadm.conf. The pkg dropping > > a file in /etc/logadm.d have to set the actuator > > refresh_fmri='svc:/system/logadm-upgrade:default' in order to > > have the contents of the file processed on install on a live > > BE. > > How does an uninstall remove the logadm entry? Why can't this just > process /etc/logadm.d in place (like /etc/logrotate.d on Linux) ?
I've a prototype start method for a service that essentially generalizes what this project does. Packages would deliver SVR4-style post* and CAS scripts into .d-like directories. The start method of this service scans for new such items delivered by new pkgs and saves backup copies... so it can also detect pkg removals, and then it runs the scripts for additions and removals as expected. Time to generalize this? I mean, how many *upgrade* services will we have littering the SMF service namespace? Nico -- _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
