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 [details] 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 [details] Latest daily MRTG graph for httpd processes
Created attachment 556267 [details] Latest weekly MRTG graph for httpd processes
Created attachment 556269 [details] 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 [details] Yum update log of previous year
Created attachment 556487 [details] 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 [details] 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 /* Set the legacy process name in addition to the POSIX name on Linux */ 2979 if (prctl(PR_SET_NAME, (unsigned long)s, 0, 0, 0) != 0) { 2980 /* diag_listed_as: SKIPME */ 2981 Perl_croak(aTHX_ "Can't set $0 with prctl(): %s", Strerror(errno)); 2982 } 2983 #endif (gdb) print s $1 = 0x555555971070 "/usr/sbin/httpd" (gdb) q A debugging session is active. Inferior 1 [process 22814] will be killed. Quit anyway? (y or n) y [jwboyer@hansolo ~]$ I disabled mod_perl in my local httpd.d/perl.conf and it doesn't do this anymore.
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 [details] 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 line 19.\nBEGIN failed--compilation aborted at /home/test/fedora/mod_perl/mod_perl-2.0.10/t/conf/modperl_startup.pl line 36.\nCompilation failed in require at (eval 2) line 1.\n [Wed Jul 26 13:33:35.351885 2017] [perl:error] [pid 18091:tid 139855501953280] Can't load Perl file: /home/test/fedora/mod_perl/mod_perl-2.0.10/t/conf/modperl_startup.pl for server localhost:8529, exiting... [ error]
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.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 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 '25'. 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 25 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.
The issue persists in F26 as well.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. 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 '26'. 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 26 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.
The issue persists in F27 as well.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. 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 '27'. 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 27 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.
The issue is still reproduced in Fedora 29.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. 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 '29'. 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 29 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.
I confirm mod_perl-2.0.11-1.fc32.x86_64 still changes the process name from "httpd" to "/usr/sbin/httpd".
The test crashes because Perl FindBin cannot determine currently running Perl script because it is neither an absolute path name, or a special value "-e" or "-". That means that with the patch, FindBin Perl module won't work. Changing argv[0] is a property of Perl as documented in perlvar(1) for "$0" variable: $0 Contains the name of the program being executed. [...] If the program has been given to perl via the switches "-e" or "-E", $0 will contain the string "-e". On Linux as of perl v5.14.0 the legacy process name will be set with prctl(2), in addition to altering the POSIX name via "argv[0]" as perl has done since version 4.000. Now system utilities that read the legacy process name such as ps, top and killall will recognize the name you set when assigning to $0. The string you supply will be cut off at 16 bytes, this is a limitation imposed by Linux. Therefore mod_perl resets argv[0] to /usr/sbin/httpd to fulfill this Perl language assumption. That's in line with the explanation in mod_perl sources: /* make sure httpd's argv[0] is the first argument so $0 is * correctly connected to the real thing */ modperl_config_srv_argv_push(s->process->argv[0]); and: /* We need to reset $0 to argv[0] (httpd) since perl_parse() will * have set it to '-e'. Being magic-aware ensures that some * OS-specific magic will happen (i.e. setproctitle() on *BSDs) */ PL_origalen = strlen(argv[0]) + 1; sv_setpv_mg(get_sv("0",0), argv[0]); perl_run(perl); I cannot see a way how to change mod_perl so that argv[0] remains "httpd" and at the same time Perl interpreter sees there "/usr/sbin/httpd".
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 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.