Podman Desktop service installation vs. Podman systemd service installation

[afbjorklund]

Bug description

The Podman Desktop installation of the podman service runs "forever" (0):

    let command = 'podman';
    let args = ['system', 'service', '--time=0'];

While the regular systemd service installation shuts down after 5 seconds:

ExecStart=@@PODMAN@@ $LOGGING system service

Shouldn't the podman installation handle this ?

That is: the podman.socket and podman.service

systemctl enable podman.socket

systemctl start podman.socket

Operating system

Linux

Installation Method

Flathub (Linux)

Version

1.1.0

Steps to reproduce

No response

Relevant log output

No response

Additional context

Podman is supposed to not run a daemon, but instead be socket-activated and start the service "on-demand"

  -t, --time uint     Time until the service session expires in seconds.  Use 0 to disable the timeout (default 5)

[benoitf]

I think there is another issue saying that we should not try to start a socket if there is already one

Socket is always started to be able to community through the rest API

[afbjorklund]

Socket is always started to be able to community through the rest API

But it should probably be started using systemctl --user start podman.socket

[benoitf]

I don't know if it should be an alternative way (option) or the default way (system service call removed))

[afbjorklund]

@benoitf note that there is a "ping" going from Podman Desktop, that keeps starting the podman.service

So the socket (podman.sock) is alive and well, and waiting for actual connections before it starts the service.
But then this fake call keeps launching the service (podman.service), even though it doesn't "do" anything?

So even without the infinite timeout, this effectively makes it into a "daemon" - even being advertised as not:
"Daemon-less and using the fastest technologies to make Podman Desktop fast to use." (service == daemon)

Anyway, I don't think Podman Desktop should start the service - but leave this to the Podman installation.

[benoitf]

AFAIK, if you don't want something being enabled it should be flagged as options.

One option to disable the ping and anothe option to select how to start the service: systemd, system service or 'do nothing'

on macOS and Windows there is a running VM to handle the call so having podman started or not is not so 'daemon-less'

[afbjorklund]

The ping is fine for something like Docker (Engine), that keeps running as a daemon in the background.
In fact, it even expects to be be pinged for every single call - since they use it for negotiating API version...

On Mac and Win you still need the VM running (like you say), but it could be "idling" without the process in it ?
The virtual machine might have to be on, but inside it the same rules apply - as long as it is running systemd.

---

On my machine, it takes around 2 seconds to start the service but more like 20ms for a running daemon response.

Your mileage might vary.

time podman --remote version

time docker version

[afbjorklund]

The end result of this, is that if I start Podman Desktop and stop it again - podman --remote is now broken.

This is because it replaced the systemd socket with a temporary one, which was then disconnected upon quit.

Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM
Error: unable to connect to Podman socket: Get "http://d/v3.4.2/libpod/_ping": dial unix ///run/user/1000/podman/podman.sock: connect: connection refused

The only way to get the functionality back again, is to restart it: systemctl --user restart podman.socket

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 6 months. It will be closed in 30 days if no further activity occurs. Please feel free to leave a comment if you believe the issue is still relevant. Thank you for your contributions!

[github-actions]

This issue has been automatically closed because it has not had any further activity in the last 30 days. Thank you for your contributions!