Hmm, I think it's actually kinda nice having these messages in there for regular sessions, but you are right, for cronjobs this sucks.

I'll now downgrade the messages to LOG_DEBUG if the session has neither a tty nor an X server attached, but leave it on LOG_INFO otherwise. That should fix the issue for you but keep the message around for regular logins.

Fixed now upstream, will upload a fixed version to f16 soon.

systemd-35-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/systemd-35-1.fc16

Package systemd-35-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-35-1.fc16'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/systemd-35-1.fc16
then log in and leave karma (feedback).

systemd-35-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

systemd-37-3.fc16.x86_64 is still logging excessively..

Nov 16 13:18:01 firewall systemd-logind[587]: New session 828 of user root.
Nov 16 13:18:39 firewall systemd-logind[587]: Removed session 828.
Nov 16 13:19:02 firewall systemd-logind[587]: New session 829 of user root.
Nov 16 13:19:40 firewall systemd-logind[587]: Removed session 829.
Nov 16 13:20:01 firewall systemd-logind[587]: New session 830 of user root.
....

Seeing same problem here, also with 37-3 on FC16.

Agree proposed solution in comment #2 would be best approach - would it be possible to set the two log-level options via one of the config files in /etc/systemd - system.conf, perhaps?  I'd really like to be able to set the facility of the entries generated by cronjobs to "cron", leave the rest on "syslog-or-kmsg" and be able to set log levels independently.

systemd-37-3.fc16.x86_64
/var/log/messages:

Nov 18 17:00:01 w systemd-logind[1002]: New session 185 of user root.
Nov 18 17:00:01 w systemd-logind[1002]: Removed session 185.
Nov 18 17:01:01 w systemd-logind[1002]: New session 187 of user root.
Nov 18 17:01:01 w systemd-logind[1002]: New session 186 of user root.
Nov 18 17:01:02 w systemd-logind[1002]: Removed session 186.
Nov 18 17:01:08 w systemd-logind[1002]: Removed session 187.
Nov 18 17:02:01 w systemd-logind[1002]: New session 188 of user root.
Nov 18 17:02:02 w systemd-logind[1002]: Removed session 188.
Nov 18 17:03:01 w systemd-logind[1002]: New session 189 of user root.
Nov 18 17:03:01 w systemd-logind[1002]: Removed session 189.
Nov 18 17:04:01 w systemd-logind[1002]: New session 190 of user root.

(In reply to comment #1)
> I'll now downgrade the messages to LOG_DEBUG if the session has neither a tty
> nor an X server attached, but leave it on LOG_INFO otherwise. That should fix
> the issue for you but keep the message around for regular logins.

Unfortunately cronie manages to confuse this filter by setting PAM_TTY.
In src/security.c:cron_start_pam():
  retcode = pam_set_item(pamh, PAM_TTY, "cron");

I don't think it should do that.
From 'man pam_set_item':

       PAM_TTY
           The terminal name: prefixed by /dev/ if it is a device file;
           for graphical, X-based, applications the value for this item
           should be the $DISPLAY variable.

Michal, this has been being set for a very long time and it cannot be changed as user configurations (access.conf and others) might very well depend on it. Why is it such a problem now?

For example sshd sets the PAM_TTY to 'ssh' for similar reasons because it does not know the tty at the point where PAM modules are called.

I see. If it cannot ever be changed in cron, then we might want to treat PAM_TTY="cron" specially in logind and/or pam_systemd.

In the PAM module we already fixup tty if it looks like a X11 display name, so
adding a fixup for cron may be acceptable.

Upstream:
http://cgit.freedesktop.org/systemd/commit/?id=1a4459d63323cdfdb8751077e555ddbbf80564b1

Can we please make this a user configurable option whether we want such logging at all or not?  Thanks.

(In reply to comment #13)

Although there is currently no config file option for that, it is possible to set the logging level and target of systemd-logind using the same environment variables that systemd itself understands. So you can add a unit file /etc/systemd/system/systemd-logind.service:

.include /lib/systemd/system/systemd-logind.service
[Service]
Environment=SYSTEMD_LOG_LEVEL=warning

... to suppress the messages (they are logged at level 'info').

*** Bug 770014 has been marked as a duplicate of this bug. ***

(In reply to comment #14)
> 
> Although there is currently no config file option for that, it is possible to
> set the logging level and target of systemd-logind using the same environment
> variables that systemd itself understands.

I followed a recipe from comment #14, did after edits 'systemctl daemon-reload'
and 'systemctl status systemd-logind.service' shows now:

systemd-logind.service - Login Service
          Loaded: loaded (/etc/systemd/system/systemd-logind.service; static)
          Active: active (running) since Sun, 25 Dec 2011 10:10:41 -0700; 1 day and 2h ago
        Main PID: 13219 (systemd-logind)
          CGroup: name=systemd:/system/systemd-logind.service
                  └ 13219 /lib/systemd/systemd-logind

I am afraid that I still see in log files from every cron job: "New session ...  Removed session ...".  So either this is wrong level or I am still missing something here.  Looking with strings at /lib/systemd/systemd-logind a name 'SYSTEMD_LOG_LEVEL' seems to be what should be used. 

This is on a fully updated Fedora 16 installation.

(In reply to comment #16)
> Active: active (running) since Sun, 25 Dec 2011 10:10:41 -0700;
> 1 day and 2h ago

Did you restart systemd-logind.service?

(In reply to comment #17)
> (In reply to comment #16)
> > Active: active (running) since Sun, 25 Dec 2011 10:10:41 -0700;
> > 1 day and 2h ago
> 
> Did you restart systemd-logind.service?

Well, status claims

          Loaded: loaded (/etc/systemd/system/systemd-logind.service; static)

and this is a file with SYSTEMD_LOG_LEVEL set.

After 'systemctl restart systemd-logind.service' only you see:

          Loaded: loaded (/lib/systemd/system/systemd-logind.service; static)

which is not that one which was modified.  Apparently you best reboot after such change (1/2 :-).

The other catch is that when everything in sight was restarted then this is preventing not only "New session" cron noise but kills that information everywhere.

(In reply to comment #18)
> Well, status claims
> 
>           Loaded: loaded (/etc/systemd/system/systemd-logind.service; static)
> 
> and this is a file with SYSTEMD_LOG_LEVEL set.
> 
> After 'systemctl restart systemd-logind.service' only you see:
> 
>           Loaded: loaded (/lib/systemd/system/systemd-logind.service; static)

Not on my system. It is really strange if the restart action causes the unit to be reloaded from a different file. I cannot reproduce this.

> The other catch is that when everything in sight was restarted then this is
> preventing not only "New session" cron noise but kills that information
> everywhere.

You missed the point. The cron noise is fixed by the upstream commit I linked to.
The trick with SYSTEMD_LOG_LEVEL is meant only for those who don't want the session information to be logged at all (even for normal user logins).

systemd-37-6.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/systemd-37-6.fc16

Package systemd-37-6.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-37-6.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-6.fc16
then log in and leave karma (feedback).

Did as in #21, but:

Jan 13 03:45:51 sufplan3 systemd[1]: Reexecuting.
Jan 13 03:45:52 sufplan3 systemd[1]: systemd 37 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +SYSVINIT +LIBCRYPTSETUP; fedora)
Jan 13 04:01:34 sufplan3 systemd-logind[24413]: User root logged out.
Jan 13 05:01:01 sufplan3 systemd-logind[24413]: New user root logged in

So what now?

You may need to restart systemd-logind.service

Did so but:

Jan 14 04:49:02 recorder systemd-logind[18804]: User mythtv logged out.
Jan 14 05:04:01 recorder systemd-logind[18804]: New user mythtv logged in.
Jan 14 07:05:01 recorder systemd-logind[18804]: User mythtv logged out.

Also root:

Jan 14 04:01:33 sufplan3 systemd-logind[29319]: User root logged out.
Jan 14 05:01:01 sufplan3 systemd-logind[29319]: New user root logged in.

This really is quite a shocking message to see appear in the main system log and it is my hope this is addressed quickly.  Seeing 'root' login to a fresh install moments after bringing the machine online nearly gave me a heart attack.

downgraded the 'user' messages to debug:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=1637a8be5570dff7ce402451240b28ddb54e5dca

Package systemd-37-8.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-37-8.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-8.fc16
then log in and leave karma (feedback).

yum update systemd:

No Packages marked for Update

So now?

ah, updates-testing.

systemd-37-11.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.