Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 467704 - Httpd hangs when /tmp/rhnccrewrite.lock is removed by tmpwatch
Summary: Httpd hangs when /tmp/rhnccrewrite.lock is removed by tmpwatch
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 0.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jan Pazdziora
QA Contact: Miroslav Suchý
Depends On:
Blocks: space04
TreeView+ depends on / blocked
Reported: 2008-10-20 12:27 UTC by Jan Pazdziora
Modified: 2009-01-22 16:30 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-01-22 16:30:04 UTC

Attachments (Terms of Use)

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 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 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 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 -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_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D HTTPD_ROOT="/etc/httpd"
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -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.

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