When we go from runlevel 5 to 3 we see:

auditd[13030]: The audit daemon is exiting.

Why?
Afterwards all the audit logging ends up in /var/log/messages until we enter runlevel 5 again (via a reboot in this case).

I'm not sure what the problem is here. If auditing is enabled and and auditd is not running, the kernel printk's it to syslog. That has been the design since the 2.6.6 kernel. As for why the daemon exits when switching runlevels? I have no idea. Its most likely s systemd problem.

Please explain me how to make sure that systemd is the cause or please explain yourself and put the bug through to them.

Well, the audit daemon has no idea that you are going from runlevel 5 to 3. It only reacts to signals being sent to it. Systemd is the only thing that knows a runlevel change is taking place and issues signals to daemons to stop them or start them as appropriate.

We use systemd-204-9.fc19.x86_64.
We see audit exit when going from runlevel 5 to 3.

udo: can you paste the output from 'systemctl show auditd'?

Id=auditd.service
Names=auditd.service
Conflicts=shutdown.target
Before=systemd-update-utmp-shutdown.service systemd-update-utmp-runlevel.service crond.service sshd.service sysinit.target shutdown.target
After=local-fs.target systemd-journald.socket
Description=Security Auditing Service
LoadState=loaded
ActiveState=inactive
SubState=dead
FragmentPath=/usr/lib/systemd/system/auditd.service
UnitFileState=disabled
InactiveExitTimestampMonotonic=0
ActiveEnterTimestampMonotonic=0
ActiveExitTimestampMonotonic=0
InactiveEnterTimestampMonotonic=0
CanStart=yes
CanStop=no
CanReload=yes
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=yes
AllowIsolate=no
DefaultDependencies=no
OnFailureIsolate=no
IgnoreOnIsolate=no
IgnoreOnSnapshot=no
NeedDaemonReload=no
JobTimeoutUSec=0
ConditionTimestampMonotonic=0
ConditionResult=no
Type=simple
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutUSec=1min 30s
TimeoutStartUSec=1min 30s
TimeoutStopUSec=1min 30s
WatchdogUSec=0
WatchdogTimestampMonotonic=0
StartLimitInterval=10000000
StartLimitBurst=5
StartLimitAction=none
ExecStart={ path=/sbin/auditd ; argv[]=/sbin/auditd -n ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }
ExecStartPost={ path=/sbin/auditctl ; argv[]=/sbin/auditctl -R /etc/audit/audit.rules ; ignore_errors=yes ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }
ExecReload={ path=/bin/kill ; argv[]=/bin/kill -HUP $MAINPID ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }
PermissionsStartOnly=no
RootDirectoryStartOnly=no
RemainAfterExit=no
GuessMainPID=yes
MainPID=0
ControlPID=0
Result=success
UMask=0022
LimitCPU=18446744073709551615
LimitFSIZE=18446744073709551615
LimitDATA=18446744073709551615
LimitSTACK=18446744073709551615
LimitCORE=18446744073709551615
LimitRSS=18446744073709551615
LimitNOFILE=4096
LimitAS=18446744073709551615
LimitNPROC=56857
LimitMEMLOCK=65536
LimitLOCKS=18446744073709551615
LimitSIGPENDING=56857
LimitMSGQUEUE=819200
LimitNICE=0
LimitRTPRIO=0
LimitRTTIME=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=50000
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=journal
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SecureBits=0
CapabilityBoundingSet=18446744073709551615
MountFlags=0
PrivateTmp=no
PrivateNetwork=no
SameProcessGroup=no
ControlGroupModify=no
ControlGroupPersistent=no
IgnoreSIGPIPE=yes
NoNewPrivileges=no
KillMode=control-group
KillSignal=15
SendSIGKILL=yes
ExecMainStartTimestampMonotonic=0
ExecMainExitTimestampMonotonic=0
ExecMainPID=0
ExecMainCode=0
ExecMainStatus=0
DefaultControlGroup=name=systemd:/system/auditd.service
ControlGroups=cpu:/system/auditd.service name=systemd:/system/auditd.service

what does "systemctl show runlevel3.target" and "systemctl show runlevel5.target" show you? (I am only interested in the dependencies of these units, so only paste the upper part of the output please)

# systemctl show runlevel3.target
Id=multi-user.target
Names=multi-user.target runlevel4.target runlevel3.target runlevel2.target
Requires=basic.target
Wants=sendmail.service nfs-idmap.service smartd.service xrdp.service nut-server.service cpupower.service cups.path motion.service abrt-xorg.service lm_sensors.service remote-fs.target rpcbind.service rsyslog
RequiredBy=graphical.target
Conflicts=rescue.service rescue.target shutdown.target
Before=graphical.target systemd-update-utmp-runlevel.service
After=basic.target rescue.service rescue.target rpcbind.service rsyslog.service avahi-daemon.service getty.target rc-local.service plymouth-quit-wait.service dbus.service systemd-user-sessions.service plymou
Documentation=man:systemd.special(7)
Description=Multi-User System
[cut]

# systemctl show runlevel5.target
Id=graphical.target
Names=runlevel5.target graphical.target default.target
Requires=multi-user.target
Wants=gdm.service systemd-update-utmp-runlevel.service systemd-readahead-collect.service systemd-readahead-replay.service squeezeboxserver.service
Conflicts=rescue.target shutdown.target
Before=systemd-update-utmp-runlevel.service systemd-readahead-done.timer systemd-readahead-done.service
After=multi-user.target gdm.service squeezeboxserver.service
Documentation=man:systemd.special(7)
Description=Graphical Interface
[cut]

Better paste:

Id=multi-user.target
Names=multi-user.target runlevel4.target runlevel3.target runlevel2.target
Requires=basic.target
Wants=sendmail.service nfs-idmap.service smartd.service xrdp.service nut-server.service cpupower.service cups.path motion.service abrt-xorg.service lm_sensors.service remote-fs.target rpcbind.service rsyslog.service atd.service gpm.service ntpd.service nut-monitor.service avahi-daemon.service ldattach sm-client.service sshd.service ntpdate.service crond.service httpd.service irqbalance.service getty.target abrt-vmcore.service abrtd.service mysqld.service openct.service network.service mrtg.timer rc-local.service systemd-logind.service plymouth-quit-wait.service systemd-ask-password-wall.path dbus.service systemd-user-sessions.service plymouth-quit.service systemd-update-utmp-runlevel.service squeezeboxserver.service
RequiredBy=graphical.target
Conflicts=rescue.service rescue.target shutdown.target
Before=graphical.target systemd-update-utmp-runlevel.service
After=basic.target rescue.service rescue.target rpcbind.service rsyslog.service avahi-daemon.service getty.target rc-local.service plymouth-quit-wait.service dbus.service systemd-user-sessions.service plymouth-quit.service systemd-logind.service mrtg.timer openct.service mysqld.service abrtd.service abrt-vmcore.service irqbalance.service httpd.service crond.service ntpdate.service sshd.service sm-client.service ldattach nut-monitor.service ntpd.service gpm.service atd.service lm_sensors.service abrt-xorg.service motion.service cups.path cpupower.service nut-server.service xrdp.service smartd.service nfs-idmap.service sendmail.service fedora-configure.service remote-fs.target network.service squeezeboxserver.service
Documentation=man:systemd.special(7)
Description=Multi-User System
[cut]

Id=graphical.target
Names=runlevel5.target graphical.target default.target
Requires=multi-user.target
Wants=gdm.service systemd-update-utmp-runlevel.service systemd-readahead-collect.service systemd-readahead-replay.service squeezeboxserver.service
Conflicts=rescue.target shutdown.target
Before=systemd-update-utmp-runlevel.service systemd-readahead-done.timer systemd-readahead-done.service
After=multi-user.target gdm.service squeezeboxserver.service
Documentation=man:systemd.special(7)
Description=Graphical Interface
[cut]

Was the info OK?
Do you need more?
Is there a patch I can test?

Also: (fedora 20..)

Dec 24 09:01:02 recorder systemd: Starting Session 23 of user root.
Dec 24 09:01:05 recorder systemd: Started Session 23 of user root.
 
Loads of them! (!!)
Saying exactly nothing: Why was the session started? By who(m)/what?
Same as the dbus logging lacking the same stuff and thus being of little use.

Please find a better place / different loglevel / etc.

More weird stuff on F20:

Dec 25 00:01:01 recorder systemd: Starting Session 42 of user root.
Dec 25 00:01:03 recorder systemd: Started Session 42 of user root.
Dec 25 00:04:01 recorder systemd: Starting Session 43 of user mythtv.
Dec 25 00:04:01 recorder systemd: Started Session 43 of user mythtv.
Dec 25 01:01:02 recorder systemd: Starting Session 44 of user root.
Dec 25 01:01:04 recorder systemd: Started Session 44 of user root.
Dec 25 02:01:01 recorder systemd: Starting Session 45 of user root.
Dec 25 02:01:03 recorder systemd: Started Session 45 of user root.
Dec 25 03:01:01 recorder systemd: Starting Session 46 of user root.
Dec 25 03:01:02 recorder systemd: Started Session 46 of user root.
Dec 25 03:38:44 recorder systemd: Reexecuting.
Dec 25 03:38:45 recorder systemd: systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)
Dec 25 03:38:46 recorder systemd: [/usr/lib/systemd/system/rtkit-daemon.service:32] Unknown lvalue 'ControlGroup' in section 'Service'
Dec 25 03:38:46 recorder systemd: Created slice Root Slice.
Dec 25 03:38:47 recorder systemd: Listening on LVM2 metadata daemon socket.
Dec 25 03:38:47 recorder systemd: Mounted /.
Dec 25 03:38:47 recorder systemd: Reached target Sound Card.
Dec 25 03:38:47 recorder systemd: Found device LVM PV iqUZZe-WrsC-uLIk-vDWp-fazS-Xevb-K0o9SL on /dev/sda3.
Dec 25 03:38:47 recorder systemd: Found device LVM PV iqUZZe-WrsC-uLIk-vDWp-fazS-Xevb-K0o9SL on /dev/sda3.
Dec 25 03:38:47 recorder systemd: Started LVM2 PV scan on device 8:3.
Dec 25 04:01:01 recorder systemd: Starting Session 47 of user root.
Dec 25 04:01:01 recorder systemd: Started Session 47 of user root.
Dec 25 04:41:02 recorder systemd: Starting Session 48 of user mythtv.
Dec 25 04:41:03 recorder systemd: Started Session 48 of user mythtv.
Dec 25 05:01:01 recorder systemd: Starting Session 49 of user root.
Dec 25 05:01:01 recorder systemd: Started Session 49 of user root.
Dec 25 05:04:01 recorder systemd: Starting Session 50 of user mythtv.
Dec 25 05:04:01 recorder systemd: Started Session 50 of user mythtv.
Dec 25 06:01:02 recorder systemd: Starting Session 51 of user root.
Dec 25 06:01:02 recorder systemd: Started Session 51 of user root.
Dec 25 07:01:02 recorder systemd: Starting Session 52 of user root.
Dec 25 07:01:02 recorder systemd: Started Session 52 of user root.
Dec 25 07:05:01 recorder systemd: Starting Session 53 of user mythtv.
Dec 25 07:05:01 recorder systemd: Started Session 53 of user mythtv.

- Various sessions that I did not start: why/what/how/sourc/etc?!?! Is my box hacked? The logging doesn't tell me.
- at 03:38 for some reason (not me) it is re-executing: why?
- What about the rtkit lvalue? 
- What slice?
- What mount for / ? This is a running system, no mounting needed except when I need it.
- What sound card? This is a running system, no adjustign needed except when I need it.
- What PV scan? LV stuff? This is a running system, the disk never went away. Disks are a kernel thing.
- Various sessions that I did not start...

So it all looks like it needs an explanation first and then maybe some fixing.

Same problem for me since update to fedora 20 (fedup --network 20).
Each hour +1 minute +1 second I have this message:

Jan  5 07:01:01 asus systemd[1]: Starting Session 43 of user root.
Jan  5 07:01:01 asus systemd[1]: Started Session 43 of user root.

I can't explain why this occurs because there is nothing in crontab.

Hi,

Not sure if related, but I just installed F20 on a system and set up some cron jobs.  These error messages seem to occur in the syslogs at the same time the cron job is being executed.


==> /var/log/messages <==
Jan  5 21:15:01 localhost systemd: Starting Session 42 of user root.
Jan  5 21:15:01 localhost systemd: Started Session 42 of user root.

==> /var/log/cron <==
Jan  5 21:15:01 localhost CROND[6634]: (root) CMD (/root/dos/blockit.sh)

--Chris

Not sure what is happening. If the sessions are related to /proc/self/sessionid, these are intended to be used only when there is a transition through a system entry point for a user (rather than a service). The entry points can be sshd, gdm, kdm, login, ftpd, or crond. Crond might be the source of these extra sessions. However, session knowledge should only be known to the kernel and it only sends these to the audit system in a different format.

Every hour 

systemd[1]: Starting Session 107 of user root.
Jan 08 18:01:01  systemd[1]: Started Session 107 of user root.
Jan 08 18:01:01  CROND[32730]: (root) CMD (run-parts /etc/cron.hourly)
Jan 08 18:01:01  run-parts[32733]: (/etc/cron.hourly) starting 0anacron
Jan 08 18:01:01  anacron[32738]: Anacron started on 2014-01-08
Jan 08 18:01:01  anacron[32738]: Normal exit (0 jobs run)
Jan 08 18:01:01  run-parts[32740]: (/etc/cron.hourly) finished 0anacron

I went through a ssh brute force attack to my freshly installed F20 this morning, so I've installed DenyHosts. Half an hour later I see log entries like:

Jan 23 16:01:01 pensja systemd: Starting Session 14 of user root.
Jan 23 16:01:01 pensja systemd: Started Session 14 of user root.

This really got me scared. Root session that I can't see in secure log or `last`, good thing I found this bug! Indeed /var/log/cron confirms:

Jan 23 16:01:01 pensja CROND[6764]: (root) CMD (run-parts /etc/cron.hourly)

Phew! :)

So indeed these systemd session loggings do add nothing that has already been logged elsewhere.
The confusion is a negative bonus.

Also in Fedora 20:

Feb 27 19:01:05 recorder systemd: Starting Session 2143 of user root.
Feb 27 19:01:05 recorder systemd: Started Session 2143 of user root.
Feb 27 19:05:02 recorder systemd: Starting Session 2144 of user mythtv.
Feb 27 19:05:02 recorder systemd: Started Session 2144 of user mythtv.
Feb 27 20:01:03 recorder systemd: Starting Session 2145 of user root.
Feb 27 20:01:03 recorder systemd: Started Session 2145 of user root.
Feb 27 21:01:04 recorder systemd: Starting Session 2146 of user root.
Feb 27 21:01:04 recorder systemd: Started Session 2146 of user root.
Feb 27 22:01:04 recorder systemd: Starting Session 2147 of user root.
Feb 27 22:01:04 recorder systemd: Started Session 2147 of user root.
Feb 27 23:01:05 recorder systemd: Starting Session 2148 of user root.
Feb 27 23:01:05 recorder systemd: Started Session 2148 of user root.
Feb 27 23:05:02 recorder systemd: Starting Session 2149 of user mythtv.
Feb 27 23:05:02 recorder systemd: Started Session 2149 of user mythtv.
Feb 28 00:01:06 recorder systemd: Starting Session 2150 of user root.
Feb 28 00:01:07 recorder systemd: Started Session 2150 of user root.
Feb 28 00:04:01 recorder systemd: Starting Session 2151 of user mythtv.
Feb 28 00:04:01 recorder systemd: Started Session 2151 of user mythtv.
Feb 28 01:01:05 recorder systemd: Starting Session 2152 of user root.
Feb 28 01:01:05 recorder systemd: Started Session 2152 of user root.
Feb 28 02:01:05 recorder systemd: Starting Session 2153 of user root.
Feb 28 02:01:05 recorder systemd: Started Session 2153 of user root.
Feb 28 03:01:04 recorder systemd: Starting Session 2154 of user root.
Feb 28 03:01:04 recorder systemd: Started Session 2154 of user root.
Feb 28 04:01:02 recorder systemd: Starting Session 2155 of user root.
Feb 28 04:01:03 recorder systemd: Started Session 2155 of user root.
Feb 28 04:41:05 recorder systemd: Starting Session 2156 of user mythtv.

1) the same idotic situation of two lines per event, as if that action could fail to start, as if we could miss that detail
2) and do we really need this stuff in /var/log/messages? before systemd came we had /var/log/secure or something. stuff was in easy to find places instead of a grabbag situation.

Please make /var/log/messages SANE again.

Any updates? Progress? Planning? 
Do you need logs? Input?

Any patches we can try? Maybe configuration thingies?

audit.service being killed is a direct result of #708537. audit.service gets killed because it is not WantedBy or RequiredBy runlevel 2, aka multi-user.target. But this problem is not specific to audit.service, it is a problem in systemd. This bug has a lot of additional noise, so let's move the discussion about that there.

WRT. to logs about user sessions: no change so far.

Are we sure we need to change the title of the bug?
The logging of systemd is a pervasive issue: every logging is done in the same manner.
Starting xxxx
Started xxxx
etc.
And then we are not looking at log level or log file that logging is being pushed into.

This logging is done at level LOG_INFO. It is off if you boot with quiet or use systemd-analyze set-log-level notice (or higher). There's not trouble with filtering it, and I think that it is expected that systemd provides some logs for starting and stopping units, this being the main purpose and goal of systemd.

The only problem is when units are started repeatedly and often. cron is the biggest offender here, so I think the rename is appropriate.

Another reminder:
Back in the days before systemd stuff simply worked without too many messages.
See the old fstab and the messages it generated as it was processed.
Same with cron: no noise in /var/log/messages (today /var/log/messages also carries .xinit-errors ; as of yet unsolved!)
Same with starting SysV stuff.
Please use that situation (wayyyy less noise...) as a reference to work towards with this behemoth called systemd. (because: what will it never do?)
Thank you.

Any updates?
Any extra info needed?
Any patches I could try?
systemd-208-21.fc20.x86_64 did not fix this issue.

I have also seen this with the "systemd-208-11.el7_0.2.x86_64" its just flooding the messages logfile with cron start/stop session

I see the same on my system. I've discovered, that it is the sysstat package that is responsible.

On my system, the file /etc/cron.d/sysstat contains the following:
# Run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib64/sa/sa1 1 1
# 0 * * * * root /usr/lib64/sa/sa1 600 6 &
# Generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A

This indeed causes two lines in /var/log/messages every ten minutes.

The following annoying messages seemed to be generated by cron job on my system.

systemd: Starting Session xxx of user yyy.
systemd: Started Session xxx of user yyy.

I got rid of them by commenting out the following line in /etc/rsyslog.conf

# $ModLoad imjournal # provides access to the systemd journal

Not sure if this will also disable other potentially useful info generated by systemd.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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 19 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.

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

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

It has been reported against Fedora 19. 
Changing it to rawhide will not do anything except keep bugzapper of my back.
So thanks for that!
Please report progress, patches or anything I or we could test.
Please note Comment 24, fixing the issue for cron only is not enough.

Also lots of 'Starting Session' messages for various cron jobs (sysstat, logcheck, etc.) and backups running under backuppc.  I found a remedy from
https://bugzilla.redhat.com/show_bug.cgi?id=1072368 
and 
http://lists.freedesktop.org/archives/systemd-devel/2014-June/019853.html

Still no fix to this madness?

Figures, taking into account who is at the helm of this abomination.. he knows best, we know nothing.

Any progress?
Updates?

Patches we can test?(In reply to Zbigniew Jędrzejewski-Szmek from comment #25)
> The only problem is when units are started repeatedly and often. cron is the
> biggest offender here, so I think the rename is appropriate.

We have some stuff like that.
mrtg. sysstat, etc.
The default loglevel is way too high.
Nice for development and testing.
Not so for production.
Not at all UNIX-like.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #25)
> This logging is done at level LOG_INFO. It is off if you boot with quiet or
> use systemd-analyze set-log-level notice (or higher).

How to make this a default?

Despite changing the log-level I still get multiples of these:

Mar  9 06:10:01 epia systemd: Cannot add dependency job for unit dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.

This is very un-UNIX. This message adds no information, uses too many words and wastes space. This is not an error so should be invisible at notice log-level.

Mar 21 16:59:09 surfplank2 systemd: Cannot add dependency job for unit systemd-journald-audit.socket, ignoring: Unit systemd-journald-audit.socket is masked.
Mar 21 16:59:09 surfplank2 systemd: Cannot add dependency job for unit systemd-journald-audit.socket, ignoring: Unit systemd-journald-audit.socket is masked.
Mar 21 16:59:09 surfplank2 systemd: Cannot add dependency job for unit dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.

Why do we get multiple lines with the same mesage?
How to mask those as they do not really add any info and do not have to repeated again and again. They might be nice for debugging but are unnecessary for production use.

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.

Any updates? Patches? Configurations?
Stuff we could try?

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. 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 '23'.

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 23 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.

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 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 '24'.

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 24 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.

*** This bug has been marked as a duplicate of bug 911766 ***