Description of problem: audit-related logging ends up in /var/log/messages where it has no place: two lines of non-failures should be logged elsewhere and/or at a lower loglevel Version-Release number of selected component (if applicable): audit-2.3.2-1.fc19.x86_64 How reproducible: run F19, check /var/log/messages every now and then Actual results: See below Expected results: No such logging. Additional info: Aug 11 03:16:36 surfplank2 kernel: [394314.894090] type=1130 audit(1376183796.005:845): pid=1 uid=0 auid=4294967295 ses=4294967295 Aug 11 03:16:36 surfplank2 kernel: [394314.894090] msg=' comm="mrtg" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Aug 11 03:16:37 surfplank2 kernel: [394316.727726] type=1131 audit(1376183797.841:846): pid=1 uid=0 auid=4294967295 ses=4294967295 Aug 11 03:16:37 surfplank2 kernel: [394316.727726] msg=' comm="mrtg" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
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 ***