Bug 467704 - Httpd hangs when /tmp/rhnccrewrite.lock is removed by tmpwatch
Summary: Httpd hangs when /tmp/rhnccrewrite.lock is removed by tmpwatch
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 0.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jan Pazdziora (Red Hat)
QA Contact: Miroslav Suchý
URL:
Whiteboard:
Depends On:
Blocks: space04
TreeView+ depends on / blocked
 
Reported: 2008-10-20 12:27 UTC by Jan Pazdziora (Red Hat)
Modified: 2009-01-22 16:30 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-01-22 16:30:04 UTC
Embargoed:


Attachments (Terms of Use)

Description Jan Pazdziora (Red Hat) 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 (Red Hat) 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 (Red Hat) 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.


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