Bug 467704 - Httpd hangs when /tmp/rhnccrewrite.lock is removed by tmpwatch
Httpd hangs when /tmp/rhnccrewrite.lock is removed by tmpwatch
Status: CLOSED CURRENTRELEASE
Product: Spacewalk
Classification: Community
Component: Server (Show other bugs)
0.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Pazdziora
Miroslav Suchý
:
Depends On:
Blocks: space04
  Show dependency treegraph
 
Reported: 2008-10-20 08:27 EDT by Jan Pazdziora
Modified: 2009-01-22 11:30 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-22 11:30:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Pazdziora 2008-10-20 08:27:12 EDT
+++ This bug was initially created as a clone of Bug #282651 +++

Description of problem:

After a week of uptime, httpd responses hang or become incredibly slow.  The
httpd error log shows:

[Tue Jul 31 09:12:31 2007] [error] (2)No such file or directory: mod_rewrite:
Child could not open RewriteLock file /tmp/rhnccrewrite.lock

Evidently this file has been removed by tmpwatch.

How reproducible:

Happens every week.  Recreating the file with the right permissions allows httpd
to proceed normally.

Steps to Reproduce:
1. rm /tmp/rhnccrewrite.lock
2. ???
3. profit!

Additional info:

Is this really where the lock file should be?  Moving it to a dedicated location
under /var/lock seems preferable.

--- Additional comment from cperry@redhat.com on 2007-09-07 13:13:41 EDT ---

[root@rlx-1-12 ~]# grep -ir hnccrewrite.lock /etc/httpd/conf/*
/etc/httpd/conf/rhn/rhn_monitoring.conf:RewriteLock /tmp/rhnccrewrite.lock
[root@rlx-1-12 ~]# ls -l /tmp/rhnccrewrite.lock 
-rw-r--r--  1 apache root 0 Sep  6 15:27 /tmp/rhnccrewrite.lock
[root@rlx-1-12 ~]# 

--- Additional comment from cperry@redhat.com on 2008-07-24 10:56:19 EDT ---

Adding to sat530-triage, since it has the sat-5.3.0 flag set. 

--- Additional comment from jpazdziora@redhat.com on 2008-10-20 08:25:40 EDT ---

Starting with Satellite 5.1.0, httpd package from RHEL 4 is used. That package is compiled with APR_USE_SYSVSEM_SERIALIZE and APR_USE_PTHREAD_SERIALIZE:

# rpm -q httpd
httpd-2.0.52-41.ent
# httpd -V
Server version: Apache/2.0.52
Server built:   May  9 2008 05:54:40
Server's Module Magic Number: 20020903:9
Architecture:   32-bit
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT="/etc/httpd"
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"
# 

Therefore SysV locking is used, and no .lock files are created. The httpd package on RHEL 5 has similar compile time settings.

I'm therefore moving this bugzilla ON_QA, with the understanding that no file gets created so no file is deleted, so no slowdown should be observed.

I shall update the lockfile path in Spacewalk but the fix in Spacewalk is not blocking this bugzilla from being tested.
Comment 1 Jan Pazdziora 2008-10-20 08:42:12 EDT
rhn_monitoring.conf changed in bfad4780e58cd79698909a62b68a7c354176cbd8.
Comment 2 Clifford Perry 2008-10-21 13:21:42 EDT
I assume it is safe to move this ot MODIFIED.
Comment 3 Jan Pazdziora 2008-11-10 08:32:43 EST
The fix was included in spacewalk-config-0.3.2-1 and Spacewalk 0.3 contains spacewalk-config-0.3.3-1, so the fix is in. Moving ON_QA.
Comment 4 Miroslav Suchý 2008-11-10 09:22:16 EST
Can not verified in Spacewalk 0.3 due it require functional monitoring.
Postponing verification to Spacewalk 0.4
Comment 5 Miroslav Suchý 2009-01-15 04:13:01 EST
The lock is no longer created as per comment #0
The config option points to correct place.
Moving to VERIFIED.

Note You need to log in before you can comment on or make changes to this bug.