Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 61356

Summary:	Several config files in /etc/xinetd.d have 0 size
Product:	[Retired] Red Hat Linux	Reporter:	Simon Matter <simon.matter>
Component:	xinetd	Assignee:	Trond Eivind Glomsrxd <teg>
Status:	CLOSED NOTABUG	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-03-18 21:53:03 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:

Description Simon Matter 2002-03-18 14:31:32 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i686)

Description of problem:
After doing some installation and configuration work, using chkconfig and ntsysv
to enable/disable services, suddenly many config files in /etc/xinetd.d have 0
byte size and services dont' work as expected.

Version-Release number of selected component (if applicable):


How reproducible:
Couldn't Reproduce

Steps to Reproduce:
1. Install RedHat 7.2 system
2. Do some more installation and configuration work, using chkconfig and ntsysv
frequently to manage services
3. ls -la /etc/xinetd.d
	

Actual Results:  Something like:

[root@gw-linux-dev root]# ls -la /etc/xinetd.d
total 52
drwxr-xr-x    2 root     root         4096 Mar 18 15:17 .
drwxr-xr-x   46 root     root         8192 Mar 18 14:56 ..
-rw-r--r--    1 root     root          295 Mar 18 15:17 chargen
-rw-r--r--    1 root     root          315 Mar 18 15:17 chargen-udp
-rw-r--r--    1 root     root          295 Mar 18 15:17 daytime
-rw-r--r--    1 root     root          315 Mar 18 15:17 daytime-udp
-rw-r--r--    1 root     root          287 Mar 18 15:17 echo
-rw-r--r--    1 root     root          306 Mar 18 15:17 echo-udp
-rw-r--r--    1 root     root          317 Mar 18 15:17 finger
-rw-r--r--    1 root     root          499 Mar 18 15:17 jftpgw-inet
-rw-r--r--    1 root     root          257 Mar 18 15:17 ntalk
-rw-r--r--    1 root     root            0 Mar 18 15:17 rexec
-rw-r--r--    1 root     root            0 Mar 18 15:17 rlogin
-rw-r--r--    1 root     root            0 Mar 18 15:17 rsh
-rw-r--r--    1 root     root            0 Mar 18 15:17 rsync
-rw-r--r--    1 root     root            0 Mar 18 15:17 talk
-rw-r--r--    1 root     root            0 Mar 18 15:17 telnet
-rw-r--r--    1 root     root            0 Mar 18 15:17 time
-rw-r--r--    1 root     root            0 Mar 18 15:17 time-udp
-rw-r--r--    1 root     root            0 Mar 18 15:17 wu-ftpd


Expected Results:  Something like:

[root@dhcp-141-104 root]# ls -la /etc/xinetd.d
total 84
drwxr-xr-x    2 root     root         4096 Mar 12 14:21 .
drwxr-xr-x   42 root     root         8192 Mar 15 08:55 ..
-rw-r--r--    1 root     root          295 Feb 22 15:51 chargen
-rw-r--r--    1 root     root          315 Feb 22 15:51 chargen-udp
-rw-r--r--    1 root     root          295 Feb 22 15:51 daytime
-rw-r--r--    1 root     root          315 Feb 22 15:51 daytime-udp
-rw-r--r--    1 root     root          287 Feb 22 15:51 echo
-rw-r--r--    1 root     root          306 Feb 22 15:51 echo-udp
-rw-r--r--    1 root     root          317 Feb 22 15:51 finger
-rw-r--r--    1 root     root          257 Feb 22 15:51 ntalk
-rw-r--r--    1 root     root          359 Feb 22 15:51 rexec
-rw-r--r--    1 root     root          376 Feb 22 15:51 rlogin
-rw-r--r--    1 root     root          429 Feb 22 15:51 rsh
-rw-r--r--    1 root     root          317 Feb 21 07:32 rsync
-rw-r--r--    1 root     root          245 Feb 22 15:51 talk
-rw-r--r--    1 root     root          303 Feb 22 15:51 telnet
-rw-r--r--    1 root     root          319 Feb 22 15:51 time
-rw-r--r--    1 root     root          315 Feb 22 15:51 time-udp
-rw-r--r--    1 root     root          361 Feb 22 15:51 wu-ftpd


Additional info:

I have experienced the problem above for more than one time now on different
machines and I'm wondering nobody else has seen this before. I still couldn't
figure out what's causing the problem.

Comment 1 Simon Matter 2002-03-18 16:27:46 UTC

Something I forgot to mention, I'm using XFS as filesystem.
One can get zero filled files when having a kernel crash or unclean shutdown.
But I didn't have a crash and no unclean shutdown as well.
I reproduced it now:
using ntsysv to manage services -> reboot: Files in /etc/xinetd.d have normal
size but filled with zero. Using ntsysv again truncates them to zero size.
Maybe write cache on the disks is enabled for some reason. That could explain
why changes are not commited to disk. I don't understand it anyway because on
reboot, the cache should be flushed to disk, doesn't it?

Comment 2 Trond Eivind Glomsrxd 2002-03-18 16:38:10 UTC

I would definitely suspect XFS - I have no other reports of anything like it,
and have never seen it happen. This does not look like an xinetd problem.

Can you reproduce it on a supported configuration? (even so, it wouldn't be an
xinetd problem, though - as long as the files are there when the package is
installed, it should be off the hook).

Comment 3 Simon Matter 2002-03-18 21:52:57 UTC

Okay, it seems to be a XFS problem, partly. XFS has the problem that on a crash,
one can get zero filled files when metadata is updated but data could not get
out to disk in time. But, whatever filesystem we use, it would be nice if the OS
forces the drive to flush it's cache on halt/reboot. I was searching the web and
found out that Windows NT had exactly this problem with the Quantum Fireball
drive I'm using. So M$ modified the 'IDE driver' to let the drive flush it's
cache before halt/reboot. I tried hdparm -f in the halt script to get the same
result but it didn't help. I'll try to disable write cache on the drives
tomorrow. Is there a way to disable write cache via hdparm or sysctl? If yes,
this should go into the halt script.

Comment 4 Trond Eivind Glomsrxd 2002-03-18 21:57:16 UTC

I'm pretty sure attempts are already made, but at this point, it's not an xinetd
bug. Closing.