With Mac OS X 10.5.8 and 10.6.x, Mac OS X Server, Xsan, Final Cut Server and a number of other serialized products were switched to a whole new solution for managing serial numbers: a newly redone serialnumberd. If you run otool against serialnumberd in 10.5.7 and below you’ll notice no dependencies; it stood alone so to speak. If you run otool against the latest and greatest then you’ll notice that it has a number of dependencies that run the gambit of otherwise unthinkable services. This caused minor growing pains during the summer with multihomed network connections, maximum number of clients and other aspects of servers with certain solutions, but that got ironed out quickly with the 10.5.8v1.1 and 10.6.1.
But there have been some minor issues I’ve seen still, mostly due to installer packages not holistically cleaning up old artifacts with regards to daemons that manage serial numbers (likely due to their author being concerned about the potential for other services to have dependencies on them). This is a problem that seems to manifest itself more frequently if you are running both Mac OS X Server and Xsan on the same host (which is basically all metadata controllers, etc) and have upgraded from Xsan 1.x to 2.x and potentially upgraded from Mac OS X 10.4.x to 10.5.x and ultimately to 10.6.x.
The /System/Library/StartupItems/SerialNumberSupport StartupItem initially invoked the SerialNumberSupport daemon. However, that’s no longer needed for any product that I’m aware of. Therefore, you can stop it using the SystemStarter command and telling it to ‘stop SerialNumberSupport’:
SystemStarter stop SerialNumberSupport
SerialNumberSupport overall is deprecated and so if stopping it does not cause any adverse effects but does resolve some form of volume issues you might be having with your Xsan then you can also move it off somewhere that it can’t be overly troublesome, like your desktop:
mv /SystemLibrary/StartupItems/SerialNumberSupport ~/Desktop/SerialNumberSupport.OLD
Additionally, since serialnumberd is invoked by com.apple.serialnumberd.plist in /System/Library/LaunchDaemons then in many cases you do not need the /System/Library/LaunchDaemons/com.apple.SNServer.plist. If it is loaded and you are still having problems then try unloading it using launchctl. If your problems are gone then so should the SNServer, so consider moving it using:
mv /System/Library/LaunchDaemons/com.apple.SNServer.plist ~/Desktop/com.apple.SNServer.plist.OLD
These artifacts are likely left behind for a reason. So before you go removing them, check that a temporary stop of them resolves issues without adversely effecting other services. There is a good reason that not everything gets removed, although sometimes they can have unintended consequences…
