On Jan 5, 2011, at 6:14 PM, LuKreme wrote: > On 3-Jan-2011, at 15:08, LuKreme wrote: >> >> It's not back yet, but I will not be sure until I reboot, and I can't do >> that for at least another day. Even then, 10.6.6 may re-enable it for me. > > > So, I tried to unload the service before my last reboot, but only got an > error: > > # launchctl unload -w > /System/Library/LaunchDaemons/org.dovecot.dovecotd.plist > launchctl: Error unloading: org.dovecot.dovecotd > > And the service was back after the reboot, spawning and dying every 10-11 > seconds.
Then if you got an error the unload didn't occur. Hence you should have expected it would be back after a reboot too. > After the reboot, I unloaded (with a -w flag) without an error. I'm planning > on rebooting once my current rsnapshot process finishes backing up my remote > server (I'm removing a couple of kexts), so we'll see if it comes back this > time. Did you get an error? If you do things the right way and don't get errors they work. > I am curious where "elsewhere on-disk" is, and why: > > -w Overrides the Disabled key and sets it to true. In previous > versions, > this option would modify the configuration file. Now the state of the > Disabled key is stored elsewhere on-disk. > > When did the behaviour change to ignore the plist's Disabled flag? You're making invalid presumptions and hence you're woolly thinking. There is no behavior change. The value in the plist was just always a marked and not an indicator of current status. This has been further made obvious in 10.6 and is being handled now with a database. See, it's not that it's ignoring the Disabled flag in the plist, it's just not that this is supposed to actually disable the launchdaemon in Snow Leopard and beyond. It didn't really before either, since the plist could change without the task management changing then either. Again, if you'd read how launchd is supposed to operate (as I suggested in my last email) you'll see that the plist value is just stored here as a marker. The "elsewhere on disk" are a series of databases depending on the realm we're talking about. If you were to have used dtrace and execute the `launchctl unload` you'd have seen that these databases are currently stored in /var/db/launchd.db/ and are maintained there for each user and for the system. This methodology is a big improvement on the prior handling of tasks where we didn't have a repository and launchd had to very inefficiently scan plists when launching things and try and use in memory tables for current state. This led to situations where something could be marked one way and operating differently. Remember, launchd has been for sometime the replacement for initd (and the first process started) as well as concepts like tcpwrappers, xinetd, indetd, ... Based on your other previous comments I'd strongly suggest you read the docs on how OS X Server operates, how to enable and manage services, and the technotes on launchdaemons. It sounds like you'll want to assure SACLs are enabled and ipfw rules exist for the sort of policies you're presuming. -d ------------------------------------------------------------------------ Dan Shoop [email protected] GoogleVoice: 1-646-402-5293 aim: iWiring twitter: @colonelmode _______________________________________________ MacOSX-admin mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-admin
