It happend again:

Sep 25 19:48:37 servername su[829912]: (to exim) root on none
Sep 25 19:48:37 servername systemd[1]: Created slice User Slice of UID 93.
Sep 25 19:48:37 servername systemd[1]: Starting User Runtime Directory /run/user/93...
Sep 25 19:48:37 servername systemd[1]: Started User Runtime Directory /run/user/93.
Sep 25 19:48:37 servername systemd[1]: Starting User Manager for UID 93...
Sep 25 19:48:37 servername systemd[829917]: Condition check resulted in Mark boot as successful after the user session has run 2 minutes being skipped.
Sep 25 19:48:37 servername systemd[829917]: Reached target Paths.
Sep 25 19:48:37 servername systemd[829917]: Reached target Timers.
Sep 25 19:48:37 servername systemd[829917]: Starting D-Bus User Message Bus Socket.
Sep 25 19:48:37 servername systemd[829917]: Listening on D-Bus User Message Bus Socket.
Sep 25 19:48:37 servername systemd[829917]: Reached target Sockets.
Sep 25 19:48:37 servername systemd[829917]: Reached target Basic System.
Sep 25 19:48:37 servername systemd[1]: Started User Manager for UID 93.
Sep 25 19:48:37 servername systemd[1]: Started Session c89 of user exim.
Sep 25 19:48:37 servername systemd[829917]: Reached target Main User Target.
Sep 25 19:48:37 servername systemd[829917]: Startup finished in 106ms.
Sep 25 19:48:38 servername systemd[1]: session-c89.scope: Succeeded.
Sep 25 19:48:38 servername su[829936]: (to exim) root on none
Sep 25 19:48:38 servername systemd[1]: Started Session c90 of user exim.
Sep 25 19:48:38 servername su[829949]: (to exim) root on none
Sep 25 19:48:38 servername systemd[1]: Started Session c91 of user exim.
Sep 25 19:48:38 servername systemd[1]: session-c91.scope: Succeeded.
Sep 25 19:48:38 servername su[829958]: (to exim) root on none
Sep 25 19:48:38 servername systemd[1]: Started Session c92 of user exim.
Sep 25 19:48:38 servername systemd[1]: session-c92.scope: Succeeded.
Sep 25 19:48:38 servername su[829967]: (to exim) root on none
Sep 25 19:48:38 servername systemd[1]: Started Session c93 of user exim.
Sep 25 19:48:38 servername systemd[1]: session-c93.scope: Succeeded.
Prozekontrolle: Fr 25. Sep 19:49:01 CEST 2020

1. prozess=829944 name=gpg-agent username=exim   ###ERROR###
:



/var/log/security has this to say:


Sep 25 19:48:37 servername systemd[829917]: pam_unix(systemd-user:session): session opened for user exim by (uid=0)
Sep 25 19:48:37 servername su[829912]: pam_unix(su:session): session opened for user exim by (uid=0)
Sep 25 19:48:38 servername su[829912]: pam_unix(su:session): session closed for user exim
Sep 25 19:48:38 servername su[829936]: pam_unix(su:session): session opened for user exim by (uid=0)
Sep 25 19:48:38 servername su[829936]: pam_unix(su:session): session closed for user exim
Sep 25 19:48:38 servername su[829949]: pam_unix(su:session): session opened for user exim by (uid=0)
Sep 25 19:48:38 servername su[829949]: pam_unix(su:session): session closed for user exim
Sep 25 19:48:38 servername su[829958]: pam_unix(su:session): session opened for user exim by (uid=0)
Sep 25 19:48:38 servername su[829958]: pam_unix(su:session): session closed for user exim
Sep 25 19:48:38 servername su[829967]: pam_unix(su:session): session opened for user exim by (uid=0)
Sep 25 19:48:38 servername su[829967]: pam_unix(su:session): session closed for user exim

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

out of the sudden...


Feb  3 08:06:06 s113 systemd[1]: Created slice User Slice of UID 93.

uid=93(exim) gid=93(exim) Gruppen=93(exim),12(mail),176(ats)

exim     1078872  0.0  0.0 365096  1256 ?        Ss   08:06   0:00 gpg-agent --homedir /var/spool/exim/.gnupg --use-standard-socket --daemon

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

> Component: exim → systemd

Why did you assign this to systemd? There is something in the exim service stack which
causes it to (I'm guessing here), start a pam session and trigger other services...
This needs to be figured out from the exim side. I don't know anything about exim is
configured in Fedora.

Because exim did not start the gpg-agent.

We are talking about a mailserver running exim for 100 days without restart and then, without any incoming/outgoing email,
it shall start a gpg-agent which it does not need? 

According to the logs, it's clearly systemd which starts a normal usersession for a system account, which is not meant to have one, and thats the bug we are talking about.

If exim would need a gpg-agent, it would be started before exim, the agent-pids would be exported to be used by exim and underlying gpg usages.
In the scenario of this bugreport, gpg-agent have been side-started without any use to exim itself, as it does not know about it.

I repeat my inital request:

Systemd, do not start usersessions for non-user-accounts.

> According to the logs, it's clearly systemd which starts a normal usersession for a system account, which is not meant to have one, and thats the bug we are talking about.

Yes, that seems to be the important part. The question is why is systemd starting a user session
for exim4? Something told it to start it, and that is the real bug. My guess would be that 
exim4 somehow uses 'su' to switch users, and this pulls in the pam stack, which instructs systemd
to start the user session. But this is just a wild guess, since I don't know anything about how
exim4 does things. As I said, this needs to be looked at by somebody who understand the exim4 setup.

You can probably do 'systemctl mask user@<uid of exim4>' to prevent the user session from starting.
But this is just an ugly work-around.

It's a server, i don't care if it's ugly from a desktop perspective :)

I will try it out. Still, the real question is, what is the real trigger of it. Maybe a cron? but those crons would run daily or even hourly, and those starts seem to be happen at random.

I talked to Heiko S. from the exim dev team and he has no clue why exim would give systemd a hint to start that usersession, in special, months after the initial start of the master process and no internal or external activity.

Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days