bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#72013: The eshell/kill command doesn't work with eshell/sudo correct


From: Jim Porter
Subject: bug#72013: The eshell/kill command doesn't work with eshell/sudo correctly
Date: Tue, 9 Jul 2024 17:08:57 -0700

(Re-adding the bug tracker address. The tracker requires using Reply
All to keep messages going to the list.)

On Tue, Jul 9, 2024 at 11:38 AM the_wurfkreuz <the_wurfkreuz@proton.me> wrote:
> Sorry, i was exhausted when i was rechecking everything before submitting the 
> bug report and made a slip up. In reality the problem is with processes owned 
> by root. I was trying to send signal to a docker daemon.

Ah ha. This is really an issue that 'eshell/kill' can't kill "remote"
processes. What you *want* to happen is for Eshell to kill the process
with some PID over the Tramp "sudo" connection, which makes it a
"remote" process. That'll fail for a couple reasons: 1) Eshell just
passes the PID to 'signal-process', and that PID will be interpreted
according to your local host+user, 2) Tramp doesn't support
'signal-process' in the first place, as far as I know (but it does
support things like 'delete-process').

> Also, it looks like it doesn't work even when i write 'eshell/kill' instead 
> of 'kill'. The main point is that i can use the 'kill' command only with 
> posix sudo when it comes to processes owned by root. Using it with 
> eshell/sudo doesn't work:

/usr/bin/sudo works here because it doesn't call eshell/kill, it calls
/usr/bin/kill. eshell/sudo would also work if you call /usr/bin/kill.
You could spell the full path like that, or use "*kill", which ignores
the Eshell built-in version.

Your scenario is actually the *less* dangerous one though: since a
Tramp sudo connection is still (usually) on localhost, the PIDs are
all the same; all that'll happen is that "kill" fails sometimes. But
if you were connected over SSH to a remote host and ran "kill" in
Eshell, it would be killing *local* processes. That's highly
unexpected and would probably cause serious problems! I think the best
way to fix this would simply be for 'eshell/kill' to fall back to
'/usr/bin/kill' any time the default-directory is remote. That way is
a lot safer.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]