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.
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?
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).
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.
I'm pretty sure attempts are already made, but at this point, it's not an xinetd bug. Closing.