[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.
- bug#72013: The eshell/kill command doesn't work with eshell/sudo correctly, the_wurfkreuz, 2024/07/09
- bug#72013: The eshell/kill command doesn't work with eshell/sudo correctly, Jim Porter, 2024/07/09
- Message not available
- bug#72013: The eshell/kill command doesn't work with eshell/sudo correctly, Michael Albinus, 2024/07/10
- bug#72013: The eshell/kill command doesn't work with eshell/sudo correctly, Jim Porter, 2024/07/14
- bug#72013: The eshell/kill command doesn't work with eshell/sudo correctly, Jim Porter, 2024/07/14
- bug#72013: The eshell/kill command doesn't work with eshell/sudo correctly, Michael Albinus, 2024/07/15
- bug#72013: The eshell/kill command doesn't work with eshell/sudo correctly, Eli Zaretskii, 2024/07/15
- bug#72013: The eshell/kill command doesn't work with eshell/sudo correctly, Jim Porter, 2024/07/15