libapache2-mod-perl2 writes wrong process name in /proc/$$/status

Description of problem: An configuration entry to display the number of httpd processes running does not work on recent SNMP servers.

Version-Release number of selected component (if applicable): net-snmp-5.7.1-2.fc16.x86_64

How reproducible: Enable public SNMP community and add the following entry in /etc/snmp/snmpd.conf:
proc httpd 30 1

Steps to Reproduce:
1. Edit /etc/snmp/snmpd.conf
2. Enable public SNMP community and add "proc httpd 30 1"
3. Restart snmpd by issuing "systemctl restart snmpd.service" as root
4. Run "snmpwalk -v 1 localhost -c public .1.3.6.1.4.1.2021.2"

Actual results:
UCD-SNMP-MIB::prCount.1 = INTEGER: 0
UCD-SNMP-MIB::prErrorFlag.1 = INTEGER: error(1)
UCD-SNMP-MIB::prErrMessage.1 = STRING: No httpd process running

Expected results:
UCD-SNMP-MIB::prCount.1 = INTEGER: 9
UCD-SNMP-MIB::prErrorFlag.1 = INTEGER: noError(0)
UCD-SNMP-MIB::prErrMessage.1 = STRING:

Additional info:
The number of the httpd processes currently run in the system:

# ps -ef | grep -i httpd
root 1067 1 0 Jan16 ? 00:00:02 /usr/sbin/httpd -k start
apache 1078 1067 0 Jan16 ? 00:00:00 /usr/sbin/httpd -k start
apache 1079 1067 0 Jan16 ? 00:00:00 /usr/sbin/httpd -k start
apache 1080 1067 0 Jan16 ? 00:00:00 /usr/sbin/httpd -k start
apache 1081 1067 0 Jan16 ? 00:00:00 /usr/sbin/httpd -k start
apache 1082 1067 0 Jan16 ? 00:00:00 /usr/sbin/httpd -k start
apache 1083 1067 0 Jan16 ? 00:00:00 /usr/sbin/httpd -k start
apache 1084 1067 0 Jan16 ? 00:00:00 /usr/sbin/httpd -k start
apache 1085 1067 0 Jan16 ? 00:00:00 /usr/sbin/httpd -k start

The full snmpd.conf configuration is also attached for your convenience.

Created attachment 555720
SNMPD configuration

Configuration file /etc/snmp/snmpd.conf

The rest configured processes (smbd & sshd) work fine:

# snmpwalk -v 1 localhost -c public .1.3.6.1.4.1.2021.2
UCD-SNMP-MIB::prIndex.1 = INTEGER: 1
UCD-SNMP-MIB::prIndex.2 = INTEGER: 2
UCD-SNMP-MIB::prIndex.3 = INTEGER: 3
UCD-SNMP-MIB::prNames.1 = STRING: httpd
UCD-SNMP-MIB::prNames.2 = STRING: smbd
UCD-SNMP-MIB::prNames.3 = STRING: sshd
UCD-SNMP-MIB::prMin.1 = INTEGER: 1
UCD-SNMP-MIB::prMin.2 = INTEGER: 1
UCD-SNMP-MIB::prMin.3 = INTEGER: 1
UCD-SNMP-MIB::prMax.1 = INTEGER: 30
UCD-SNMP-MIB::prMax.2 = INTEGER: 25
UCD-SNMP-MIB::prMax.3 = INTEGER: 20
UCD-SNMP-MIB::prCount.1 = INTEGER: 0
UCD-SNMP-MIB::prCount.2 = INTEGER: 2
UCD-SNMP-MIB::prCount.3 = INTEGER: 1
UCD-SNMP-MIB::prErrorFlag.1 = INTEGER: error(1)
UCD-SNMP-MIB::prErrorFlag.2 = INTEGER: noError(0)
UCD-SNMP-MIB::prErrorFlag.3 = INTEGER: noError(0)
UCD-SNMP-MIB::prErrMessage.1 = STRING: No httpd process running
UCD-SNMP-MIB::prErrMessage.2 = STRING:
UCD-SNMP-MIB::prErrMessage.3 = STRING:
UCD-SNMP-MIB::prErrFix.1 = INTEGER: noError(0)
UCD-SNMP-MIB::prErrFix.2 = INTEGER: noError(0)
UCD-SNMP-MIB::prErrFix.3 = INTEGER: noError(0)
UCD-SNMP-MIB::prErrFixCmd.1 = STRING:
UCD-SNMP-MIB::prErrFixCmd.2 = STRING:
UCD-SNMP-MIB::prErrFixCmd.3 = STRING:

In my test environment I can see all httpd daemons in prTable. Please note that
net-snmp-5.7.1 uses caches with 30 second timeout to count processes, i.e. the prTable is updated every 30 seconds with new/exited processes. Did you wait at least half a minute after httpd service start/stop?

BTW, I don't know how this 30 second timeout was chosen, maybe it's too long.

Hello Jan,

Something very weird is happening. It now works:

# snmpwalk -v 1 localhost -c public .1.3.6.1.4.1.2021.2
UCD-SNMP-MIB::prIndex.1 = INTEGER: 1
UCD-SNMP-MIB::prIndex.2 = INTEGER: 2
UCD-SNMP-MIB::prIndex.3 = INTEGER: 3
UCD-SNMP-MIB::prNames.1 = STRING: httpd
UCD-SNMP-MIB::prNames.2 = STRING: smbd
UCD-SNMP-MIB::prNames.3 = STRING: sshd
UCD-SNMP-MIB::prMin.1 = INTEGER: 1
UCD-SNMP-MIB::prMin.2 = INTEGER: 1
UCD-SNMP-MIB::prMin.3 = INTEGER: 1
UCD-SNMP-MIB::prMax.1 = INTEGER: 30
UCD-SNMP-MIB::prMax.2 = INTEGER: 25
UCD-SNMP-MIB::prMax.3 = INTEGER: 20
UCD-SNMP-MIB::prCount.1 = INTEGER: 4
UCD-SNMP-MIB::prCount.2 = INTEGER: 2
UCD-SNMP-MIB::prCount.3 = INTEGER: 7
UCD-SNMP-MIB::prErrorFlag.1 = INTEGER: noError(0)
UCD-SNMP-MIB::prErrorFlag.2 = INTEGER: noError(0)
UCD-SNMP-MIB::prErrorFlag.3 = INTEGER: noError(0)
UCD-SNMP-MIB::prErrMessage.1 = STRING:
UCD-SNMP-MIB::prErrMessage.2 = STRING:
UCD-SNMP-MIB::prErrMessage.3 = STRING:
UCD-SNMP-MIB::prErrFix.1 = INTEGER: noError(0)
UCD-SNMP-MIB::prErrFix.2 = INTEGER: noError(0)
UCD-SNMP-MIB::prErrFix.3 = INTEGER: noError(0)
UCD-SNMP-MIB::prErrFixCmd.1 = STRING:
UCD-SNMP-MIB::prErrFixCmd.2 = STRING:
UCD-SNMP-MIB::prErrFixCmd.3 = STRING:

but only for an Apache started as normal user having 4 processes. The system processes are not calculated:

# ps -ef | grep -i httpd
root 1044 1 0 10:39 ? 00:00:00 /usr/sbin/httpd -k start
apache 1047 1044 0 10:39 ? 00:00:00 /usr/sbin/httpd -k start
apache 1048 1044 0 10:39 ? 00:00:00 /usr/sbin/httpd -k start
apache 1049 1044 0 10:39 ? 00:00:00 /usr/sbin/httpd -k start
apache 1050 1044 0 10:39 ? 00:00:00 /usr/sbin/httpd -k start
apache 1051 1044 0 10:39 ? 00:00:00 /usr/sbin/httpd -k start
apache 1052 1044 0 10:39 ? 00:00:00 /usr/sbin/httpd -k start
apache 1053 1044 0 10:39 ? 00:00:00 /usr/sbin/httpd -k start
apache 1054 1044 0 10:39 ? 00:00:00 /usr/sbin/httpd -k start
n-lex 6274 1 0 12:24 ? 00:00:00 /home/n-lex/tools/bin/httpd -f /home/n-lex/natlex_utils/Nat-Lex_perlsoap/conf/soap_httpd.conf
n-lex 6275 6274 0 12:24 ? 00:00:00 /home/n-lex/tools/bin/httpd -f /home/n-lex/natlex_utils/Nat-Lex_perlsoap/conf/soap_httpd.conf
n-lex 6276 6274 0 12:24 ? 00:00:00 /home/n-lex/tools/bin/httpd -f /home/n-lex/natlex_utils/Nat-Lex_perlsoap/conf/soap_httpd.conf
n-lex 6277 6274 0 12:24 ? 00:00:00 /home/n-lex/tools/bin/httpd -f /home/n-lex/natlex_utils/Nat-Lex_perlsoap/conf/soap_httpd.conf

# id apache
uid=48(apache) gid=48(apache) groups=48(apache)
# id n-lex
uid=503(n-lex) gid=100(users) groups=100(users)

The system's apache server is run at boot time, my PC is always turned on 24/7 and only restarts may occur. As I can see from my MRTG graphs for httpd processes run every 5 minutes, it was unable to count ever the system's httpd processes, but only that development httpd.

Created attachment 556266
Latest daily MRTG graph for httpd processes

Created attachment 556267
Latest weekly MRTG graph for httpd processes

Created attachment 556269
Latest yearly MRTG graph for httpd processes

As you can see from this graph, the problem occurred on early December. It used to work fine before by displaying 9 processes.

That's very strange. Can you see your httpd processes in hrSWRunTable? It shares the same data with prTable.

snmptable localhost hrSWRunTable | grep httpd

If you don't see any httpd there, I need strace of snmpd. Please run following commands (in different terminals) and send me their output. I need to see how snmpd goes through /proc/* and reads /proc/*/cmdline of every process and also what it finds there (= the snmpwalk output).

$ service snmpd stop; strace -s 9999 snmpd -f -Lo 2>&1 | tee strace.out

(in different terminal)
$ (snmpwalk -v2c -c public localhost hrSWRunTable ; snmpwalk -v2c -c public localhost prTable) | tee walk.out

Also, do you remember anything interesting happening in beginning of December, like updating the machine (see /var/log/yum.log) or so?

Hello Jan,

I confirm that hrSWRunTable displays my system httpd processes:

# snmptable -c public -v 1 localhost hrSWRunTable | grep httpd
         1051 "/usr/sbin/httpd" SNMPv2-SMI::zeroDotZero "/usr/sbin/httpd" "-k start" application runnable
         1060 "/usr/sbin/httpd" SNMPv2-SMI::zeroDotZero "/usr/sbin/httpd" "-k start" application runnable
         1061 "/usr/sbin/httpd" SNMPv2-SMI::zeroDotZero "/usr/sbin/httpd" "-k start" application runnable
         1062 "/usr/sbin/httpd" SNMPv2-SMI::zeroDotZero "/usr/sbin/httpd" "-k start" application runnable
         1063 "/usr/sbin/httpd" SNMPv2-SMI::zeroDotZero "/usr/sbin/httpd" "-k start" application runnable
         1064 "/usr/sbin/httpd" SNMPv2-SMI::zeroDotZero "/usr/sbin/httpd" "-k start" application runnable
         1065 "/usr/sbin/httpd" SNMPv2-SMI::zeroDotZero "/usr/sbin/httpd" "-k start" application runnable
         1066 "/usr/sbin/httpd" SNMPv2-SMI::zeroDotZero "/usr/sbin/httpd" "-k start" application runnable
         1067 "/usr/sbin/httpd" SNMPv2-SMI::zeroDotZero "/usr/sbin/httpd" "-k start" application runnable
         6371 "grep" SNMPv2-SMI::zeroDotZero

Please, tell me if you still need the strace, because I have understood that you need it in case that no httpd process is displayed.

I'm also attaching the yum update log. A major system event was the upgrade from F15 to F16 on Nov 22, 2012.

Created attachment 556485
Yum update log of previous year

Created attachment 556487
Yum update log of previous year

Attaching the correct yum log

Sorry for late response...

I can see a difference in my and your setup. My hrSWRunTable short "httpd" as name of the httpd process, your shows "/usr/sbin/httpd"

Try using "proc /usr/sbin/httpd 30 1" in your snmpd.conf as a workaround.

And yes, please provide the strace, I want to see where the difference comes from.

Created attachment 566293
Strace and snmwalk output

Hello Jan,

Please, find attached strace-walk.zip file containing both requested outputs.

Thanks a lot!

In the strace I can see snmpd reads /proc/1048/status. snmpd interprets the Name: line as name of the process and your kernel reports full path of the binary "Name: /usr/sbin/httpd" here, while e.g. /proc/971/status shows only name of the binary: "Name: bluetoothd".

That's why snmpd does not match "httpd" process and reports UCD-SNMP-MIB::prCount.1 = 0.

My kernel (kernel-3.2.5-3.fc16.x86_64) shows "Name: httpd" in /proc/XYZ/status of httpd processes.

Try to use full path in your snmpd.conf as suggested in comment #12. I have no idea why kernel reports full path name to the binary, you can ask kernel guys (i.e. reassign this bug to them). Definitely, there is no bug in snmpd.

Hello Jan,

Thank you very much. I have also verified that only for httpd process the full path is given in the Name field of status file in /proc/<PID>/status.

Re-assigning the bug to kernel folks. My kernel is the latest kernel-3.2.7-1.fc16.x86_64. Their feedback could be very helpful. The question is why HTTPD process is reported with full path /usr/sbin/httpd instead of httpd?

This isn't a kernel bug.

A process can call prctl(PR_SET_NAME) to set it's task name (task->comm) in the kernel, as long as the name is under 16 characters. If you have mod_perl included in httpd, it calls prctl and sets the name to '/usr/sbin/httpd'.

Why it does this, I have absolutely no clue. But it does.

[jwboyer@hansolo ~]$ sudo gdb /usr/sbin/httpd
GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/httpd...Reading symbols from /usr/lib/debug/usr/sbin/httpd.debug...done.
done.
(gdb) set args -k start
(gdb) break prctl
Breakpoint 1 at 0x162f0
(gdb) r
Starting program: /usr/sbin/httpd -k start
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, prctl () at ../sysdeps/unix/syscall-template.S:82
82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Missing separate debuginfos, use: debuginfo-install avahi-libs-0.6.30-4.fc16.x86_64 cyrus-sasl-lib-2.1.23-27.fc16.x86_64 dbus-libs-1.4.10-3.fc16.x86_64 keyutils-libs-1.5.2-1.fc16.x86_64 krb5-libs-1.9.2-6.fc16.x86_64 libcom_err-1.41.14-2.fc15.x86_64 libselinux-2.1.6-6.fc16.x86_64 libuuid-2.20.1-2.2.fc16.x86_64 mod_dnssd-0.6-4.fc15.x86_64 mod_perl-2.0.5-7.fc16.x86_64 mod_python-3.3.1-16.fc16.x86_64 mod_wsgi-3.3-1.fc16.x86_64 nspr-4.8.9-2.fc16.x86_64 nss-3.13.1-11.fc16.x86_64 nss-util-3.13.1-3.fc16.x86_64 openldap-2.4.26-6.fc16.x86_64 openssl-1.0.0g-1.fc16.x86_64 python-libs-2.7.2-5.2.fc16.x86_64
(gdb) bt
#0 prctl () at ../sysdeps/unix/syscall-template.S:82
#1 0x00007fffed120abc in Perl_magic_set (my_perl=0x55555594c1d0,
    sv=<optimized out>, mg=<optimized out>) at mg.c:2979
#2 0x00007fffed11c942 in Perl_mg_set (my_perl=0x55555594c1d0,
    sv=0x55555596c9e0) at mg.c:302
#3 0x00007fffed412079 in modperl_startup ()
   from /etc/httpd/modules/mod_perl.so
#4 0x00007fffed411fa0 in modperl_startup ()
   from /etc/httpd/modules/mod_perl.so
#5 0x00007fffed4123f5 in modperl_init () from /etc/httpd/modules/mod_perl.so
#6 0x00007fffed41254b in modperl_hook_init ()
   from /etc/httpd/modules/mod_perl.so
#7 0x0000555555580511 in ap_run_open_logs (pconf=0x5555557b4138,
    plog=0x5555557e62c8, ptemp=0x5555557e82d8, s=0x5555557de3d0)
    at /usr/src/debug/httpd-2.2.22/server/config.c:151
#8 0x000055555556b5cc in main (argc=3, argv=0x7fffffffe618)
    at /usr/src/debug/httpd-2.2.22/server/main.c:680
(gdb) up
#1 0x00007fffed120abc in Perl_magic_set (my_perl=0x55555594c1d0,
    sv=<optimized out>, mg=<optimized out>) at mg.c:2979
2979 if (prctl(PR_SET_NAME, (unsigned long)s, 0, 0, 0) != 0) {
(gdb) list
2974 PL_origargv[0][PL_origalen-1] = 0;
2975 for (i = 1; i < PL_origargc; i++)
2976 PL_origargv[i] = 0;
2977 #ifdef HAS_PRCTL_SET_NAME
2978 /* ...

Hello Josh,

Thank you very much. I have also confirmed that disabling mod_perl allows HTTPD to set the name correctly.

Re-assigning the bug to mod_perl experts.

Panos,

when snmpd/MRTG was working perfectly, did you have mod_perl installed? I'm trying to find, if it is regression in mod_perl or already old mod_perl bug, which just got visible when you enabled it.

There was perl update on Nov 22 (4:perl-5.14.2-190.fc16.x86_64), could this be the guilty one?

Also mod_perl was updated at the end of November, this could be another source of regressions:
Nov 30 14:21:42 Installed: mod_perl-2.0.5-6.fc16.x86_64

Hello Jan,

I confirm that mod_perl wasn't installed before the problem appeared:

root@bb229:[205] ~ # grep -i mod_perl /var/log/yum.log*
/var/log/yum.log:Jan 12 08:49:38 Updated: mod_perl-2.0.5-7.fc16.x86_64
/var/log/yum.log:Jan 12 08:50:01 Updated: mod_perl-devel-2.0.5-7.fc16.x86_64
/var/log/yum.log-20120101:Nov 30 14:21:42 Installed: mod_perl-2.0.5-6.fc16.x86_64
/var/log/yum.log-20120101:Nov 30 14:21:43 Installed: mod_perl-devel-2.0.5-6.fc16.x86_64

Please, also note that Nov 22 was an upgrade date from F15 to F16.

From the first try, attached mod_perl patch fixed the problem for me. But I will better check it twice and find out what exactly is the meaning of that short_name variable.

Created attachment 567625
proposed patch

mod_perl-2.0.5-8.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mod_perl-2.0.5-8.fc17

mod_perl-2.0.5-8.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mod_perl-2.0.5-8.fc16

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

mod_perl-2.0.5-8.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.

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

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

The fix was dropped by an accident in mod_perl-2.0.7-12.20130221svn1448242.fc18. We need to put it back.

Well, the patch breaks current mod_perl tests. I will have to look why is that a problem:

APACHE_TEST_APXS= APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= \
"/usr/bin/perl" -Iblib/arch -Iblib/lib \
t/TEST -bugreport -verbose=1
/usr/sbin/httpd -d /home/test/fedora/mod_perl/mod_perl-2.0.10/t -f /home/test/fedora/mod_perl/mod_perl-2.0.10/t/conf/httpd.conf -D APACHE2 -D APACHE2_4 -D PERL_USEITHREADS
using Apache/2.4.27 (event MPM)

waiting 300 seconds for server to start: .[Wed Jul 26 13:33:35.181948 2017] [env:warn] [pid 18091:tid 139855501953280] AH01506: PassEnv variable LD_LIBRARY_PATH was undefined
[Wed Jul 26 13:33:35.205891 2017] [perl:info] [pid 18091:tid 139855501953280] 6 Apache2:: modules loaded
[Wed Jul 26 13:33:35.205911 2017] [perl:info] [pid 18091:tid 139855501953280] 0 APR:: modules loaded
[Wed Jul 26 13:33:35.205947 2017] [perl:info] [pid 18091:tid 139855501953280] base server + 28 vhosts ready to run tests
[Wed Jul 26 13:33:35.351835 2017] [perl:error] [pid 18091:tid 139855501953280] $s->add_config() has failed: Cannot find current script 'httpd' at /usr/share/perl5/FindBin.pm line 166.\nBEGIN failed--compilation aborted at /usr/share/perl5/FindBin.pm line 166.\nCompilation failed in require at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/TestSmoke.pm line 31.\nBEGIN failed--compilation aborted at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/TestSmoke.pm line 31.\nCompilation failed in require at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/TestMM.pm line 24.\nBEGIN failed--compilation aborted at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/TestMM.pm line 24.\nCompilation failed in require at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/TestRun.pm line 22.\nBEGIN failed--compilation aborted at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/TestRun.pm line 22.\nCompilation failed in require at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/TestServer.pm line 26.\nBEGIN failed--compilation aborted at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/TestServer.pm line 26.\nCompilation failed in require at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/TestConfig.pm line 56.\nBEGIN failed--compilation aborted at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/TestConfig.pm line 56.\nCompilation failed in require at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/Test.pm line 23.\nBEGIN failed--compilation aborted at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/Test.pm line 23.\nCompilation failed in require at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/TestHandler.pm line 21.\nBEGIN failed--compilation aborted at /home/test/fedora/mod_perl/mod_perl-2.0.10/Apache-Test/lib/Apache/TestHandler.pm line 21.\nCompilation failed in require at (eval 3) line 1.\nCompilation failed in require at /home/test/fedora/mod_perl/mod_perl-2.0.10/t/conf/modperl_startup.pl line 18.\n\t...propagated at /home/test/fedora/mod_perl/mod_perl-2.0.10/t/conf/modperl_startup.pl l...

Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 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.