/proc/<pid>/{cwd, root} links to <defunct> for cygrunsrv, daemons, and shells

[Brian Inglis]

On 2024-04-09 07:08, Corinna Vinschen wrote:
> On Apr  7 13:34, Brian Inglis wrote:
>> ISTM anomalous that for cygrunsrv, daemons, cron processes, and shells
>> /proc/<pid>/{cwd,root} have bad symlinks to "<defunct>", normally a process
>> or exe status:
>>
>> /proc/732/exe   -> /usr/bin/cygrunsrv
>> /proc/732/root  -> <defunct>
>> /proc/732/cwd   -> <defunct>
>> |  /proc/733/exe   -> /usr/sbin/cygserver
>>   ->/proc/733/root  -> <defunct>
>>     /proc/733/cwd   -> <defunct>
>> /proc/740/exe   -> /usr/bin/cygrunsrv
>> /proc/740/root  -> <defunct>
>> /proc/740/cwd   -> <defunct>
>> |  /proc/741/exe   -> /usr/sbin/syslog-ng
>>   ->/proc/741/root  -> <defunct>
>>     /proc/741/cwd   -> <defunct>
>> /proc/748/exe   -> /usr/bin/cygrunsrv
>> /proc/748/root  -> <defunct>
>> /proc/748/cwd   -> <defunct>
>> |  /proc/749/exe   -> /usr/sbin/cron
>>   ->/proc/749/root  -> <defunct>
>>     /proc/749/cwd   -> <defunct>
>>     |  /proc/2080/exe  -> /usr/sbin/cron
>>      ->/proc/2080/root -> <defunct>
>>        /proc/2080/cwd  -> <defunct>
>>        |  /proc/2082/exe  -> /usr/bin/bash
>>         ->/proc/2082/root -> <defunct>
>>           /proc/2082/cwd  -> <defunct>
>>
>> Should we consider changing that to root "/", or nothing, null, or something
>> meaningful?
> 
> That's typically a permission problem.  On Linux you get something like
> 
>    ls: cannot read symbolic link '/proc/1/cwd': Permission denied

Thanks Corinna,

That now makes sense, as Cygwin ps -a and btop showed the processes, although 
procps and top did not, and other info is visible, I never thought about 
permissions as there were links, but I see from elevated admin sh:

/proc/732/exe   -> /usr/bin/cygrunsrv
/proc/732/root  -> /
/proc/732/cwd   -> /proc/cygdrive/c/WINDOWS/system32
|  /proc/733/exe   -> /usr/sbin/cygserver
  ->/proc/733/root  -> /
    /proc/733/cwd   -> /proc/cygdrive/WINDOWS/system32
/proc/740/exe   -> /usr/bin/cygrunsrv
/proc/740/root  -> /
/proc/740/cwd   -> /proc/cygdrive/WINDOWS/system32
|  /proc/741/exe   -> /usr/sbin/syslog-ng
  ->/proc/741/root  -> /
    /proc/741/cwd   -> /proc/cygdrive/WINDOWS/system32
/proc/748/exe   -> /usr/bin/cygrunsrv
/proc/748/root  -> /
/proc/748/cwd   -> /proc/cygdrive/WINDOWS/system32
|  /proc/749/exe   -> /usr/sbin/cron
  ->/proc/749/root  -> /
    /proc/749/cwd   -> /var/cron

and from normal mintty bash:

$ stat -L -c%a\ %A\ %n /proc/732/*
444 -r--r--r-- /proc/732/cmdline
444 -r--r--r-- /proc/732/ctty
stat: cannot stat '/proc/732/cwd': No such file or directory
444 -r--r--r-- /proc/732/environ
755 -rwxr-xr-x /proc/732/exe
444 -r--r--r-- /proc/732/exename
555 dr-xr-xr-x /proc/732/fd
444 -r--r--r-- /proc/732/gid
444 -r--r--r-- /proc/732/maps
444 -r--r--r-- /proc/732/mountinfo
444 -r--r--r-- /proc/732/mounts
444 -r--r--r-- /proc/732/pgid
444 -r--r--r-- /proc/732/ppid
stat: cannot stat '/proc/732/root': No such file or directory
444 -r--r--r-- /proc/732/sid
444 -r--r--r-- /proc/732/stat
444 -r--r--r-- /proc/732/statm
444 -r--r--r-- /proc/732/status
444 -r--r--r-- /proc/732/uid
444 -r--r--r-- /proc/732/winexename
444 -r--r--r-- /proc/732/winpid
$ more /proc/732/* > /dev/null
more: cannot open /proc/732/cwd: No such file or directory
more: cannot open /proc/732/maps: Permission denied
more: cannot open /proc/732/root: No such file or directory
more: cannot open /proc/732/stat: Permission denied
more: cannot open /proc/732/statm: Permission denied

so I think perms on these should be 440 or 550 not 444 or 555, but that may 
involve a lot of work to decide that for each entry?

> But on Cygwin the content of those links require to open the processes'
> signal pipe and send/receive a message containing the information.  I
> didn't look into the code for a while but it seems we don't check why we
> couldn't connect to a process to fetch the info. IIRC the current
> fhandler_process framework doesn't have a way to communicate that
> info.
> 
> If you want to change that, feel free!

I will take a look sometime but no promises of any patch(es) ;^>

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry