ps questions

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

ps questions

Kizito Porta Balanyà
Hello,

I can't find where "ps -W" is coded in the procps source files. Is it
there ? is it in cygwin.dll? What are you doing "internally" with the
-W option?

Another question related is: It is possible to map windows processes
to the /proc filysystem. Any way or hint?

Thanks a lot for your time and thanks for the other answered questions.

Regards.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: ps questions

marco atzeri-4


On 12/18/2014 3:52 PM, Kizito Porta Balanyà wrote:

> Hello,
>
> I can't find where "ps -W" is coded in the procps source files. Is it
> there ? is it in cygwin.dll? What are you doing "internally" with the
> -W option?
>
> Another question related is: It is possible to map windows processes
> to the /proc filysystem. Any way or hint?
>
> Thanks a lot for your time and thanks for the other answered questions.
>
> Regards.
>

ps is part of the cygwin package

https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86%2Fcygwin%2Fcygwin-1.7.33-1&grep=ps.exe

https://cygwin.com/viewvc/src/winsup/utils/ps.cc?revision=1.38&view=markup

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: ps questions

BGINFO4X
2014-12-18 16:08 GMT+01:00 Marco Atzeri <[hidden email]>:

>
>
> On 12/18/2014 3:52 PM, Kizito Porta Balanyà wrote:
>>
>> Hello,
>>
>> I can't find where "ps -W" is coded in the procps source files. Is it
>> there ? is it in cygwin.dll? What are you doing "internally" with the
>> -W option?
>>
>> Another question related is: It is possible to map windows processes
>> to the /proc filysystem. Any way or hint?
>>
>> Thanks a lot for your time and thanks for the other answered questions.
>>
>> Regards.
>>
>
> ps is part of the cygwin package

Yes, you are right, I was confused with the procps package.

Another question:
When I execute a windows program, in the /proc table of the process,
the cwd and root are <defunct> , is this correct? is it a bug?

For example, if I launch notepad & : /proc/4422 :

cwd -> <defunct>
root -> <defunct>
exe -> is OK.  /cygdrive/c/WINDOWS/system32/notepad

This only happens with the native windows aplications.
Cygwin applications have correct values in cwd and root.

Thanks again.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: ps questions

Corinna Vinschen-2
On Dec 18 17:57, BGINFO4X wrote:

> 2014-12-18 16:08 GMT+01:00 Marco Atzeri <[hidden email]>:
> >
> >
> > On 12/18/2014 3:52 PM, Kizito Porta Balanyà wrote:
> >>
> >> Hello,
> >>
> >> I can't find where "ps -W" is coded in the procps source files. Is it
> >> there ? is it in cygwin.dll? What are you doing "internally" with the
> >> -W option?
> >>
> >> Another question related is: It is possible to map windows processes
> >> to the /proc filysystem. Any way or hint?
Not without writing lots of new code.  Also, some of the files don't
make sense or can't be filled.

> >> Thanks a lot for your time and thanks for the other answered questions.
> >>
> >> Regards.
> >>
> >
> > ps is part of the cygwin package
>
> Yes, you are right, I was confused with the procps package.
>
> Another question:
> When I execute a windows program, in the /proc table of the process,
> the cwd and root are <defunct> , is this correct? is it a bug?
>
> For example, if I launch notepad & : /proc/4422 :
>
> cwd -> <defunct>
> root -> <defunct>
> exe -> is OK.  /cygdrive/c/WINDOWS/system32/notepad
>
> This only happens with the native windows aplications.
> Cygwin applications have correct values in cwd and root.
The <defunct> information is fetched from the process itself.  This
requires a living, valid Cygwin process, so the info isn't available for
Windows processes.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ps questions

Warren Young-2
On Dec 18, 2014, at 10:11 AM, Corinna Vinschen <[hidden email]> wrote:

> The <defunct> information is fetched from the process itself.  This
> requires a living, valid Cygwin process, so the info isn't available for
> Windows processes.

On a Unix/Linux system, a process is marked <defunct> when the kernel knows it has died, but its parent hasn’t called wait(2) or similar yet, so the kernel keeps info about the process around with the expectation that this call will come later.

So, you’re saying that Cygwin doesn’t do something similar?

If it did, it would be able to distinguish between dead Cygwin processes and dead native processes.  “I didn’t start that one, so I will mark it <dead> instead of <defunct>,” kind of thing.
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: ps questions

Corinna Vinschen-2
On Dec 18 10:26, Warren Young wrote:

> On Dec 18, 2014, at 10:11 AM, Corinna Vinschen <[hidden email]> wrote:
>
> > The <defunct> information is fetched from the process itself.  This
> > requires a living, valid Cygwin process, so the info isn't available for
> > Windows processes.
>
> On a Unix/Linux system, a process is marked <defunct> when the kernel
> knows it has died, but its parent hasn’t called wait(2) or similar
> yet, so the kernel keeps info about the process around with the
> expectation that this call will come later.
>
> So, you’re saying that Cygwin doesn’t do something similar?
Similar, but not the same.  Cygwin isn't a kernel and the process
information is kept in shared memory regions held by the parent process
and the process itself.  This model has limitations you don't have on a
real kernel.

> If it did, it would be able to distinguish between dead Cygwin
> processes and dead native processes.  “I didn’t start that one, so I
> will mark it <dead> instead of <defunct>,” kind of thing.

The <defunct> in case of a Windows process means only that the calling
process was incapable of fetching this information.  It doesn't know
the state, because the target process didn't reply with the requested
information.  Actually, it didn't reply at all.  That's one of the
limitations of the model.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ps questions

BGINFO4X
In reply to this post by Corinna Vinschen-2
2014-12-18 18:11 GMT+01:00 Corinna Vinschen <[hidden email]>:

> On Dec 18 17:57, BGINFO4X wrote:
>> 2014-12-18 16:08 GMT+01:00 Marco Atzeri <[hidden email]>:
>> >
>> >
>> > On 12/18/2014 3:52 PM, Kizito Porta Balanyà wrote:
>> >>
>> >> Hello,
>> >>
>> >> I can't find where "ps -W" is coded in the procps source files. Is it
>> >> there ? is it in cygwin.dll? What are you doing "internally" with the
>> >> -W option?
>> >>
>> >> Another question related is: It is possible to map windows processes
>> >> to the /proc filysystem. Any way or hint?
>
> Not without writing lots of new code.  Also, some of the files don't
> make sense or can't be filled.
>
>> >> Thanks a lot for your time and thanks for the other answered questions.
>> >>
>> >> Regards.
>> >>
>> >
>> > ps is part of the cygwin package
>>
>> Yes, you are right, I was confused with the procps package.
>>
>> Another question:
>> When I execute a windows program, in the /proc table of the process,
>> the cwd and root are <defunct> , is this correct? is it a bug?
>>
>> For example, if I launch notepad & : /proc/4422 :
>>
>> cwd -> <defunct>
>> root -> <defunct>
>> exe -> is OK.  /cygdrive/c/WINDOWS/system32/notepad
>>
>> This only happens with the native windows aplications.
>> Cygwin applications have correct values in cwd and root.
>
> The <defunct> information is fetched from the process itself.  This
> requires a living, valid Cygwin process, so the info isn't available for
> Windows processes.
>

Hello again, forgive me if this is stupid:

If any cygwin process has the values
cwd=/proc/$PID
root=/

Instead of fetching the information, you can "hardcode" the values. Isn't it?

Thanks.


> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: ps questions

Corinna Vinschen-2
On Dec 18 18:56, BGINFO4X wrote:

> 2014-12-18 18:11 GMT+01:00 Corinna Vinschen <...>
> > The <defunct> information is fetched from the process itself.  This
> > requires a living, valid Cygwin process, so the info isn't available for
> > Windows processes.
> >
>
> Hello again, forgive me if this is stupid:
>
> If any cygwin process has the values
> cwd=/proc/$PID
> root=/
>
> Instead of fetching the information, you can "hardcode" the values. Isn't it?
And how much sense does it make?

The root value is most of the time ok, unless a process runs under
chroot.

The cwd value on the other hand...  /proc is a virtual, Cygwin-only
directory and isn't a valid CWD for a non-Cygwin process.
And you can't call the OS for the CWD of another process.  On Windows,
the CWD is a process-local concept, not supported by the kernel.
Fetching the CWD of a process requires read access to the VM of a
process and a bit of undocumented NT magic.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ps questions

Warren Young-2
In reply to this post by Corinna Vinschen-2
On Dec 18, 2014, at 10:33 AM, Corinna Vinschen <[hidden email]> wrote:

> On Dec 18 10:26, Warren Young wrote:
>>
>> ...Cygwin doesn’t do something similar?
>
> Cygwin isn't a kernel and the process
> information is kept in shared memory regions held by the parent process
> and the process itself.  This model has limitations you don't have on a
> real kernel.

I’m aware of that, but can’t the DLL see both the birth and death of every Cygwin process?  Birth via either DllMain() or execvp(2), and death via one of the methods here:

    http://stackoverflow.com/questions/4242469/
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: ps questions

Corinna Vinschen-2
On Dec 18 11:40, Warren Young wrote:

> On Dec 18, 2014, at 10:33 AM, Corinna Vinschen <[hidden email]> wrote:
>
> > On Dec 18 10:26, Warren Young wrote:
> >>
> >> ...Cygwin doesn’t do something similar?
> >
> > Cygwin isn't a kernel and the process
> > information is kept in shared memory regions held by the parent process
> > and the process itself.  This model has limitations you don't have on a
> > real kernel.
>
> I’m aware of that, but can’t the DLL see both the birth and death of
> every Cygwin process?  Birth via either DllMain() or execvp(2), and
> death via one of the methods here:
Aren't we talking about fetching info from non-Cygwin processes?


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ps questions

Warren Young
On Dec 18, 2014, at 11:51 AM, Corinna Vinschen <[hidden email]> wrote:

> On Dec 18 11:40, Warren Young wrote:
>> On Dec 18, 2014, at 10:33 AM, Corinna Vinschen <[hidden email]> wrote:
>>
>>> On Dec 18 10:26, Warren Young wrote:
>>>>
>>>> ...Cygwin doesn’t do something similar?
>>>
>>> Cygwin isn't a kernel and the process
>>> information is kept in shared memory regions held by the parent process
>>> and the process itself.  This model has limitations you don't have on a
>>> real kernel.
>>
>> I’m aware of that, but can’t the DLL see both the birth and death of
>> every Cygwin process?  Birth via either DllMain() or execvp(2), and
>> death via one of the methods here:
>
> Aren't we talking about fetching info from non-Cygwin processes?

Of course.  But if you keep a table of all Cygwin processes, you can tell whether you’re being asked for info for a native process vs a Cygwin one, and handle <defunct> differently for the two cases.
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: ps questions

Corinna Vinschen-2
In reply to this post by Corinna Vinschen-2
On Dec 18 19:51, Corinna Vinschen wrote:

> On Dec 18 11:40, Warren Young wrote:
> > On Dec 18, 2014, at 10:33 AM, Corinna Vinschen <[hidden email]> wrote:
> >
> > > On Dec 18 10:26, Warren Young wrote:
> > >>
> > >> ...Cygwin doesn’t do something similar?
> > >
> > > Cygwin isn't a kernel and the process
> > > information is kept in shared memory regions held by the parent process
> > > and the process itself.  This model has limitations you don't have on a
> > > real kernel.
> >
> > I’m aware of that, but can’t the DLL see both the birth and death of
> > every Cygwin process?  Birth via either DllMain() or execvp(2), and
> > death via one of the methods here:
>
> Aren't we talking about fetching info from non-Cygwin processes?
On re-reading your question, I'm wondering if you don't have a slight
misconception.  Keep in mind that the (Cygwin) DLL is not a single
entity on the system.  Every process is running its own copy of the
Cygwin DLL.  The communication between different Cygwin process requires
bookkeeping outside of the DLL.  For instance, all Cygwin processes have
their own shared memory region constituting something akin to a process
table entry of an OS.  For security reasons, access to this shared
memory is restricted via ACLs, so not every process can open the process
info region of every process.

Back to the DLL.  There's one Cygwin DLL in every Cygwin process'
virtual memory.  If "the Cygwin DLL" is supposed to keep track of
life and death of every Cygwin process, you're in fact asking for
*every* Cygwin process keeping track of life and death of *every*
other Cygwin process.

Again, the Cygwin DLL is no kernel, and it's no process on its own.
It's just the core part of each Cygwin process, handling bookkeeping for
itself and its child processes, and otherwise trying to communicate with
the Cygwin DLLs in other processes in good faith.

Does that clarify the situation a bit?


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ps questions

Corinna Vinschen-2
In reply to this post by Warren Young
On Dec 18 11:54, Warren Young wrote:

> On Dec 18, 2014, at 11:51 AM, Corinna Vinschen <[hidden email]> wrote:
>
> > On Dec 18 11:40, Warren Young wrote:
> >> On Dec 18, 2014, at 10:33 AM, Corinna Vinschen <[hidden email]> wrote:
> >>
> >>> On Dec 18 10:26, Warren Young wrote:
> >>>>
> >>>> ...Cygwin doesn’t do something similar?
> >>>
> >>> Cygwin isn't a kernel and the process
> >>> information is kept in shared memory regions held by the parent process
> >>> and the process itself.  This model has limitations you don't have on a
> >>> real kernel.
> >>
> >> I’m aware of that, but can’t the DLL see both the birth and death of
> >> every Cygwin process?  Birth via either DllMain() or execvp(2), and
> >> death via one of the methods here:
> >
> > Aren't we talking about fetching info from non-Cygwin processes?
>
> Of course.  But if you keep a table of all Cygwin processes, you can
> tell whether you’re being asked for info for a native process vs a
> Cygwin one, and handle <defunct> differently for the two cases.
That may be possible, but it's just not implemented.  Under the hood,
the process your seeing in /proc is not really the native Windows
process, but rather a Cygwin process stub.  The stub has a process info
shared mem region, but it's essentially defunct, the only task it's
handling is to wait for the non-Cygwin process to exit.  It may be
possible to add functionality to the stub process, but given that the
actually running process is a non-Cygwin process, it will be fairly
limited.  And, seriously, there was just no reason to put that much
work into bookkeeping for native processes.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ps questions

Warren Young-2
On Dec 18, 2014, at 12:10 PM, Corinna Vinschen <[hidden email]> wrote:

> That may be possible

That’s all I really wanted: to be correct. :)


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: ps questions

Corinna Vinschen-2
On Dec 18 12:17, Warren Young wrote:
> On Dec 18, 2014, at 12:10 PM, Corinna Vinschen <[hidden email]> wrote:
>
> > That may be possible
>
> That’s all I really wanted: to be correct. :)

"Maybe" doesn't mean "is" ;)


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ps questions

Kizito Porta Balanyà
In reply to this post by Corinna Vinschen-2
2014-12-18 19:51 GMT+01:00 Corinna Vinschen <[hidden email]>:

> On Dec 18 11:40, Warren Young wrote:
>> On Dec 18, 2014, at 10:33 AM, Corinna Vinschen <[hidden email]> wrote:
>>
>> > On Dec 18 10:26, Warren Young wrote:
>> >>
>> >> ...Cygwin doesn’t do something similar?
>> >
>> > Cygwin isn't a kernel and the process
>> > information is kept in shared memory regions held by the parent process
>> > and the process itself.  This model has limitations you don't have on a
>> > real kernel.
>>
>> I’m aware of that, but can’t the DLL see both the birth and death of
>> every Cygwin process?  Birth via either DllMain() or execvp(2), and
>> death via one of the methods here:
>
> Aren't we talking about fetching info from non-Cygwin processes?

But .., any process found in /proc is not a cygwin processs?
If it isn't why ps -ef reports it?

$ ps -ef
    UID     PID    PPID  TTY        STIME COMMAND
    k        4804   4908  pty0     18:18:29 /cygdrive/c/WINDOWS/system32/notepad

In this case notepad, is a child of bash (pid 4908). So it seams a
cygwin process, isn't it?


Thanks a lot again.



> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: ps questions

marco atzeri-4
On 12/19/2014 11:15 AM, Kizito Porta Balanyà wrote:
> 2014-12-18 19:51 GMT+01:00 Corinna Vinschen <[hidden email]>:
>> On Dec 18 11:40, Warren Young wrote:
>>> On Dec 18, 2014, at 10:33 AM, Corinna Vinschen <[hidden email]> wrote:
>>>
>>
>> Aren't we talking about fetching info from non-Cygwin processes?

no, only the ones linked to the cygwin1.dll

> But .., any process found in /proc is not a cygwin processs?
> If it isn't why ps -ef reports it?
>
> $ ps -ef
>      UID     PID    PPID  TTY        STIME COMMAND
>      k        4804   4908  pty0     18:18:29 /cygdrive/c/WINDOWS/system32/notepad
>
> In this case notepad, is a child of bash (pid 4908). So it seams a
> cygwin process, isn't it?

No. Just a normal windows process started from a cygwin one.

REgards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple