Bug 467704

Summary: Httpd hangs when /tmp/rhnccrewrite.lock is removed by tmpwatch
Product: [Community] Spacewalk Reporter: Jan Pazdziora <jpazdziora>
Component: ServerAssignee: Jan Pazdziora <jpazdziora>
Status: CLOSED CURRENTRELEASE QA Contact: Miroslav Suchý <msuchy>
Severity: medium Docs Contact:
Priority: medium    
Version: 0.2CC: bperkins, cperry, msuchy
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-22 16:30:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 456552    

Description Jan Pazdziora 2008-10-20 12:27:12 UTC
+++ 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 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 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 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 12:42:12 UTC
rhn_monitoring.conf changed in bfad4780e58cd79698909a62b68a7c354176cbd8.

Comment 2 Clifford Perry 2008-10-21 17:21:42 UTC
I assume it is safe to move this ot MODIFIED.

Comment 3 Jan Pazdziora 2008-11-10 13:32:43 UTC
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 14:22:16 UTC
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 09:13:01 UTC
The lock is no longer created as per comment #0
The config option points to correct place.
Moving to VERIFIED.