its friday, its 19:28 , its home time!
By timatworkhomeandinbetween on Apr 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
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..
In Between.15 miles in the smart, it was snowing and sleeting at 2 degrees centigrade this morning!
0 miles on the bike, no excuse unlike chrisg.