I recently upgraded two of my Solaris boxes to the latest Solaris 10 release and had some problems getting Samba working correctly again. Originally Samba on Solaris was started via the /etc/init.d/samba script and depended on whether the /etc/sfw/smb.conf configuration file existed. Then when the service framework came into use it was converted to a service, and you enabled it by running ‘svcadm enable samba’. All pretty straightforward so far.
In current Solaris releases there is a subtle change that may not be immediately obvious. For most Samba configurations you have two daemon processes running, smbd and nmbd. smbd is what actually does the file serving. If you only have smbd running you can still access files but you need to manually enter the filesystem path to get there. nmbd provides the netbios/wins service which is what announces on the LAN that the computer is part of a workgroup and what its name is. This is the piece that allows you to go to “My Network Places” or “View Workgroup Computers” and have stuff just automatically appear.
The change in the current Solaris versions is that while both daemons were controlled together in the past, they are now controlled as separate services. So now if you just do ‘svcadm enable samba’ it turns on only smbd and you only get file sharing that you can manually access. If you go to “My Network Places” or “View Workgroup Computers” you won’t see anything from that server. To enable nmbd also you need to also run ‘svcadm enable wins’.
Why would they do things this way? In more advanced network configurations you may have a domain controller that performs the netbios/wins functions. In that environment, separately running nmbd on a standalone server could cause confusion. Others may not want to run it because they don’t want an intruder to be able to easily discover shared filesystems. In any case, for most simple LAN based file service implementations, such as a home or small office network, you would probably want to run both services.
as my association with solaris ended while /etc/init.d/foo start was still in vogue i’m curious why the switch to the seemingly no different ‘svcadm enable foo’. being the luddite i am, i’d probably have an /etc/init.d/samba script that calls svcadm. assuming they haven’t nuked /etc/init.d altogether.
/etc/init.d/ still exists, and you can still start services that way. You aren’t exactly understanding how services work though. If you run ‘svcadm enable’ on a service then the service will start up automatically any time the system is booted. If you ‘svcadm disable’ something then it will not run even if you reboot. This is opposed to init.d scripts which start up on boot and the only way to disable them is to remove the links in rc?.d.
Also as opposed to init.d, services are monitored and are automatically restarted by the service monitor if they fail for some reason. With something in init.d if it fails for some reason it will remain offline until an admin restarts it or reboots.
Another advantage is that while init.d scripts are executed sequentially, services are started based on when their dependencies are satisfied. With init.d each script needs to wait until the previous script finishes before it can start and dependencies are handled by putting scripts in an appropriate sequence. With that method it can take quite a while to boot even though resources aren’t fully utilized. With services each service is started as soon as it is able to based on dependencies, and so several services can be starting up simultaneously and bootup is much faster. If something depends on another service starting then it only needs to wait for that service to start, it doesn’t have to wait for a dozen other unrelated service to wind their way through their startup scripts.
init.d scripts were an improvement over dumping everything in /etc/rc.local, and now services take things to the next level and improves performance, efficiency and reliability in the process.
so my next question is, how hard is it to write applications that interface properly with svcadm? for init.d scripts it was a cinch, just support the stop and start arguments and you’re done. sounds like svcadm has more complex requirements. where does it get its dependency information, etc.?
Service support is set up via an XML file describing the start and stop methods, and optionally other methods such as reload, etc. You can also specify what services or run level the service depends on and how to monitor if the service is alive. For a basic service supporting stop and start and monitoring via whether the process is still running is pretty easy; it’s just different.
By the way, the service monitor also replaces inetd as well so you can have similar semantics for those types of network services as well.
thank you for the clear and informative explanations.