Quoth UNIX admin on Wed, Jan 03, 2007 at 04:21:25PM -0800:
> > > cat << _EOF_ | svccfg
> > > repository ${PKG_INSTALL_ROOT}${REPOSITORY}
> >
> > This may break if you're trying to manipulate a
> > repository with
> > a different version of Solaris.
>
> What do you propose to do if the package is added to a diskless
> client, autoclient or after a JumpStart install with `pkgadd -R`?
You can either fail if the versions of Solaris don't match or you can
postpone the commands until the root is booted. The only public ways to
do that is with an SMF service or an rc script.
That said, we could make it easier for you to deliver your service as
a manifest by moving our network/dns/server's properties into the
dns/server:default instance. To that end I have filed
6509773 network/dns/server:default should not deliver any
service-level properties
> > Why do you need to add a refresh method to the service?
>
> What you are seeing here is only a small piece of the whole mosaic.
> I am also adding DNS configuration packages, which contain
> preconfigured named.conf payload, in modules. So after I add
> a configuration package or packages, I call `svcadm refresh
> svc:/network/dns/server:${STOCK-SYMBOL}`, which sends a SIGHUP to
> `named`. This causes `named` to reread his configuration.
>
> This should really be filed as an RFE for the SUNWbindr package, as
> the manifest should implement a refresh method, as described above.
Ok. I have filed
6509770 network/dns/server:default should have a refresh method
In this case, note that you could add your refresh method to your
instance, rather than the service, unless you need the default instance
to have the refresh method, too.
...
> > We discourage file dependencies because we don't
> > receive notifications
> > if the filesystem is mounted. It would be better to
> > check for the file
> > in your start script and fail the method if it
> > doesn't exist.
>
> I'm confused. A lot of SUNW manifests have file dependencies.
Well then a lot of SUNW manifests have bugs.
> If the method is failed, how will SMF know what went wrong? However,
> when I define "named.conf" as a dependency, SMF can complain that the
> service didn't start because "named.conf" is missing.
SMF won't, but just as with any other failure, your start method should
echo an explanation, like "configuration file X is missing", before it
exits with a nonzero status. The message will end up in the log file
and the administrator will be directed to it when he runs svcs -x on
your service, which will be in maintenance.
> > Mmm, if this is live, then it would be better to
> > modify the system
> > repository (by omitting the repository command to
> > svccfg) than doing
> > this.
>
> It is not yet live; it's undergoing testing and optimization right
> now. Again, how do you propose I deal with the `pkgadd -R
> /export/client1` issue?
By "live" I mean "pkgadd'ed onto the live system". If you use the
repository command to modify /etc/svc/repository.db then svccfg will
modify the file under the system's svc.configd's feet and problems will
ensue. If we taught svccfg where the system repository is, svccfg could
avoid this.
If you're installing onto a dead root, using the repository command is
ok, as long as the versions of Solaris match.
> > It would be better to use "svcprop -c -p
> > restarter/state" here.
>
> If that is a viable alternative, it shall be implemented.
Well it's more stable.
> > > #
> > > # Finally, refresh svc.configd.
> > > #
> > > pkill -TERM svc.configd
> >
> > This should not be necessary.
>
> It shouldn't, but it is. When I add the pgs and props from my original
> post, then end, the service instance does not show up when doing
> `svcadm refresh svc:/network/dns (or
> svc:/network/dns/server:${STOCK-SYMBOL} for that matter); svcs -a
> | grep dns`; but it does show up after svc.configd receives a SIGTERM
> and is consequently restarted by `svc.startd`!
>
> Maybe a bug?
Those are the symptoms of using svccfg repository or $SVCCFG_REPOSITORY
to modify /etc/svc/repository.db under the system's svc.configd's feet.
Therefore killing svc.configd would be necessary if you had done one of
those things. Except it might result in data loss, so you should avoid
doing those things.
This comment in particular was made against the preremove script, where
I didn't see SVCCFG_REPOSITORY being set. Without it, svccfg should go
through the system's svc.configd, so killing svc.configd should not be
necessary.
David
