GNU bug report logs - #76950
tramp caches non-existing podman containers

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76950 in the body.
You can then email your comments to 76950 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: tramp caches non-existing podman containers
Date: Tue, 11 Mar 2025 20:35:51 +0300

When tramp is used to connect to a container, it provides completion
based on what containers are currently running. However, after
containers exit, the completion annoyingly still enlists those dead
containers.

# Steps to reproduce

1. Run any container, e.g.: `podman run --rm -it ubuntu:24.04`
2. Start Emacs as `emacs -Q --eval "(require 'tramp)"`
3. Press `C-x C-f /podman:`, then press TAB to complete the minibuffer
text to container name (it should get completed).
4. Cancel with C-g
5. Exit the container
6. Repeat step 3

## Expected

You'd get no completion because no containers are running.

## Actual

You'd get completion for the non-existing container.

# Version

Emacs built yesterday from master, commit
94ba1b097ed12b9b77ecef4899c18b46b7e2dd36

Message #8 received at 76950 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: 76950 <at> debbugs.gnu.org
Subject: Re: bug#76950: tramp caches non-existing podman containers
Date: Tue, 11 Mar 2025 20:22:47 +0100

Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:

Hi Konstantin,

> When tramp is used to connect to a container, it provides completion
> based on what containers are currently running. However, after
> containers exit, the completion annoyingly still enlists those dead
> containers.
>
> # Steps to reproduce
>
> 1. Run any container, e.g.: `podman run --rm -it ubuntu:24.04`
> 2. Start Emacs as `emacs -Q --eval "(require 'tramp)"`
> 3. Press `C-x C-f /podman:`, then press TAB to complete the minibuffer
> text to container name (it should get completed).
> 4. Cancel with C-g
> 5. Exit the container
> 6. Repeat step 3
>
> ## Expected
>
> You'd get no completion because no containers are running.
>
> ## Actual
>
> You'd get completion for the non-existing container.

See the Tramp manual, (info "(tramp) File name completion")

--8<---------------cut here---------------start------------->8---
   Remote hosts previously visited or hosts whose connections are kept
persistently (*note Connection caching::) will be included in the
completion lists.  If you want to suppress this completion because there
are invalid entries in the persistency file, for example if the host
configuration changes often, or if you plug your laptop to different
networks frequently, you can set the user option
‘tramp-completion-use-cache’ to ‘nil’.
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.

Message #11 received at 76950 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 76950 <at> debbugs.gnu.org
Subject: Re: bug#76950: tramp caches non-existing podman containers
Date: Tue, 11 Mar 2025 22:28:47 +0300

On Tue, 2025-03-11 at 20:22 +0100, Michael Albinus wrote:
> Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:
> 
> Hi Konstantin,
> 
> > When tramp is used to connect to a container, it provides
> > completion
> > based on what containers are currently running. However, after
> > containers exit, the completion annoyingly still enlists those dead
> > containers.
> > 
> > # Steps to reproduce
> > 
> > 1. Run any container, e.g.: `podman run --rm -it ubuntu:24.04`
> > 2. Start Emacs as `emacs -Q --eval "(require 'tramp)"`
> > 3. Press `C-x C-f /podman:`, then press TAB to complete the
> > minibuffer
> > text to container name (it should get completed).
> > 4. Cancel with C-g
> > 5. Exit the container
> > 6. Repeat step 3
> > 
> > ## Expected
> > 
> > You'd get no completion because no containers are running.
> > 
> > ## Actual
> > 
> > You'd get completion for the non-existing container.
> 
> See the Tramp manual, (info "(tramp) File name completion")
> 
> --8<---------------cut here---------------start------------->8---
>    Remote hosts previously visited or hosts whose connections are
> kept
> persistently (*note Connection caching::) will be included in the
> completion lists.  If you want to suppress this completion because
> there
> are invalid entries in the persistency file, for example if the host
> configuration changes often, or if you plug your laptop to different
> networks frequently, you can set the user option
> ‘tramp-completion-use-cache’ to ‘nil’.
> --8<---------------cut here---------------end--------------->8---

Thanks! Note though that your workaround is about disabling cache for
tramp globally, so isn't useful. But thanks anyway 😊

Message #14 received at 76950 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 76950 <at> debbugs.gnu.org
Subject: Re: bug#76950: tramp caches non-existing podman containers
Date: Tue, 11 Mar 2025 22:45:18 +0300

Figured, I'd clarify for people who don't work with containerization:
the docker and podman completion is about auto-generated names like
vibrant_hopper, frosty_northcutt, etc. Caching them has no use
whatsoever, because:

1. The command that receives possible completions always fetches the
current list, so even if cached containers still exist, the cache only
wastes space.
2. When containers quit, the names become useless (the bug).

So cache should not be working at all for both Podman and Docker.

Message #17 received at 76950 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: 76950 <at> debbugs.gnu.org
Subject: Re: bug#76950: tramp caches non-existing podman containers
Date: Wed, 12 Mar 2025 13:36:06 +0100

Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:

Hi Konstantin,
 
>> --8<---------------cut here---------------start------------->8---
>>    Remote hosts previously visited or hosts whose connections are
>> kept
>> persistently (*note Connection caching::) will be included in the
>> completion lists.  If you want to suppress this completion because
>> there
>> are invalid entries in the persistency file, for example if the host
>> configuration changes often, or if you plug your laptop to different
>> networks frequently, you can set the user option
>> ‘tramp-completion-use-cache’ to ‘nil’.
>> --8<---------------cut here---------------end--------------->8---
>
> Thanks! Note though that your workaround is about disabling cache for
> tramp globally, so isn't useful. But thanks anyway 😊

Well, using the global tramp-completion-use-cache is not intended as
workaround, but as solution (so far). But I see your point.

Best regards, Michael.

Message #20 received at 76950 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: 76950 <at> debbugs.gnu.org
Subject: Re: bug#76950: tramp caches non-existing podman containers
Date: Wed, 12 Mar 2025 13:42:50 +0100

[Message part 1 (text/plain, inline)]

Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:

Hi Konstantin,

> Figured, I'd clarify for people who don't work with containerization:
> the docker and podman completion is about auto-generated names like
> vibrant_hopper, frosty_northcutt, etc. Caching them has no use
> whatsoever, because:

That's not always the case. You can run a container with the
'--name="NAME"' argument.

> 1. The command that receives possible completions always fetches the
> current list, so even if cached containers still exist, the cache only
> wastes space.

Right. It doesn't make sense to offer container names which do not run,
but are cached.

> 2. When containers quit, the names become useless (the bug).

Not always (see above).

> So cache should not be working at all for both Podman and Docker.

Well, I've assembled a patch with disables completion of cached container
names for the docker, dockercp, podman and podmancp methods. See
appended. Could you, pls test?

It can be extended for other methods easily, which are offered by
tramp-container.el.

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

Message #23 received at 76950 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 76950 <at> debbugs.gnu.org
Subject: Re: bug#76950: tramp caches non-existing podman containers
Date: Wed, 12 Mar 2025 17:07:50 +0300

On Wed, 2025-03-12 at 13:42 +0100, Michael Albinus wrote:
> Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:
> 
> Hi Konstantin,
> 
> > Figured, I'd clarify for people who don't work with
> > containerization:
> > the docker and podman completion is about auto-generated names like
> > vibrant_hopper, frosty_northcutt, etc. Caching them has no use
> > whatsoever, because:
> 
> That's not always the case. You can run a container with the
> '--name="NAME"' argument.
> 
> > 1. The command that receives possible completions always fetches
> > the
> > current list, so even if cached containers still exist, the cache
> > only
> > wastes space.
> 
> Right. It doesn't make sense to offer container names which do not
> run,
> but are cached.
> 
> > 2. When containers quit, the names become useless (the bug).
> 
> Not always (see above).
> 
> > So cache should not be working at all for both Podman and Docker.
> 
> Well, I've assembled a patch with disables completion of cached
> container
> names for the docker, dockercp, podman and podmancp methods. See
> appended. Could you, pls test?
> 
> It can be extended for other methods easily, which are offered by
> tramp-container.el.

Thank you! The patch seems to work, but it behaves a bit oddly. If I go
over steps-to-reproduce, I quit container, do C-x C-f and check
containers name not there anymore… I still see it cached! However, if I
do that again in a few seconds, the container disappears.

It's as if cache still there, but it gets removed after a delay.

Other than that, the patch is definitely an improvement, so if it's not
clear why this "cache removal with delay" happens, I think patch still
may be worth installing.

Message #26 received at 76950 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: 76950 <at> debbugs.gnu.org
Subject: Re: bug#76950: tramp caches non-existing podman containers
Date: Wed, 12 Mar 2025 15:20:21 +0100

Konstantin Kharlamov <Hi-Angel <at> yandex.ru> writes:

Hi Konstantin,
 
> Thank you! The patch seems to work, but it behaves a bit oddly. If I go
> over steps-to-reproduce, I quit container, do C-x C-f and check
> containers name not there anymore… I still see it cached! However, if I
> do that again in a few seconds, the container disappears.
>
> It's as if cache still there, but it gets removed after a delay.

My patch doesn't cleanup the cache. It just suppresses the use of the
cache for host name completion.

The (file) cache expires due to remote-file-name-inhibit-cache. Likely
you use the default value, 10 seconds. This is independent of my patch.

> Other than that, the patch is definitely an improvement, so if it's not
> clear why this "cache removal with delay" happens, I think patch still
> may be worth installing.

I'll polish it a little bit, will push it later.

Best regards, Michael.

Message #31 received at 76950-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: 76950-done <at> debbugs.gnu.org
Subject: Re: bug#76950: tramp caches non-existing podman containers
Date: Wed, 12 Mar 2025 20:59:10 +0100

Version: 31.1

Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi Konstantin,

>> Other than that, the patch is definitely an improvement, so if it's not
>> clear why this "cache removal with delay" happens, I think patch still
>> may be worth installing.
>
> I'll polish it a little bit, will push it later.

I've pushed it to master, closing the bug.

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.