Problems listing tasks under cygwin.

Problems listing tasks under cygwin.

[alejandro.sanchez]

Hello,

I have the following trouble, if I try to do a ps -aux I obtain all the current
tasks running under cygwin, but sometimes the PID listed is not the right one.
However trying ps -ef I obtain the right PID of the task.

Anyway if I'm trying to list the tasks under the user system (with the same
privileges of root) runned out of cygwin, I see the associated PID but I can't
kill the task, it says something like 'not such PID for the process'.

P.D: To list the tasks in windows I use ps -W -ef under cygwin environment.

Any clue? 

Thanks in advance,
Alejandro.

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

Re: Problems listing tasks under cygwin.

[Larry Hall]

At 03:52 AM 5/18/2004, you wrote:
>Hello,
>
>I have the following trouble, if I try to do a ps -aux I obtain all the current
>tasks running under cygwin, but sometimes the PID listed is not the right one.
>However trying ps -ef I obtain the right PID of the task.
>
>Anyway if I'm trying to list the tasks under the user system (with the same
>privileges of root) runned out of cygwin, I see the associated PID but I can't
>kill the task, it says something like 'not such PID for the process'.
>
>P.D: To list the tasks in windows I use ps -W -ef under cygwin environment.
>
>Any clue? 


I think you need to start back at the beginning.  Here's what I get:

# ps -aux
ps: user x unknown
# ps --version
ps (cygwin) 1.11
Process Statistics
Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
Compiled on Mar 18 2004
# cygcheck -f /bin/ps.exe
cygwin-1.5.9-1

Whatever you're running for 'ps' is not Cygwin's current version at least.


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


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

RE: Problems listing tasks under cygwin.

[Dave Korn]

> -----Original Message-----
> From: cygwin-owner On Behalf Of alejandro.sanchez
> Sent: 18 May 2004 08:52

> I have the following trouble, if I try to do a ps -aux I 
> obtain all the current
> tasks running under cygwin, but sometimes the PID listed is 
> not the right one.

  You're lucky.  My copy of cygwin ps doesn't understand the -aux flag set
at all, because I don't have a user account named 'x' on my system.  ps
takes different flags on different systems, and "-aux" looks to me like
you're expecting it to use the same options as solaris ps.  It doesn't.  "ps
--help" for more.

> However trying ps -ef I obtain the right PID of the task.

  I'm still amazed that you get anything but an error message from the first
way you tried it.  I want to see some cut-n-paste output from your command
shell, because I think you probably haven't described the situation
accurately.

> Anyway if I'm trying to list the tasks under the user system 
> (with the same
> privileges of root) runned out of cygwin, I see the 
> associated PID but I can't
> kill the task, it says something like 'not such PID for the process'.

  Actually, SYSTEM has higher privileges in general than root.  It may well
be impossible to kill some tasks belonging to system because they may not
allow full access even to users with admin rights.  The error message may be
misleading, and maybe it should be saying "Access denied".

  Or maybe not, because you didn't tell us anything about what tasks or what
PIDs or exactly what output you're getting.  Next time you get an error and
want some help with it, I suggest you tell us what the error message
actually was, rather than just some vague approximation to it.  Saying "It
says something like" comes across as if you implying "But I couldn't be
bothered to make a proper note of it because I expect someone else to solve
all my problems for me anyway."  Fully detailed bug reports always get
better responses.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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

Re: Problems listing tasks under cygwin.

[Brian Dessent]

Dave Korn wrote:

>   Actually, SYSTEM has higher privileges in general than root.  It may well
> be impossible to kill some tasks belonging to system because they may not
> allow full access even to users with admin rights.  The error message may be
> misleading, and maybe it should be saying "Access denied".

FYI, you can kill SYSTEM processes as a regular user administrator
account using Process Explorer from sysinternals.com.  I haven't checked
but I believe the program installs a helper driver that runs as SYSTEM
to perform these actions as proxy for the user.  A lot of the
sysinternals tools do something like that it seems.

Brian

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

Re: Problems listing tasks under cygwin.

[Igor Pechtchanski]

On Tue, 18 May 2004, Brian Dessent wrote:

> Dave Korn wrote:
>
> >   Actually, SYSTEM has higher privileges in general than root.  It may
> > well be impossible to kill some tasks belonging to system because they
> > may not allow full access even to users with admin rights.  The error
> > message may be misleading, and maybe it should be saying "Access
> > denied".
>
> FYI, you can kill SYSTEM processes as a regular user administrator
> account using Process Explorer from sysinternals.com.  I haven't checked
> but I believe the program installs a helper driver that runs as SYSTEM
> to perform these actions as proxy for the user.  A lot of the
> sysinternals tools do something like that it seems.
>
> Brian

...Which means that currently in Cygwin one should be able to kill a
SYSTEM-owned task from a SYSTEM-owned shell (using the "at /interactive"
trick), and that once "su via cygserver" is operational, one can simply do
"su SYSTEM kill PID"...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

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

[OT] RE: Problems listing tasks under cygwin.

[Dave Korn]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Brian Dessent
> Sent: 18 May 2004 19:34

> Dave Korn wrote:
> 
> >   Actually, SYSTEM has higher privileges in general than 
> root.  It may well
> > be impossible to kill some tasks belonging to system 
> because they may not
> > allow full access even to users with admin rights.  The 
> error message may be
> > misleading, and maybe it should be saying "Access denied".
> 
> FYI, you can kill SYSTEM processes as a regular user administrator
> account using Process Explorer from sysinternals.com.  I 
> haven't checked
> but I believe the program installs a helper driver that runs as SYSTEM
> to perform these actions as proxy for the user.  A lot of the
> sysinternals tools do something like that it seems.

  Yep.  A quick check with PEView shows that procexp.exe contains two binary
resources, RCDRIVERNT and RCDRIVER9X; the ..NT one clearly contains a .sys
driver file that creates a device.  Interesting functions it links against
include  ZwOpenProcess, KeDetachProcess and KeAttachProcess, and
ZwOpenProcessToken.  Looks like it attaches a thread into the process to be
killed and I'd guess it then gives access rights to the token allowing the
gui process to get at it.

[ObCygwin]  Sysinternals' tools are invaluable for diagnosing cygwin
problems just as much as windoze problems.  Trouble with access perms for
your cron daemon service?  See what's going on with tokenmon.  Trouble with
file access?  Filemon will show you what files are involved.  Need lofs
functionality?  Use HandleEx or ProcExp.  And so on!


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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

Re: [OT] RE: Problems listing tasks under cygwin.

[Brian Dessent]

Dave Korn wrote:

> [ObCygwin]  Sysinternals' tools are invaluable for diagnosing cygwin
> problems just as much as windoze problems.  Trouble with access perms for
> your cron daemon service?  See what's going on with tokenmon.  Trouble with
> file access?  Filemon will show you what files are involved.  Need lofs
> functionality?  Use HandleEx or ProcExp.  And so on!

Although I'd still like to know why using ProcExp to list the handles*
of any running Cygwin process causes the CPU to peg to 100%, and not
come down until cygwin1.dll is unloaded, i.e. kill all running cygwin
tasks and services.  I've had to train myself when using ProcExp to
never accidently click on any Cygwin process, otherwise I have to go
through the annoying process of closing all rxvt's and stopping all
cygservices in order to get an idle CPU again...  I've seen this
reported to the list before but it got no replies.  It started several
notches back in the 1.5 series when there were a large number of changes
to the signal handling code, IIRC.

[*] It could be listing DLLs that causes it, but I don't want to find
out at the moment.

Brian

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

Re: [OT] RE: Problems listing tasks under cygwin.

[Brian Ford]

On Wed, 19 May 2004, Brian Dessent wrote:

> Although I'd still like to know why using ProcExp to list the handles*

Nope, it is DLLs.

> of any running Cygwin process causes the CPU to peg to 100%, and not
> come down until cygwin1.dll is unloaded, i.e. kill all running cygwin
> tasks and services.  I've had to train myself when using ProcExp to
> never accidently click on any Cygwin process, otherwise I have to go
> through the annoying process of closing all rxvt's and stopping all
> cygservices in order to get an idle CPU again...

I don't quite see that.  Only the process being explored runs away.
After killing it, all is normal.

> I've seen this reported to the list before but it got no replies.

IIRC, I think I was the first to report it and you were the only one who
replied.  I haven't tried to fix it yet.

> It started several notches back in the 1.5 series when there were a
> large number of changes to the signal handling code, IIRC.

Agreed.

> [*] It could be listing DLLs that causes it, but I don't want to find
> out at the moment.

It's not that destructive as it only affects the process being explored.
Note that the DLLs are not able to be listed, though.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...

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

RE: [OT] RE: Problems listing tasks under cygwin.

[Dave Korn]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Brian Ford
> Sent: 19 May 2004 14:54

> On Wed, 19 May 2004, Brian Dessent wrote:
> 
> > Although I'd still like to know why using ProcExp to list 
> the handles*
> 
> Nope, it is DLLs.
> 
> > of any running Cygwin process causes the CPU to peg to 100%, and not
> > come down until cygwin1.dll is unloaded, i.e. kill all 
> running cygwin
> > tasks and services.  I've had to train myself when using ProcExp to
> > never accidently click on any Cygwin process, otherwise I have to go
> > through the annoying process of closing all rxvt's and stopping all
> > cygservices in order to get an idle CPU again...
> 
> I don't quite see that.  Only the process being explored runs away.
> After killing it, all is normal.
> 
> > I've seen this reported to the list before but it got no replies.
> 
> IIRC, I think I was the first to report it and you were the 
> only one who
> replied.  I haven't tried to fix it yet.
> 
> > It started several notches back in the 1.5 series when there were a
> > large number of changes to the signal handling code, IIRC.
> 
> Agreed.

  A few data points:

  The reason that the cygwin task behaves strangely has to be a consequence
of the actions of the thread that procexp/handleex attaches into it.
Perhaps we can find out more using apispy or similar.  I can't see any
obvious reason why attaching a thread and messing with the process token
should cause problems, but maybe there's more to it than that.

  When I saw this problem, ISTM that the cpu time was divided approx. 70/30
between the cygwin task and CSRSS.EXE; I think there must be a whole load of
client-server lpc thrashing going on between them.

  When I ran handleex, it didn't even start up properly because a cygwin
(bash) process was hogging cpu; when I killed that process, handleex got
some time to run and promptly crashed with a NULL pointer dereference.  This
came immediately after a failed call to
ntdll!RtlQueryProcessDebugInformation, i.e. the code sequence was

  call ntdll!RtlQueryProcessDebugInformation 
  check return value, if non-zero continue elsewhere
  load up a variable from the stack frame
  dereference it.

so I suspect that something is going wrong in the debug subsystem (which
csrss has responsibility for forwarding).

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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