svc doesn't stay enabled
Frank Cusack
I wrote a custom service manifest, which seems to work except that the
service does not stay enabled across reboot. svcs -x always claims
disabled by admin. help!
i knew svc would be like sac
-frank
Gary Mills
>Let's try this again. See my other post 'svc manifest import problem'.
>I wrote a custom service manifest, which seems to work except that the
>service does not stay enabled across reboot. svcs -x always claims
>disabled by admin. help!
This behavior is often caused by the service running too early in
the boot, before some of its resources are available. You may need
to add another dependancy or two. Check with `svcs -l ...' to find
the per-service log file. It might explain why the service fails
during the boot.
--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
Frank Cusack
> In <m2ody5d...@maguro.local> Frank Cusack <fcu...@fcusack.com> writes:
>
>>Let's try this again. See my other post 'svc manifest import problem'.
>>I wrote a custom service manifest, which seems to work except that the
>>service does not stay enabled across reboot. svcs -x always claims
>>disabled by admin. help!
>
> This behavior is often caused by the service running too early in
> the boot, before some of its resources are available. You may need
> to add another dependancy or two. Check with `svcs -l ...' to find
> the per-service log file. It might explain why the service fails
> during the boot.
The log file is completely uninteresting. svcs -l is nearly identical
to the Sun SUNWbind package (dns/server), which does stay enabled:
[root@test:~]# svcs -l dns/server
fmri svc:/network/dns/server:default
enabled false
state disabled
next_state none
state_time Wed May 10 16:24:53 2006
restarter svc:/system/svc/restarter:default
dependency require_all/none file://localhost/etc/named.conf (online)
dependency require_all/none svc:/system/filesystem/minimal (online)
dependency require_any/error svc:/network/loopback (online)
dependency optional_all/error svc:/milestone/network (online)
[root@test:~]# svcs -l dns/named
fmri svc:/site/foo/network/dns/named:default
name BIND DNS server
enabled false
state disabled
next_state none
state_time Wed May 10 16:24:53 2006
restarter svc:/system/svc/restarter:default
dependency require_all/none file://localhost/etc/named.conf (online)
dependency require_all/none svc:/system/filesystem/minimal (online)
dependency require_any/error svc:/network/loopback (online)
dependency optional_all/error svc:/milestone/network (online)
[root@test:~]#
The only differeence is that Sun's package doesn't show the name for
some reason. (The above shows both disabled but that was just after
install. Once I enable dns/server it sticks.)
In fact if I copy the manifest exactly from SUNWbindr, changing only
the path, my named still stays disabled. It seems it's not a problem
with the manifest per se.
So why would smf think my named should stay disabled?
-frank
Gary Mills
>On Wed, 10 May 2006 19:31:31 +0000 (UTC) Gary Mills <mi...@cc.umanitoba.ca> wrote:
>> In <m2ody5d...@maguro.local> Frank Cusack <fcu...@fcusack.com> writes:
>>
>>>Let's try this again. See my other post 'svc manifest import problem'.
>>>I wrote a custom service manifest, which seems to work except that the
>>>service does not stay enabled across reboot. svcs -x always claims
>>>disabled by admin. help!
>>
>> This behavior is often caused by the service running too early in
>> the boot, before some of its resources are available.
>The only differeence is that Sun's package doesn't show the name for
>some reason. (The above shows both disabled but that was just after
>install. Once I enable dns/server it sticks.)
>In fact if I copy the manifest exactly from SUNWbindr, changing only
>the path, my named still stays disabled. It seems it's not a problem
>with the manifest per se.
Then, it has to be the service name. Do you have a site.xml file
in /var/svc/profile that disables the service? Can you give your
service a more distinctive name? Maybe it's matching a partially-
qualified FMRI someplace.
Frank Cusack
No site.xml. I tried something else, I changed the start method in
the Sun dns/server manifest to start my named instead of Sun's (and
reimported the manifest). So I'm using the Sun manifest, with the Sun
fmri, which works with Sun's named, but *mine* still doesn't stay
enabled.
I now see that if I do 'pkill named' against the Sun named, the
restarter restarts it. If I kill my named, the restarter doesn't
do anything.
Log for Sun named:
[ May 10 20:55:33 Executing start method ("/usr/sbin/named") ]
[ May 10 20:55:33 Method "start" exited with status 0 ]
... pkill ...
[ May 10 20:56:58 Stopping because all processes in service exited. ]
[ May 10 20:56:58 Executing stop method (:kill) ]
[ May 10 20:56:58 Executing start method ("/usr/sbin/named") ]
[ May 10 20:56:58 Method "start" exited with status 0 ]
Log for my named:
[ May 10 21:02:09 Executing start method ("/usr/local/sbin/named") ]
[ May 10 21:02:10 Method "start" exited with status 0 ]
... pkill ...
[ May 10 21:02:21 Stopping because service disabled. ]
[ May 10 21:02:21 Executing stop method (:kill) ]
and that's it.
Interesting, the difference between why smf thinks the service went down.
Does a process have to be contract-aware to properly use the smf restarter?
I thought the start method would create a new contract and that would be
enough. svcs -l certainly reports a unique contract id, which
'pgrep -c named' agrees with. I think I'm barking up the wrong tree
there but I'm running out of guesses.
-frank
Frank Cusack
More data: I thought maybe they exit differently but it seems the same:
[root@test:~]# truss -t exit -f /usr/sbin/named
16000: _exit(0)
16001/1: Received signal #15, SIGTERM, in sigtimedwait() [default]
16001/1: siginfo: SIGTERM pid=16003 uid=0
16001: _exit(0)
[root@test:~]# truss -t exit -f /usr/local/sbin/named
16005: _exit(0)
16006/1: Received signal #15, SIGTERM, in sigtimedwait() [default]
16006/1: siginfo: SIGTERM pid=16008 uid=0
16006: _exit(0)
[root@test:~]#
-frank
Frank Cusack
named is too smart for it's own good; it knows about smf and on exit
it disables itself. This almost makes sense if 'rndc stop' were used
to halt the server, but named doesn't distinguish between smf stopping
the server (in which case it should let smf handle the state) or rndc
doing it.
I say almost, because the only argument I can see is that you might
want rndc stop to act like it does on an init.d system, ie named won't
magically restart. In which case you need the disable to be
temporary, not permanent. But this doesn't work because
'svcadm restart' leaves the service in temporary disabled state.
I fixed it by just disabling the smf code via ./configure.
A fix that implements what the code probably is supposed to do (the
case I described above) would be to add an option to 'rndc stop'
which tells named that smf is doing the stopping and it shouldn't
mess with the state.
-frank