I'm trying to debug a problem with SMF & inetd as part of the removal of in.tnamed. Basically, I can't seem to figure out why inetd still spews this message on the first reboot after an upgrade:
/var/adm/messages.0:May 12 22:45:11 surya-x4200 inetd[28174]: [ID 702911 daemon.error] Failed to update state of instance svc:/network/tname:default in repository: entity not found /var/adm/messages.0:May 12 22:45:11 surya-x4200 inetd[28174]: [ID 702911 daemon.error] Failed to update state of instance svc:/network/tname:default in repository: No such file or directory What I can't tell, is why inetd even knows about network/tname. It should be _gone_. Obviously I've missed something here, but I feel lost in a maze of twisty passages that all say "SMF this way". :-( I've posted a webrev of what I've figured out so far: http://cr.grommit.com/~gdamore/6656092/webrev/ For the record, the simple process of removing in.tnamed, instead of just requiring an update to /etc/inetd.conf and removal of the binary, has snowballed, thanks to SMF. So far I've had to update the following things: usr/src/tools/scripts/bfu.sh usr/src/pkgdefs/SUNWcsr/postinstall usr/src/cmd/svc/profile/generic_limited_net.xml usr/src/cmd/svc/prophist/prophist.SUNWcsr usr/src/cmd/cmd-inet/usr.sbin/tname.xml (removed) This is in addition to the various Makefiles and packaging files I've modified to simply reflect removal of the binary itself. If anyone can help me debug this problem, or locate the reference to tname that I've missed, I'd be very grateful. This is a major issue for snv_64 right now, so its very urgent. And, I'm seriously wondering why knowledge of in.tnamed is spread across so many files. I'd argue that this distribution of information seriously impedes maintenance, and is a design weakness in SMF. In the meantime, any advice would be really, really helpful. -- Garrett
