Jon Haslam's Weblog

Doors are an IPC facility that exist within Solaris which allow one process to execute functions within another process. A process that exports a function using the door_create() interface is termed a door server and a process that invokes this function with the door_call() interface is known as a client (suprisingly enough).

I was on the train the other day just tinkering with a few DTrace scripts that I've been developing (see Alans Blog for other DTrace train tinkering) when I happened to notice a reasonable amount of door_call() calls being made by my X server (the Xsun process). Nowadays it's really easy to see what process the door_call() is being made to as the pfiles(1) utility even tells us what process is the door server for this door. Taking a quick look at my X server we see:

# pgrep -fl Xsun
  497 /usr/openwin/bin/Xsun :0 -nobanner -defdepth 24 -auth /var/dt/A:0-PDaa9a
# pfiles 497 | grep -i door
   4: S_IFDOOR mode:0777 dev:214,0 ino:0 uid:0 gid:0 size:0
      O_RDWR  door to svc.configd[9]
  26: S_IFDOOR mode:0777 dev:214,0 ino:0 uid:0 gid:0 size:0
      O_RDWR  door to stfontserverd[695]

How spoilt we are nowadays - it's all so easy to see what is happening! However, I really want to see a systemic view a what door calls are being made so inbetween Surbiton and Waterloo I put the following simple script together:

#!/usr/sbin/dtrace -s

#pragma D option quiet

door_call:entry
{
        self->in = 1;
}

door_lookup:return
/self->in/
{
        self->called = stringof(args[1]->door_target->p_user.u_comm);
}

door_call:return
/self->in/
{
        @[execname, self->called] = count();
        self->in = 0;
        self->called = 0;
}

END
{
        printa("%s called door in %s %@d times\n", @);
}

The above script just takes advantage of the fact that we do a door_lookup() from within a door_call(). We can then extract the name of the door server from the proc structure that is stored in the struct door_node that door_lookup() returns (see sys/door.h).

# ./door.d
^C
kcfd called door in nscd 1 times
zoneadm called door in zoneadmd 1 times
devfsadm called door in devfsadm 1 times
zoneadmd called door in devfsadm 1 times
snmpd called door in nscd 2 times
sshd called door in kcfd 2 times
sshd called door in nscd 2 times
syslogd called door in nscd 2 times
syseventd called door in devfsadm 2 times
chown called door in nscd 2 times
devfsadm called door in syseventd 2 times
ttymon called door in nscd 3 times
dtlogin called door in nscd 3 times
id called door in nscd 4 times
deallocate called door in nscd 4 times
snmpXdmid called door in nscd 4 times
lpstat called door in syslogd 4 times
cron called door in nscd 5 times
svc.startd called door in nscd 6 times
inetd called door in nscd 16 times
svcprop called door in svc.configd 26 times
svccfg called door in svc.configd 54 times
rpcbind called door in svc.configd 117 times
lsvcrun called door in svc.configd 550 times
svc.configd called door in nscd 2034 times
mfstscan called door in svc.configd 2708 times
Xsun called door in stfontserverd 5046 times
svcs called door in svc.configd 7918 times
inetd called door in svc.configd 28908 times
svc.startd called door in svc.configd 37110 times

You'll have to excuse the poor formatting as it's always a weakness of mine but isn't it cool to see how easy we can see the various interactions? That's quite a few doors being opened in the smf(5) world as I was doing a bit of svcs work at the time (see Stephen Hahn's Blog for smf(5) goodness).