# Dave Zarzycki's incomplete brain dump on system startup, mobility and merging similar daemons in to "the anti-kernel"

Mobility and performance are hot topic at Apple. Both mean many things to many people. Both ideas can be related at some level. I believe the important undercurrent of ideas is as follows:

- Detect and cope with the world changing around you. (Mobility)
- Be lazy. "Why do today what you can put off till tomorrow." (Mobility and Performance)
- Use less resources (a side effect of being lazy) (Performance)
- ...???...

The master tracking bug I filed for these issues is 3190635.

So as the owner of SystemStarter and as a natural consequence, responsibility for the care and feeding of our boot up proceedure, what do I see the problems and solutions as?

First and foremost, we must switch from a boot-up model where loginwindow launches "as soon as everybody should be able to login" to where loginwindow launches "as soon as anybody can login." Ideally, this is as soon as the boot volume becomes mounted read/write. This requires changes between loginwindow and it's dependencies.

1. loginwindow needs to register for a call back for when "directory" infrastructure changes, comes or goes. This will partially decouple loginwindow from needing "the network" to be up before launching. See 3101359.
2. The other half will involve cooperation from the file system team and loginwindow. Before logging in a user, loginwindow will need to verify that the user's home directory is mounted/mountable, and if not, let the user know that they cannot finish logging in until a disk is done being fscked or an NFS server/export comes online.

So the user-land boot-up model that we should be moving towards looks something like this:

1. Run the anti-kernel
2. get the disk fscked and mounted read/write
3. Register all services (lazy or not) with the anti-kernel
4. Launch the WindowServer and loginwindow
5. Launch non servicy startup-items and other "at boot" items (if any) in the background

So what is this anti-kernel? At the end of this web page is a huge table of nearly all of the daemons on our system. I tried to summarize their mobility/lazy launch situation. What you'll see if you look closely at many of the daemons is that they support or could easily support launching lazily/on-demand. Each does it different daemons due to the different mechanisms that they use.

- Mach based services use mach_init.
- gettys use init(8).
- TCP/UDP based services use [x]inetd.
- Some services launch out of cron.
- A mach_init/xinetd for IOKit devices is sorely needed after looking at many daemons at Apple.
- AF_UNIX domain socket based services currently lack something like mach_init/xinetd for lazy launching of them.

What has become really obvious to me is that init, mach_init, xinetd, cron, atd, configd, kextd, SystemStarter, watchdog and friends are very similar. They are top level daemons that take specific kinds of events and then schedule code or commands to run based on limted events/rules. I think a unifed tool/daemon is begging to be born. The anti-kernel I envision will be expected to source just about every event possible coming out of the kernel and provide a language for scheduling/triggering commands/jobs to run when a condition is satisfied. So for example, cron functionality could be used in combination with changing my configuration with configd style functionality. Or tools that listen on multiple event sources like mDNSResponder (mach and TCP/IP) can finally be launched lazily from what daemon. If this daemon is well written it could be used by users to lazily launch programs like the ssh-agent, SecurityAgent or iChatAgent.app. It could also schedule iCal to launch at certain times while the user is logged in. There are plenty of other examples where this could be useful to the user in addition to the system itself.

At the very least, I think Apple should experiment with what this kind of daemon might allow for us to do.

Interesting mobility/laziness support bugs are as follows:

- 3101359 notify automounter that search policy changed
- 3173430 systemstarter support for bootstrap_create_server
- 3190357 Loginwindow should run a tool to register mach bootstrap services in the sub namespace
- ...more to come...

Interesting "be lazy" bugs are as follows:

- 2573924 The afp server should run out of xinetd (at least on Mac OS X client)
- 3186400 The cupsd server should run out of xinetd
- 3186570 slapd should run out of xinetd
- 3187905 coreservicesd should install this mach_init related plist file to launch at boot lazily
- 3187906 distnoted should install this mach_init related plist file to launch at boot lazily
- 3187912 fix_prebinding should install this mach_init related plist file to launch at boot lazily
- 3189625 DirectoryService should install this mach_init related plist file to launch at boot lazily
- 3190281 lookupd should install this mach_init related plist file to launch at boot lazily
- 3190356 URLMount should install this mach_init related plist file to launch at login lazily
- 3190596 ATSServer should install this mach_init related plist file to launch at boot lazily
- ...more to come...

# The anti-kernel per daemon investigation:

(We should start tracking mobility bugs against specific daemons and tools too.)

## System Wide Services
Daemon: | Short summary: | The big picture summary:
ATSServer | The font server (xfs for Unix heads) | This could be launched lazily via mach_init.
DirectoryService | lookupd rewritten | This could be launched lazily via mach_init.
SecurityServer | Trusted half of the security framework | This could be launched lazily via mach_init, but currently today, they manage /dev/random entropy, which is a layering violation.
AppleFileServer | AFP server | This could be launched lazily via xinetd, some changes to xinetd would be needed, but nothing major.
SharedIP | kext to share an IP with Classic | This is loaded at boot today. The kernel should request this get loaded on demand when somebody (Classic) requests an PF_NDRV socket.
IPFirewall | ipfw support code | If we're always going to load it, why not compile it in? (it was more work to take it out of the kernel...)
OpenAFS | AFS Servers | This needs more investigation, but in the short to mid term, this is probably best left as a startup item. There is little to be gained by making this lauch lazily.
OpenLDAP | LDAP servers | This could run out of xinetd.
SystemStarter | runs startup items | SystemStarter does too much today. Once loginwindow gets mobility aware, SystemStarter can get out of the GUI business. Once more services lauch themselves lazily via various mechanisms like mach_init or xinetd, SystemStarter will slowly get off the critical path for boot-up. This kind of functionality should be merged in to the anti-kernel.
amd | am-utils automounter | This needs more investigation, but in the short to mid term, this is probably best left as a startup item. There is little to be gained by making this lauch lazily.
atd | batch job scheduler | This should be merged with cron, init, mach_init and friends to form the super-job schedular.
cron | periodic job scheduler | This should be merged with atd, init, mach_init and friends to form the super-job schedular.
init | reaps processes and launches ttys | This should be merged with cron, atd, mach_init and friends to form the super-job schedular.
mach_init | mananges the Mach bootstrap namespace | In addition to managing the Mach bootstrap name space, it launches mach based services lazily like [x]inetd. This should be merged with cron, atd, init and friends to form the super-job schedular.
autodiskmount | Finds, fscks and mounts disks | This could be launched via mach_init (not lazily until we have a device based trigger mechanism that should evolve in the anti-kernel).
automount | Apple's NFS automounter | This needs more investigation, but in the short to mid term, this is probably best left as a startup item. There is little to be gained by making this lauch lazily.
configd | All things config | Historically called ipconfigd, these days it manages other configuration details than just networking. This is arguably one of the more modern daemons in the system, and the closest thing we have to the "anti-kernel" in the system. But I believe it is fair to say that configd wasn't designed with becoming the anti-kernel goal in mind.
blued | Bluetooth | The bluetooth daemon wants is just the start of various to come that want to be launched on demand when hardware shows up. Today, blued launches on demand, but never exits after the hardware goes away. Anecdotal evidence suggests that the daemon is automatically launched after a reboot if a bluetooth device was ever attached.
bootparamd | boot paramater server | This should run out of xinetd.
bootpd | bootpd | This should run out of xinetd.
coreservicesd | Remote AppleEvent server | Launches via xinetd in Panther.
coreservicesd | Shared Carbon app state | This will launch lazily via mach_init in Panther.
cupsd | The CUPS Printing daemon | This could run out of xinetd, but some extra work to cupsd needs to run, and some extra support needs to be added to xinetd so that individual printers can advertised via Rendezvous rather than just the CUPS daemon. This problem is much like the Apache (httpd) problem.
fix_prebinding | Prebinding fix-ups | Listens to dyld requests for prebinding fix-ups. This will/should be switching to launching lazily via mach_init in Panther.
distnoted | Carbon/AppKit notification server | This will launch lazily via mach_init in Panther.
dhcpd | DHCP server | Launches lazily via xinetd today.
fingerd | finger server | Launches lazily via xinetd today.
ftpd | FTP server | Launches lazily via xinetd today.
httpd | HTTP server | The Apache web server. This is probably the complicated daemon to make launch via [x]inetd. It is complicated by the fact that many of the Apache developers do not want to support running out of an inetd. This problem is much like the cupsd problem.
dynamic_pager | manages swap files | this could be merged in to the anti-kernel, but after talking with some of the Mach kernel engineers, it would add some restrictions to the anti-kernel design.
crashreporterd | listens for mach exceptions and logs crashes | This could be merged with the anti-kernel. Processing mach exceptions can be thought of like init(8) reaping processes via the wait family of system calls.
getty | login tty helper | launched via init(8) today, it isn't worth being launched lazily.
identd | ident server | Launches lazily via xinetd today.
imapd | IMAP server | Launches lazily via xinetd today.
kadmind | Kerberos admin server | This could launch lazily via xinetd.
kdcd | Kerberos Domain Controller server |
kpropd | Kerberos ??? server | This could probably launch lazily via xinetd.
kextd | Kernel extension daemon | This should be launched via mach_init, but since it cares about device event, it cannot be launched lazily at this time.
lookupd | Pre DirectoryService lookup cache server | This should launch lazily via mach_init.
lsregister -load | LaunchServices db helper | This should ideally be done lazily at login time and with the help of modern software package management, at install time.
irpd (bind) | lookupd by the people who brought you DNS | Not much to say here, we don't have any interest in this at the moment.
lwresd (bind) | lookupd for DNS by the people you brought you DNS | This could be handled by a xinetd/mach_init equivlent for AF_UNIX domain sockets.
mDNSResponder | Rendezvous support | This could be launched lazily vi the anti-kernel, but it would require work, and given that it would need to run almost all the time, there would be little value in lazily launching it.
named | DNS server | This could be launched lazily via xinetd.
hwmond | hardware monitoring daemon | More investigation is needed, but one would hope the anti-kernel's trigger hooks would be flexable enough to launch this on demand.
hlfsd | am-utils home-link file system daemon | This needs more investigation, but in the short to mid term, this is probably best left as a startup item. We don't know of anybody who uses this daemon.
loginwindow | GUI login daemon | loginwindow in theory is fine. It launches on demand from init(8). The only problem is that random groups at Apple have used loginwindow as a home for random hunks of code that have nothing to do with logging users in.
natd | BSD NAT daemon | "...it comes into play when a user turns on the Internet Sharing feature in the Sharing pref pane. Clicking "Start" launches a process called InternetSharing (built by the InternetSharingSupport project in cvs) and this is the policy program that starts natd, enables ip forwarding, starts the dhcp server, etc etc. The InternetSharing process actually continues to run as long as Internet Sharing is enabled so that it may listen for config change notifications from configd and take action if necessary." -- Matt Scopp
netinfod -s local | The local NetInfo domain | This could be launched on demand via xinetd.
mountd, nfsd, nfsiod, rpc.lockd, rpc.statd | NFS servers | These are conditionally launched today if we export NFS volumes, but it would be nice if the NFS startup-item code was unified with some existing or new lazy launch mechanism.
portmap | Sun RPC name to port mapper | This, like mDNSResponder maps names to addresses/ports. xinetd can also map names to ports via the historic tcpmux port. It would be nice to unify these.
nibindd | The portmap for netinfod | NetInfo is going away. I'm not sure how much we care about this in the long run.
nmbd (samba) | Rendezvous/DynDNS for NetBIOS | This, like mDNSResponder maps names to addresses/ports. This is owned by the samba world. Not likely that we can make it launch lazily or be merged with some other daemon.
smbd (samba) | SMB file server | This should switch to launching lazily via xinetd.
ntpd | NTP client/server | This needs to be running all of the time to detect and fix clock drift in the machine that you're on. If we just care about fixing the time and we don't care about fixing drift, we can run the ntpdate command out of cron.
panicdump | Records a panic dump to disk | This is not really a daemon, but something launched at boot. This information wants to be extracted as soon as possible and logged, but I'm not sure where a good home for it is.
pcscd | PC/SC Smartcard daemon | This could be launched lazily, but it needs an AF_UNIX equivlent for xinetd or mach_init.
pop3d | POP3 server | This launches lazily via xinetd today.
pppd | PPP client/server | This launches lazily today via a variety of mechanisms.
routed | RIP routing daemon | This should probably be launched lazily via configd given the right networking configuration.
rpc.yppasswdd, ypbind, ypserv | NIS daemons | I'm not sure what to do about these and I'm not sure how much we care. NIS is dead. Long live LDAP. The servers can be launched out of xinetd. We'd need to figure out a way to trigger the client daemon to launch lazily.
rsyncd | rsync daemon | This can lauch lazily via xinetd today.
rtadvd | Router advertisement daemon | This could be launched lazily via xinetd.
rtsold | Router solicitation daemon | This should probably be a configd plug-in or launched lazily via configd.
saslauthd | SASL daemon ("password server") | This could be launched lazily, but it needs an AF_UNIX equivlent for xinetd or mach_init.
sendmail | Apple's MTA for today | Launching this lazily will require some work due to the mail queue on disk might need flushing at boot.
syslogd | syslog server | Launching this lazily will require some small amount of work do the the kernel's syslog interface.
sshd | ssh server | Launched lazily via xinetd today.
talk | talk server | Launched lazily via xinetd today.
tftpd | tftp server | Launched lazily via xinetd today.
tim | legacy cleartext password server | This could be launched lazily via xinetd.
timed | time server daemon | already runs via xinetd today
update | while (1) {sync(); sleep(30);} | This should just be absorbed in to the anti-kernel.
vsdbutil | Manages db of known disks | Conditionally run at startup. It would be nice to find a better home for this.
watchdog | Mac OS X Server SysV style init(8) | This functionality should be merged with the anti-kernel.
xfs | X11 font server | This could be launched lazily via the anti-kernel (needs both TCP and AF_UNIX domain for lazily launching).
xinetd | Internet super server | This is our laziness enabling daemon for network servers.
servermgrd | Mac OS X Server Manager daemon | This could probably be launched lazily. More investigation is needed.
serversettingsd | Mac OS X Server ??? daemon | This could probably be launched lazily. More investigation is needed.
sambadmind | Mac OS X Server Samba admin daemon | This could probably be launched lazily. More investigation is needed.
## Per User Services
CCacheServer | The Kerberos Credentials Cache Server. | This could be launched lazily via mach_init (since the Kerberos team decided to use mach for the implementation), but it is currently launched lazily today when somebody first calls in to the Kerberos library
Dock | half-daemon/half-app | It is worth considering launching it via a standardized FBE management daemon.
InternetReminder.app | from Setup Assistant.app | This really wants to be launched on demand from the per user form of the anti-kernel.
SecurityAgent | trusted per-user program of the Security framework | Could probably be lazily launched via mach_init. 3190357 will probably help.
SystemUIServer | another misc daemon as far as I can tell | More research is needed.
Xquartz | X11 server | This could be launched lazily from the per user anti-kernel.
fetchmail | Unix e-mail download agent | This should be launched lazily/managed via the anti-kernel in it's per user form.
gnuserv | emacs agent | Could be launched lazily via the anti-kernel in it's per-user form.
hdi_agent | hard disk image agent | This is launched on demand today when somebody requests that a disk image is to be mounted.
iChatAgent.app | iChat agent | This should be launched lazily at login. 3190357 should help.
pbs | Paste Board server | Could probably be lazily launched via mach_init. 3190357 will probably help.
ssh-agent | ssh "key chain" | Listens on a AF_UNIX domain socket. Could be lazily launched.
screen | tty mux and session manager | Listens on a AF_UNIX domain socket. Could be lazily launched.
quartswm | Quartz X11 window manager | Could be launched via the anti-kernel in it's per-user form. It needs to be relaunched if it dies.
## LoginWindow plug-ins
BezelServices | F1-F5 keys | This probably shouldn't live in loginwindow. More research needs to be done.
BootCache | Final BootCache code | This tells the BootCache to stop recording disk block access and lets the BootCache begin to clean up. This code really shouldn't live in loginwindow. With the right rules/triggers this could be run from the anti-kernel.
DisplayServices |  | Similar to BezelServices. This probably shouldn't live in loginwindow. More research needs to be done. (talk to Chester Devine?)
KextHelper |  | This probably shouldn't live in loginwindow. More research needs to be done. (talk to nik gervae probably)
MCX |  | This for managed servers. If so it writes out certain prefercences. This probably shouldn't live in loginwindow. More research needs to be done. (talk to Rob Neville)
SystemSoundServer |  | Like the window server but for simple sound clients. This probably shouldn't live in loginwindow. More research needs to be done.
URLMountUIProxy |  | This exists only so that it can get registered in the per-user mach sub bootstrap port. This shouldn't live in loginwindow. See 3190356.
## configd plug-ins
ATconfig | AppleTalk config mgmt | AppleTalk config mgmt (appropriate use of configd)
Apple80211Monitor | AirPort support | AirPort config mgmt (appropriate use of configd)
Bluetooth | Bluetooth support | starts blued once a bluetooth dongle is attached and keep it alive forever (inappropriate use of configd)
DynamicPowerStep | CPU clock down support | This will probably move to the kernel in the future from what I hear.
IPConfiguration | DHCP and IP config mgmt | appropriate use of configd
IPv6Configuration | DHCPv6 and IPv6 config mgmt | appropriate use of configd
IPMonitor | companion to IPConfiguration | manages default route and resolver configuration, proxies etc. (appropriate use of configd)
InterfaceNamer | maps Unix to IOKit devices | This maps the Unix device names to IOKit devices (appropriate use of configd)
EAPOL | 802.1x support | Authenticantion at the Ethernet layer (appropriate use of configd)
KernelEventMonitor | Watches NKE event socket | (appropriate use of configd)
KernelNotifications | KUNC support | Kernel User Notification Center (half should move to kextd, half should move to SystemUIServer)
Kicker | configd helper | Helper for kicking components who are not SystemConfiguration aware.
LinkConfiguration | network device configuration | Manages "layer 2" device configuration (appropriate use of configd)
PPPController | PPP | Manages running pppd with the right parameters (appropriate use of configd)
PowerManagement | Some Power Management code | This code could really live in about any daemon.
PreferencesMonitor | watches for pref file changes | This brings networking config files in to effect (appropriate use of configd)
PrinterNotifications | USB printer support | Like blued (inappropriate use of configd)
USBUPSSupport | Watches for USB UPS devices | Like blued (inappropriate use of configd)

    $Id: daemon-investigation.html,v 1.1.1.1 2003/11/13 19:18:00 zarzycki Exp $