Remote process attributes

Remote process attributes

[Michael Albinus]

Hi,

Triggered by the recent changes in proced.el, I've played a little bit
in order to see whether proced could also show remote processes. After
all, it is really simple:

- list-system-processes and process-attributes shall return process
  information of the remote host when default-directory is remote. That
  is easy to achive by Tramp, calling ps on that remote host.

- proced would show a remote process list, if default-directory is remote.

That would work for the majority of remote default-directory kind. If
the related Tramp connection does not support remote processes, or there
is no proper argument list for ps, list-system-processes returns nil, no
problem.

This is an incompatible change for list-system-processes and
process-attributes. But the current behavior could be preserved by
calling sonething like

  (let ((default-directory temporary-file-directory))
    (list-system-processes))

There are not so many places list-system-processes and process-attributes
are used in core Emacs, GNU ELPA and NonGNU ELPA. All of them could be
adapted accordingly.

A problem could be to find the proper arguments for ps. I've used a
default setting for GNU/Linux, other systems could apply
connection-local variables for that. My proof-of-concept implementation
offers such settings for the Tramp adb method as well as for remote
(Free)BSD systems and ps implementations based on Busybox. That are the
test cases I could run locally.

Comments?

Best regards, Michael.

Re: Remote process attributes

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Mon, 04 Apr 2022 12:59:22 +0200
> 
> Triggered by the recent changes in proced.el, I've played a little bit
> in order to see whether proced could also show remote processes. After
> all, it is really simple:
> 
> - list-system-processes and process-attributes shall return process
>   information of the remote host when default-directory is remote.

Is it really certain that the default-directory being remote is
evidence significant enough that the user wants to list remote
processes?  Processes aren't files, and aren't even related to files
like programs (whose executable files are looked up before we run
them).

> A problem could be to find the proper arguments for ps. I've used a
> default setting for GNU/Linux, other systems could apply
> connection-local variables for that. My proof-of-concept implementation
> offers such settings for the Tramp adb method as well as for remote
> (Free)BSD systems and ps implementations based on Busybox. That are the
> test cases I could run locally.

As mentioned in that thread, there are several ps implementations, and
they differ in what they accept and how they report various
attributes.  We switched to our own implementation to avoid the
problems we had using ps.  Now these problems will be back.  I
envision trouble.

Re: Remote process attributes

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> - list-system-processes and process-attributes shall return process
>>   information of the remote host when default-directory is remote.
>
> Is it really certain that the default-directory being remote is
> evidence significant enough that the user wants to list remote
> processes?  Processes aren't files, and aren't even related to files
> like programs (whose executable files are looked up before we run
> them).

I've checked all occurences of list-system-processes and
process-attributes in core Emacs, GNU ELPA and NonGNU ELPA. This is just
a handful, and all of them could preserve their behavior with the
template I've shown. Really not a big deal.

If both functions are used somewhere else in the future, the
documentation tells what to do. And I could imagine that this
information about remote processes could be used not only in proced.

>> A problem could be to find the proper arguments for ps. I've used a
>> default setting for GNU/Linux, other systems could apply
>> connection-local variables for that. My proof-of-concept implementation
>> offers such settings for the Tramp adb method as well as for remote
>> (Free)BSD systems and ps implementations based on Busybox. That are the
>> test cases I could run locally.
>
> As mentioned in that thread, there are several ps implementations, and
> they differ in what they accept and how they report various
> attributes.  We switched to our own implementation to avoid the
> problems we had using ps.  Now these problems will be back.  I
> envision trouble.

I'm fully aware of this. And for local processes, nothing changes. For
remote processes, my implementation simply returns nil if ps isn't
called with a proper argument list. This could be enhanced case by case,
and users could also configure the ps argument list by themselves, but
for a large fraction of remote systems this would return already useful
information. So it isn't a regression, but rather a progression.

What we could think about is a way to indicate proced whether to return
local or possibly remote process information. I wanted to add a prefix
argument to proced in order to trigger remote process information, but
this is already used for window selection.

Best regards, Michael.

Re: Remote process attributes

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Mon, 04 Apr 2022 13:33:59 +0200
> 
> > Is it really certain that the default-directory being remote is
> > evidence significant enough that the user wants to list remote
> > processes?  Processes aren't files, and aren't even related to files
> > like programs (whose executable files are looked up before we run
> > them).
> 
> I've checked all occurences of list-system-processes and
> process-attributes in core Emacs, GNU ELPA and NonGNU ELPA. This is just
> a handful, and all of them could preserve their behavior with the
> template I've shown. Really not a big deal.
> 
> If both functions are used somewhere else in the future, the
> documentation tells what to do. And I could imagine that this
> information about remote processes could be used not only in proced.

Using Proced is what I had in mind.  AFAIU, if Proced is invoked with
default-directory being on a remote host, it will show remote
processes after your changes.  I'm asking whether users will indeed
expect that.

> What we could think about is a way to indicate proced whether to return
> local or possibly remote process information. I wanted to add a prefix
> argument to proced in order to trigger remote process information, but
> this is already used for window selection.

We could use a special value of the argument to work around this.

Re: Remote process attributes

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> If both functions are used somewhere else in the future, the
>> documentation tells what to do. And I could imagine that this
>> information about remote processes could be used not only in proced.
>
> Using Proced is what I had in mind.  AFAIU, if Proced is invoked with
> default-directory being on a remote host, it will show remote
> processes after your changes.  I'm asking whether users will indeed
> expect that.

Agreed, local processes shall be the default, whatever default-directory is.

>> What we could think about is a way to indicate proced whether to return
>> local or possibly remote process information. I wanted to add a prefix
>> argument to proced in order to trigger remote process information, but
>> this is already used for window selection.
>
> We could use a special value of the argument to work around this.

Hmm, perhaps "C-u -" (aka "M--") would serve?

Best regards, Michael.

Re: Remote process attributes

[chad]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

On Mon, Apr 4, 2022 at 8:28 AM Michael Albinus <michael.albinus@gmx.de>
wrote:

> >> What we could think about is a way to indicate proced whether to return
> >> local or possibly remote process information. I wanted to add a prefix
> >> argument to proced in order to trigger remote process information, but
> >> this is already used for window selection.
> >
> > We could use a special value of the argument to work around this.
>
> Hmm, perhaps "C-u -" (aka "M--") would serve?
>

Since this will usually be invoked interactively, maybe just ask the user,
something like "Default directory is remote; list remote processes?" or
"Run proced on remote host matching <default-directory>?", with the
attendant ask/assume-yes/assume-no customization?

~Chad

[-- Attachment #2: Type: text/html, Size: 1442 bytes --]

Re: Remote process attributes

[Michael Albinus]

chad <yandros@gmail.com> writes:

Hi,

>     > We could use a special value of the argument to work around this.
>
>     Hmm, perhaps "C-u -" (aka "M--") would serve?
>
> Since this will usually be invoked interactively, maybe just ask the
> user, something like "Default directory is remote; list remote
> processes?" or "Run proced on remote host matching
> <default-directory>?", with the attendant ask/assume-yes/assume-no
> customization?

Thanks for the proposal. However, since I assume that the majority of
users are still interested in local system processes, this might an
annoyance to them.

So I've added a new user option `proced-show-remote-processes', which
activates the new behavior when non-nil. And also the "C-u -" prefix, as
discussed above.

Pushed to master. Feedback much appreciated!

> ~Chad

Best regards, Michael.