Portable and persistent systemd units

[jpf91]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

I have some services which perform some expensive initial setup and for some this setup shouldn't even be run unattended. Because of that, I can't use the podman systemd generate --new units, as I don't want to create new containers on each restart. OTOH the podman systemd generate services are not portable: I can't really use them on coreos, as the initial setup does not have any containers initialized. I came up with these unit template for myself, which I hope doesn't have any hidden issues:

[Unit]
Description=Podman test.service
Wants=network.target
After=network-online.target

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
ExecStartPre=/bin/rm -f %t/test-fedora.pid
ExecStartPre=-/bin/podman create \
  --log-driver journald \
  --conmon-pidfile %t/test-fedora.pid \
  --label "io.containers.autoupdate=image" \
  --cgroups=no-conmon \
  --name test-fedora \
  registry.fedoraproject.org/fedora-minimal:33 /bin/bash -c "while true; do sleep 10; echo foo; done"
ExecStart=/usr/bin/podman start test-fedora
ExecStop=/usr/bin/podman stop --ignore test-fedora -t 10
PIDFile=%t/test-fedora.pid
KillMode=none
Type=forking

[Install]
WantedBy=multi-user.target default.target

Here if "test-fedora" does not exists, a new container is created. Otherwise the create command fails (and is ignored) and the unit calls start anyway. Maybe it'd make sense to include a stop/kill before the create, just to be safe?

BTW: I think --log-driver journald should really be included in all systemd units.

[vrothberg]

Thanks for opening the issue and apologies for the long silence, we've been super busy.

--label "io.containers.autoupdate=image" \

That would not work. podman auto-update restart the systemd unit, so even if there's a newer image the old container would continue running.

I am open to add a new template to generate systemd but the mentioned use case does not seem sufficiently generic to me. If container creation doesn't work unattended, then it seems like a red flag for automation to me.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@vrothberg Where do we stand on this one?

[vrothberg]

@vrothberg Where do we stand on this one?

No progress since we're in bug-scrubbing mode. But I am also not yet convinced about the idea. The underlying assumption would be that podman create is a bottle neck and I have not seen evidence for it yet.

One thing, I do want to tackle now is enforcing the journald logger in the units.

[vrothberg]

I am going to close this issue.

@rhatdan is currently working on making journald the the default log-driver.