I noticed that most of the other *socket* files in /var/run don't live in
their own directory.  Is tog-pegasus going against convention here?

Well, it looks like there are some exceptions built into rc.sysinit for this
(@ line 792):
---
# Clean up /var.  I'd use find, but /usr may not be mounted.
for afile in /var/lock/* /var/run/* ; do
        if [ -d "$afile" ]; then
           case "$afile" in
                */news|*/mon)   ;;
                */sudo)         rm -f $afile/*/* ;;
                */vmware)       rm -rf $afile/*/* ;;
                */samba)        rm -rf $afile/*/* ;;
                *)              rm -f $afile/* ;;
           esac
        else
           rm -f $afile
        fi
done
---

In future, it would be nice to have an exception in rc.sysinit for tog-pegasus.

I'll make tog-pegasus' initscript's 'stop' handler do a 
'rm -rf /var/run/tog-pegasus' 
for the next version (tog-pegasus-2.4.1-2+) - this is now in CVS.

changed component to tog-pegasus.

That's a workaround more than a fix -- after an unclean shutdown (i.e. power
loss) the message will still appear on next boot.

This is now fixed with latest tog-pegasus-2.4.1-2.rhel4 version :
cimserver no longer creates the /var/run/tog-pegasus/socket/ directory,
but puts its socket in /var/run/tog-pegasus .
It is RHEA-2005:494 that needs the respin (also for bug 165803).

The new tog-pegasus release also fixes Bug 165803 and Bug 165880.
I think it is better to start out with the new tog-pegasus release
since it will be our first distribution of the package, but this is
up to PM.

Yes, this issue may remain after upgrade or erase+install from
tog-pegasus-2.4.1-1 to the fixed tog-pegasus-2.4.1-2.rhel-4 release .

But after a clean install of tog-pegasus-2.4.1-2.rhel4+, as would occur
when RHEL-4 customers receive the tog-pegasus-2.4.1-2.rhel4 for the first
time through the RHN channels, this problem would not occur.

The problem is this: the tog-pegasus-2.4.1-1 release did not list the 
/var/run/tog-pegasus/socket directory in its %files list (it did not
Provide: it), so it was not removed when tog-pegasus-2.4.1-1 was 
erased.

This problem was fixed with tog-pegasus-2.4.1-2.rhel4+: the package now
lists /var/run/tog-pegasus in its %files list, and the directory would
be removed when erasing tog-pegasus-2.4.1-2+ .

Because it is VERY bad practice for any RPM scriplet to do a 'rm -rf' of
ANY directory, as did tog-pegasus-2.4.1-1 with the /opt/tog-pegasus
directory (but not /var/run/tog-pegasus/socket!) we do not want to 
make tog-pegasus-2.4.1-2 do this during install / upgrade - who knows
what some user might have put in this directory?

This issue was inherited from the upstream tog-pegasus release, which
still has this behaviour, though the tog-pegasus maintainers are 
committed to resolving it in subsequent releases.

So, I'm sorry - you'll need to 'rm -rf /var/run/tog-pegasus/socket' to prevent
this message occuring .

After this, all subsequent upgrades / installs will not result in the
message reappearing. 

Any user who clean installs to tog-pegasus-2.4.1-2+, as would all non-beta
customers, will not experience this problem.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2005-494.html