Problem
Currently the installer configures podman services as systemd user scoped services. 
This has an important drawback because the service is automatically stopped when the session finishes. To prevent this behavior, the installer enables the systemd lingering to ensure the service is running in the background all the time. 

This approach has some identified problems:
1. systemd cache some process information like for example the groups, so to make effective some changes the session and processes must be restarted which might end into an unnecessary downtime or loss of data. For example, to be able to set the "journald" group to allow EDA to fetch logs from activations, has been proposed to disable/enable the lingering as solution. 
Refs: 

• https://issues.redhat.com/browse/AAP-40247
• https://issues.redhat.com/browse/AAP-40144

2. Commented by rhn-support-jamarsha in Awx there is also problems like the reported one in https://access.redhat.com/solutions/7072907 which is necessary to run "podman system reset" which destroy current running pods (probably in this case the solution of enabling/disabling the lingering can be applied too)

Why
In the end all these services are actually system services, daemons that the system have to be running all the time for the correct working of AAP. Configuring an user scoped service and enabling the lingering might not be the right approach for what they actually are. 

Solution proposed
These services can be configured as system-wide services. 
The user scoped service is not a requirement for rootless podman. 
Systemd already allows to define in the service script the user and group that is used for the process. This is a common approach for system-wide services that must be executed by a different user than root.  https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#User= 

Example:

# aap-podman.service
This is an example taking as reference the current script, not actually tested. 

[Unit]
Description=Podman API Service
Requires=aap-podman.socket
After=aap-podman.socket
Documentation=man:podman-system-service(1)
StartLimitIntervalSec=0

[Service]

##### 
User=ansible 
Group=ansible 
#####

Delegate=true
Type=exec
KillMode=process
Environment=LOGGING="--log-level=info"
ExecStart=/usr/bin/podman $LOGGING system service

[Install]
WantedBy=default.target

These services are configured and managed by the root user as system services while are running under user configured for it and there is no need to lead with lingering and we would be avoiding some of the issues of the current approach.