[Spacewalk-list] Spacewalk 0.7 rhnsd not running rhn_check

Lee Verberne verb at pontiflex.com
Thu Jan 21 23:36:08 UTC 2010

While researching this issue, I found this related thread:


When upgrading my clients from rhnsd-4.5.11-1.el5 (Spacewalk 0.6) to
rhnsd-4.5.16-1.el5 (Spacewalk 0.7), I noticed that they stop checking in
altogether.  As a result, updates aren't being applied without manually running
rhn_check or yum.

Here's a snippet of an strace from rhnsd after it wakes up from sleep:

time(NULL)                              = 1264108496
time(NULL)                              = 1264108496
access("/etc/sysconfig/rhn/up2date", R_OK) = 0
open("/etc/sysconfig/rhn/up2date", O_RDONLY) = 1
fstat(1, {st_mode=S_IFREG|0644, st_size=1483, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ad1bf4ed000
read(1, "# Red Hat Update Agent config fi"..., 4096) = 1483
access("", R_OK)                        = -1 ENOENT (No such file or directory)
time([1264108496])                      = 1264108496
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
sendto(0, "<31>Jan 21 16:14:56 rhnsd[21946]"..., 66, MSG_NOSIGNAL, NULL, 0) = 66

The message that gets logged is:
rhnsd[21946]:  does not exist or is unreadable

So basically, rhnsd wakes up, parses /etc/sysconfig/rhn/up2date, attempts to
open a systemid file of "", fails and exits.

Looking for the source to rhnsd, I stumbled upon this:

I'm not familiar with Spacewalk's source organization, so forgive me if the
above file is not actually the source to rhnsd from Spacewalk 0.7.  I was
hesitant to assume this was the released version, but the behavior of rhnsd 
is consistent with this source.

The first thing I noticed is that the "return 0" of line 604 from 
parse_systemid_path causes rhnsd to leaks file descriptors.  My running rhnsd 
does indeed leak:

rhnsd   21946 root  cwd    DIR              202,1    4096       2 /
rhnsd   21946 root  rtd    DIR              202,1    4096       2 /
rhnsd   21946 root  txt    REG              202,1   17016 2194587 /usr/sbin/rhnsd
rhnsd   21946 root  mem    REG              202,1  139416 1437596 /lib64/ld-2.5.so
rhnsd   21946 root  mem    REG              202,1 1717800 1437598 /lib64/libc-2.5.so
rhnsd   21946 root    0u  unix 0xffff8800144f5d00         1453816 socket
rhnsd   21946 root    1r   REG              202,1    1483 1242872 /etc/sysconfig/rhn/up2date~ (deleted)
rhnsd   21946 root    2r   REG              202,1    1483 1242872 /etc/sysconfig/rhn/up2date~ (deleted)
rhnsd   21946 root    3r   REG              202,1    1524 1242848 /etc/sysconfig/rhn/up2date

The other strange thing the above source is that it compiles the regular 
expression, but it never uses it.  So this source would never actually
work -- which is why I'm loath to assume it's the actual source.

Anyway, I hope I've provided enough information for a spacewalk
developer to take a look and comment on what could be happening.  


More information about the Spacewalk-list mailing list