> You can either fail if the versions of Solaris don't
> match or you can
> postpone the commands until the root is booted.
What exactly would you designate as a Solaris version mismatch?
Solaris sparc versus Solaris i86pc?
SunOS 5.10 versus 5.11, 5.12 or 5.23?
Both of the above and some more?
Please help me understand so that I might get a perspective. I'd like to make
sure we're on the same page.
Are you implying that SMF property groups and properties and/or
mechanisms/interfaces might insufficiently change so as to be incompatible with
previous syntax and structure of SMF?
> The
> only public ways to
> do that is with an SMF service or an rc script.
OKay. init.d scripts are out of the question, even though that is the path of
the least resistance. I'm either going to be "jiggy" and "down" with that there
SMF thingy, or I'm going to be limping along in "maintenance mode" with rc
scripts.
And I don't want to limp. Since I already know how to walk, now I want to
sprint.
This does bring up an interesting issue though: how would one go about
delivering an SMF manifest that should only run once, then be removed from the
system after it ran? What would be the *cleanest* way of doing that via SMF
itself?
> 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
Does that mean I will be able to deliver
${PKG_INSTALL_ROOT}/var/svc/manifest/network/dns/server:${STOCK-SYMBOL}.xml
and won't clash with
${PKG_INSTALL_ROOT}/var/svc/manifest/network/dns/server.xml,
but still have it show up under
svc:/network/dns/server:${STOCK-SYMBOL}?
> Ok. I have filed
>
> 6509770 network/dns/server:default should have a
> a refresh method
Can you use my existing addpg and setprops for that, or will it require more
work?
Since I'm working on this right now anyways, if you tell me exactly how you
want it done and what you want me to do, I'll do the rest of the work as well,
so that the RFE can be closed?
> 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.
Yes; initially, I implemented the refresh method just for my instance, but then
I realized that /usr/sbin/named could benefit from a refresh method as well, so
I implemented it at the service rather than the instance level. It seemed
scalable to me that way.
Although, when I think about it, svc:/network/dns/server:${INSTANCE} could have
a non-BIND DNS server, which might or might not refresh his configuration by
receiving a SIGHUP.
Which means both Sun and I should implement refresh methods at instance levels,
correct? If that's so, it's too bad we have to duplicate/double the work.
> Well then a lot of SUNW manifests have bugs.
I guess so... including SUNWbindr server.xml manifest.
> 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.
That's all well, but I don't use a start method to fire up `named`. Instead, I
start, stop and refresh `named` directly via SMF, since SMF provides everything
that I need:
a) user to run as (method_context)
b) group to run as (method_context)
c) stop (:kill)
d) binary to start (exec)
e) a way to reread the configuration (refresh)
f) a way to detect whether the named.conf file is present (dependency)
Even the necessary environment variables that a method might normally need can
be set.
So the way I see it, a separate method is in this case redundant. I believe
that a method would only be needed when some preprocessing must occur before a
service instance is started.
> 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.
By "teaching" you mean modifying the `svccfg` source code and hardcoding
etc/svc/repository.db in it?
> If you're installing onto a dead root, using the
> repository command is
> ok, as long as the versions of Solaris match.
Hmmm... I can check whether PKG_INSTALL_ROOT is either undefined/empty or set
to "/"; if none of these holds, then I could execute the repository command,
else I just proceed without the repository directive.
Now, if I implement all of these, how close would you say that my
implementation is to being clean and Sun-compliant?
> > > 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.
Implemented.
> 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.
To test your theory, I created a special revision of the "${STOCK-SYMBOL}named"
package, which did not contain the "repository" directive and the SIGTERM to
svc.configd portion of the code, but instead calls `svcadm refresh
svc:/network/dns/server:${STOCK-SYMBOL}`, then executes `svcadm enable
svc:/network/dns/server:${STOCK-SYMBOL}`, and here is what SMF had to say:
root at host /tmp> svcs -a | grep dns
disabled 10:18:39 svc:/network/dns/client:default
disabled 10:18:40 svc:/network/dns/server:default
maintenance 0:22:10 svc:/network/dns/server:abcd
root at host /tmp> svcs -xv
svc:/network/dns/server:abcd (ABCD BIND DNS server)
State: maintenance since Fri Jan 05 00:22:10 2007
Reason: Start method failed repeatedly, last exited with status 1.
See: http://sun.com/msg/SMF-8000-KS
See: man -M /opt/scfw/share/man -s 8 named
See: /var/svc/log/network-dns-server:abcd.log
Impact: This service is not running.
root at host /tmp> tail -f /var/svc/log/network-dns-server:abcd.log
[ Jan 5 00:22:09 Executing start method ("/opt/abcd/sbin/named -4") ]
[ Jan 5 00:22:10 Method "start" exited with status 1 ]
which is simply false, since when `svc.configd` receives a SIGTERM and is
subsequently restarted by `svc.startd`, everything works as it should. The
only thing I could think of why the above didn't work as expected is that I did
not properly "alert" `svc.configd` to the additions and modifications that were
performed. Could that be the cause? If so, what is the correct way?
> 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.
Whatever the $SVCCFG_REPOSITORY environment variable is supposed to do, the
(in)correct usage of this variable, or the variable itself for that matter, is
not documented in either the `svc.configd` or the `svccfg` manual pages. In
fact, those pages are pretty spartan on details.
Please explain how $SVCCFG_REPOSITORY works, and how I should or should not be
using it.
This message posted from opensolaris.org
