Re: [hobbit] getcwd (was .cfg file name stuff)

[Rob Munsch <rmunsch (at) solutionsforprogress.com>]

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