[jauntywundrkind]

Overall this looks really good but it also obfuscates whether how & where this really integrates with systemd.

Maybe everything is this easy & good. Maybe this is an /etc/systems/system/WordPress.quadlet file, part & parcel to everything else in the systemd-verse. But it doesn't say clearly whether it is or isn't. It's an acontextual example.

I think it's powerful tech either way, but so much of the explanation is missing here. It focuses on the strengths, on what is consistent, but isn't discussing the overall picture of how things slot together.

In many ways I think this is the most interesting frontier for systemd. It's supposedly not a monolith, supposedly modular, it so far that has largely meant that components are modular, optional. You don't need to run the pretty fine systemd-resolvd, for example. But what k8s has done is make handling resources modular, and that feels like the broad idea here. But it seems dubious that systemd really has that extensibility builtin; it seems likely that podman quadlet is a secondary entirely unrelated controller, ape-ing what systemd does without integrating at all. It seems likely that's not a podman-quadlet fault: it's likely a broad systemd inflexibility.

Could be wrong here. But the article seems to offer no support that there is any integration, no support that this systemd-alike integrates or extends at all. Quadlet seem to be a parallel and similar-looking tech, with deep parallel, but those parallels from what I read here are handcrafted. Jt's not quadlet that fails here to be great, ut systemd not offering actual deep integration options.

[goku12]

Quadlet uses SystemD Generators [1] feature. Generators are a way to convert non-systemd-native configuration extensions (like containers, volumes and networks in case of quadlets) into regular systemd-native configuration like service unit-files. The quadlet generator converts the podman extension for systemd into regular service file that you can examine yourself. Non-root podman container services are in /run/user/<uid>/systemd/generator. Here is a blog post that describes the design in detail (slightly dated): [2]

[1] https://www.freedesktop.org/software/systemd/man/systemd.gen...

[2] https://blogs.gnome.org/alexl/2021/10/12/quadlet-an-easier-w...

[yrro]

The reason it works at all is because of systemd's extension mechanisms.

Maybe this helps. Picking a random example container unit...

    [root@xoanon ~]# cat /etc/containers/systemd/oxidized.container 
    
    [Unit]
    Description=Oxidized
    
    [Service]
    ExecStartPre=/usr/bin/rm -f /var/local/oxidized/pid
    
    [Container]
    Exec=oxidized
    Image=docker.io/oxidized/oxidized
    User=972
    Group=971
    NoNewPrivileges=yes
    ReadOnly=yes
    RunInit=yes
    VolatileTmp=yes
    Volume=/var/local/oxidized:/var/local/oxidized:rw,Z
    PodmanArgs=--cpus=1
    PodmanArgs=--memory=256m
    Label=io.containers.autoupdate=registry
    Environment=OXIDIZED_HOME=/var/local/oxidized
    
    [Service]
    Restart=always
    
    [Install]
    WantedBy=multi-user.target

After a `systemctl daemon-reload` an `oxidized` service springs into being.

    [root@xoanon ~]# systemctl status oxidized
    ● oxidized.service - Oxidized
       Loaded: loaded (/etc/containers/systemd/oxidized.container; generated)
       Active: active (running) since Sat 2023-09-23 09:53:11 UTC; 2 days ago
      Process: 221712 ExecStopPost=/usr/bin/rm -f /run/oxidized.cid (code=exited, status=219/CGROUP)
      Process: 221711 ExecStopPost=/usr/bin/podman rm -f -i --cidfile=/run/oxidized.cid (code=exited, status=219/CGROUP)
      Process: 221713 ExecStartPre=/usr/bin/rm -f /var/local/oxidized/pid (code=exited, status=0/SUCCESS)
     Main PID: 221799 (conmon)
        Tasks: 8 (limit: 98641)
       Memory: 169.0M
       CGroup: /system.slice/oxidized.service
               ├─libpod-payload-b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390
               │ ├─221801 /run/podman-init -- oxidized
               │ └─221803 puma 3.11.4 (tcp://127.0.0.1:8888) [/]
               └─runtime
                 └─221799 /usr/bin/conmon --api-version 1 -c b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390 -u b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390 -r /usr/bin/crun -b /var/lib/containers/storage/overlay-containers/b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390/userdata -p /run/containers/storage/overlay-containers/b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390/userdata/pidfile -n systemd-oxidized --exit-dir /run/libpod/exits --full-attach -l passthrough --log-level warning --runtime-arg --log-format=json --runtime-arg --log --runtime-arg=/run/containers/storage/overlay-containers/b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390/userdata/oci-log --conmon-pidfile /run/containers/storage/overlay-containers/b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390/userdata/conmon.pid --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /var/lib/containers/storage --exit-command-arg --runroot --exit-command-arg /run/containers/storage --exit-command-arg --log-level --exit-command-arg warning --exit-command-arg --cgroup-manager --exit-command-arg systemd --exit-command-arg --tmpdir --exit-command-arg /run/libpod --exit-command-arg --network-config-dir --exit-command-arg --exit-command-arg --network-backend --exit-command-arg cni --exit-command-arg --volumepath --exit-command-arg /var/lib/containers/storage/volumes --exit-command-arg --transient-store=false --exit-command-arg --runtime --exit-command-arg /usr/bin/crun --exit-command-arg --storage-driver --exit-command-arg overlay --exit-command-arg --storage-opt --exit-command-arg overlay.mountopt=nodev,metacopy=on --exit-command-arg --events-backend --exit-command-arg file --exit-command-arg container --exit-command-arg cleanup --exit-command-arg --rm --exit-command-arg b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390Learn more at: 
    
    Sep 26 00:03:05 xoanon oxidized[221803]: I, [2023-09-26T00:03:05.807594 #2]  INFO -- : Configuration updated for /192.168.89.5
    Sep 26 01:03:15 xoanon oxidized[221803]: I, [2023-09-26T01:03:15.083603 #2]  INFO -- : Configuration updated for /192.168.89.5
    Sep 26 02:03:24 xoanon oxidized[221803]: I, [2023-09-26T02:03:24.414821 #2]  INFO -- : Configuration updated for /192.168.89.5
    Sep 26 03:03:33 xoanon oxidized[221803]: I, [2023-09-26T03:03:33.677828 #2]  INFO -- : Configuration updated for /192.168.89.5
    Sep 26 04:03:42 xoanon oxidized[221803]: I, [2023-09-26T04:03:42.983589 #2]  INFO -- : Configuration updated for /192.168.89.5
    Sep 26 05:03:52 xoanon oxidized[221803]: I, [2023-09-26T05:03:52.297830 #2]  INFO -- : Configuration updated for /192.168.89.5
    Sep 26 06:04:01 xoanon oxidized[221803]: I, [2023-09-26T06:04:01.637348 #2]  INFO -- : Configuration updated for /192.168.89.5
    Sep 26 07:04:10 xoanon oxidized[221803]: I, [2023-09-26T07:04:10.935352 #2]  INFO -- : Configuration updated for /192.168.89.5
    Sep 26 08:04:20 xoanon oxidized[221803]: I, [2023-09-26T08:04:20.199651 #2]  INFO -- : Configuration updated for /192.168.89.5
    Sep 26 09:04:29 xoanon oxidized[221803]: I, [2023-09-26T09:04:29.553178 #2]  INFO -- : Configuration updated for /192.168.89.5

During the daemon-reload, systemd invoked /usr/lib/systemd/system-generators/podman-system-generator, which read the files in /etc/podman/systemd and synthesized a systemd service for each of then, which it dropped into /run/systemd/generator, which is one of the directories from which systemd loads unit files.

Far from being a parallel service control mechanism (á la Docker), this is proper separation of concerns: the service is a first-class systemd service like any other; the payload of the service is the podman command that runs the container. We can introspect this a bit to examine the systemd unit that was generated:

    [root@xoanon ~]# systemctl cat oxidized
    # /run/systemd/generator/oxidized.service
    # Automatically generated by /usr/lib/systemd/system-generators/podman-system-generator
    # 
    [Unit]
    Description=Oxidized
    SourcePath=/etc/containers/systemd/oxidized.container
    RequiresMountsFor=%t/containers
    RequiresMountsFor=/var/local/oxidized

    [Service]
    ExecStartPre=/usr/bin/rm -f /var/local/oxidized/pid
    Restart=always
    Environment=PODMAN_SYSTEMD_UNIT=%n
    KillMode=mixed
    ExecStopPost=-/usr/bin/podman rm -f -i --cidfile=%t/%N.cid
    ExecStopPost=-rm -f %t/%N.cid
    Delegate=yes
    Type=notify
    NotifyAccess=all
    SyslogIdentifier=%N
    ExecStart=/usr/bin/podman run --name=systemd-%N --cidfile=%t/%N.cid --replace --rm --log-driver passthrough --runtime /usr/bin/crun --cgroups=split --init --sdnotify=conmon -d --security-opt=no-new-privileges --read-only --user 972:971 -v /var/local/oxidized:/var/local/oxidized:rw,Z --env OXIDIZED_HOME=/var/local/oxidized --label io.containers.autoupdate=registry --cpus=1 --memory=256m docker.io/oxidized/oxidized oxidized
    
    [X-Container]
    Exec=oxidized
    Image=docker.io/oxidized/oxidized
    User=972
    Group=971
    NoNewPrivileges=yes
    ReadOnly=yes
    RunInit=yes
    VolatileTmp=yes
    Volume=/var/local/oxidized:/var/local/oxidized:rw,Z
    PodmanArgs=--cpus=1
    PodmanArgs=--memory=256m
    Label=io.containers.autoupdate=registry
    Environment=OXIDIZED_HOME=/var/local/oxidized
    
    [Install]
    WantedBy=multi-user.target

No deep magic, just the pleasant feeling you get when you see layered systems interacting together without cross-cutting.

You can learn more about the systemd generator extension mechanism at: https://www.freedesktop.org/software/systemd/man/systemd.gen...