This page validates as XHTML 1.0, and will look much better in a browser that supports web standards, but it is accessible to any browser or Internet device. It was created using techniques detailed at glish.com/css/.
Friday April 08, 2005 Helped one child with a model volcano, its got a chamber full of sodium bicarbonate and a squeezy bottle of vinagar built in - should make his science project go with a fizz. Had my curry a day early as I was out and about shopping last night. I tend to go to the Gulshan, in Farnham as the food is very good, just spiced how I like it. I usually take one of the children as it is a good time to sit and talk whilst we wait for it to cook.
Our Ford Galaxy car insurance is due and the current insurer wanted
about 700 pounds for a year, so I used the internet and got several
quotes for half that amount, the cover and excesses seemed similar
so I picked one, so it pays to shop around, beat the lethargy.
One lingering escalation I have involves clustered machines
intermitently producing "devfsadmd not responding" messages in
/var/adm/messages. Syseventd is a really useful but little known
collection of code. It handles events from the kernel and farms them
out to modules that have registered interest. It is written in a way
using theads/doors and event queues to avoid a client module being able
to hang the man thread. There are four modules that are loaded
from /usr/lib/sysevent/modules.
picl_slm.so - to handle sending events to picld, This registers to get passed EC_DEVFS/EC_DR events so it can respond to changes in /devices land.
sysevent_conf_mod.so - This is the user extensible part. The
module looks in /etc/sysevent/config for files that end
",sysevent.conf". It expects them to have a format that describes a
program to invoke when incoming events from the kernel match some
tokens. The README in that directory has some hints. Several
software manufactures use this to allow their software to be poked when
something changes in /devices land so they can see what changed.
Solaris 10 introduces syseventadm to mange these config files and the
man page describes the tokens.
sysevent_reg_mod.so - this module supplies the infrastructure
for other programs to register themselves as event consumers using
libsysevent, posting events goes via the kernel. This is my current
suspect..
devfsadmd_mod.so - this module gets events from the syseventd
core but only wants EC_DEVFS type events. Each event gets sent through
a door to devfsadmd, if there are problems then it forks and execs
devfsadmd. So that is how devfsadmd gets started!
In this escalation there is a problem contacting devfsadmd so we
start a new one only to discover that the old one is still there.
The code loops a couple of times trying this before producing..
"/devices or /dev may not be current (devfsadmd not responding) Run
devfsadm". What I need is a testcase that leads to the devfsadmd_mod
deciding that no one has subscribed to EC_DEVFS events so not sending
the event. Any suggestions gratefully accepted..