Xymon Mailing List Archive search

getcwd (was .cfg file name stuff)

list Rob Munsch
Fri, 28 Oct 2005 18:27:40 -0400
Message-Id: <user-41f566c2fa9b@xymon.invalid>

hello again, maybe this will help:

rmunsch at doisneau:~/client$ strace -f ./runclient.sh --hostname=doisneau start 2>&1 | grep -5 getcwd
[pid  7053] close(6)                    = 0
[pid  7053] open("/proc/7014/status", O_RDONLY) = 6
[pid  7053] read(6, "Name:\tgrep\nState:\tS (sleeping)\nS"..., 1023) = 531
[pid  7053] close(6)                    = 0
[pid  7053] open("/proc/7014/cmdline", O_RDONLY) = 6
[pid  7053] read(6, "grep\0-5\0getcwd\0", 2047) = 15
[pid  7053] close(6)                    = 0
[pid  7053] stat64("/dev/ttyp0", {st_mode=S_IFCHR|0620, st_rdev=makedev(3, 0), ...}) = 0
[pid  7053] stat64("/proc/7042", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid  7053] open("/proc/7042/stat", O_RDONLY) = 6
[pid  7053] read(6, "7042 (hobbitlaunch) S 1 7042 704"..., 1023) = 184
--
[pid  7054] close(4)                    = 0
[pid  7054] open("/proc/7014/statm", O_RDONLY) = 4
[pid  7054] read(4, "439 143 117 18 0 90 0\n", 1023) = 22
[pid  7054] close(4)                    = 0
[pid  7054] open("/proc/7014/cmdline", O_RDONLY) = 4
[pid  7054] read(4, "grep\0-5\0getcwd\0", 2047) = 15
[pid  7054] close(4)                    = 0
[pid  7054] stat64("/proc/7042", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid  7054] open("/proc/7042/stat", O_RDONLY) = 4
[pid  7054] read(4, "7042 (hobbitlaunch) S 1 7042 704"..., 1023) = 184
[pid  7054] close(4)                    = 0

With every 5 seconds a new line appearing in the log of

shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

What's strange is it seems to be working now, for the most part.  I let this client run, shut down the hobbitd, and it faithfully complained of a lack of server to send to.

What is it trying to do with this getcwd() that is failing, and that doesn't seem to affect the reports sent to the host..?

Of note: there is an ancient Debian bugrep about this message that was alternately blamed on bash 2.03 and dpkg < 1.9, and closed as "resolved with dpkg 1.9" - as i have bash 3-something and dpkg 1.10+ i am going to assume it was not :D.  It was reported as a rare occurance by all parties at the time, but it shows up like clockwork here.

Hope this helps...

-- 
Rob Munsch
Systems Analyst, Solutions for Progress
http://www.solutionsforprogress.com