I've run into an issue with the installadm test suite when run on a
newly-installed server that has never had an x86 AI service set up
on it. The first test case run for 'installadm create-service' is
a negative case that provides no arguments. It expects that the
command will fail and that mdns, tftp, and dhcp services will
remain in the disabled state.
The problem I'm running into is with the status of the tftp service.
Based on the messages from the test suite, what I think is happening
is that when 'svcs -H svc:/network/tftp/udp6:default' is run the
first time (before a successful x86 service configuration), instead
of getting
disabled <timestamp> svc:/network/tftp/udp6:default
printed to stdout as we expect, nothing gets printed to stdout and:
svcs: Pattern 'svc:/network/tftp/udp6:default' doesn't match any
instances
is getting printed to stderr.
This only happens following initial installation. Once an x86 service
has been configured once, all subsequent calls to 'svcs -H' get the
'disabled' message, even following reboots. So this is a one-time
problem right after initial system installation. Unfortunately, I
expect this will bite anyone like ON-PIT who attempts to run the
suite.
Changing the order of the tests (so that a successful x86 service
configuration happens before this test gets run) isn't a full
solution as individual tests can be run standalone and therefore
still hit the problem. I can add code that will consider the
above error output to be equivalent to 'disabled' or 'offline',
but that could mask problems with the service itself.
Is there any way I could get tftp status to show up in SMF without
having created an x86 install service on the machine? If so, I
could add that to the 'startup' function to work around this issue.
Regards,
Andre
