Bug 90984 - xinetd fails after upgrade
xinetd fails after upgrade
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-15 23:17 EDT by Carl Harris
Modified: 2014-08-31 19:24 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-18 13:07:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xinetd.conf and files from /etc/xinetd.d/ (2.21 KB, application/x-compressed)
2003-05-15 23:19 EDT, Carl Harris
no flags Details

  None (edit)
Description Carl Harris 2003-05-15 23:17:21 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312

Description of problem:
Upgraded from xinetd-2.3.7-4.7x using the up2date tool, on restart of xinet d
the following errors showed up in the message log:

May 15 23:02:57 trident xinetd[1567]: Bad log_on_failure flag: RECORD [line=11]
May 15 23:02:57 trident xinetd[1567]: Error parsing attribute log_on_failure -
DISABLING SERVICE [line=11]
May 15 23:02:57 trident xinetd[1567]: missing service keyword [line=14]
May 15 23:02:57 trident xinetd[1567]: missing } in last service entry [line=15]
May 15 23:02:57 trident xinetd[1567]: 1567 {general_handler} (1567) Unexpected
signal: 11 (Segmentation fault)
May 15 23:02:57 trident last message repeated 9 times
May 15 23:02:57 trident xinetd[1567]: 1567 {bad_signal} Received 10 signals in 1
seconds. Exiting...
May 15 23:02:57 trident xinetd: xinetd startup succeeded

Rolled back to 2.3.7-4.7x  and everything works fine

Contents of /etc/xinetd.d/ are as follows

[root@trident xinetd.d]# ls -laF
total 80
drwxr-xr-x    2 root     root         4096 May 15 23:14 ./
drwxr-xr-x   46 root     root         8192 May 15 23:14 ../
-rw-r--r--    1 root     root          563 Nov 19 12:00 chargen
-rw-r--r--    1 root     root          580 Nov 19 12:00 chargen-udp
-rw-r--r--    1 root     root          419 Nov 19 12:00 daytime
-rw-r--r--    1 root     root          438 Nov 19 12:00 daytime-udp
-rw-r--r--    1 root     root          341 Nov 19 12:00 echo
-rw-r--r--    1 root     root          360 Nov 19 12:00 echo-udp
-rw----r--    1 root     root          344 Aug 31  2001 linuxconf-web
-rw-r--r--    1 root     root          331 Aug 24  2002 proftpd
-rw----r--    1 root     root          361 Jul 24  2001 rexec
-rw----r--    1 root     root          378 Jul 24  2001 rlogin
-rw----r--    1 root     root          431 Jul 24  2001 rsh
-rw-r--r--    1 root     root          317 Feb 21  2002 rsync
-rw-r--r--    1 root     root          312 Nov 19 12:00 servers
-rw-r--r--    1 root     root          314 Nov 19 12:00 services
-rw----r--    1 root     root          305 Aug 24  2002 telnet
-rw-r--r--    1 root     root          497 Nov 19 12:00 time
-rw-r--r--    1 root     root          518 Nov 19 12:00 time-udp

Attached (xinetd.tgz) all related files

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

How reproducible:
Always

Steps to Reproduce:
1.up2date xinetd
2.service xinetd restart
3.
    

Actual Results:  upgrade seemed to be successful, but upon restart of the xinetd
service it segfaults

Expected Results:  xinetd service should run

Additional info:

kernel version is 2.4.20-13.7
Comment 1 Carl Harris 2003-05-15 23:19:05 EDT
Created attachment 91715 [details]
xinetd.conf and files from /etc/xinetd.d/
Comment 2 Robert van den Aker 2003-05-23 13:11:35 EDT
I can add that just having the RECORD log option in xinetd.conf is enough to make xinetd-2.3.11-1.7x fail to start. In my case, there were no other config parsing errors and just removing the RECORD option fixed the problem.
Comment 3 Bill Nottingham 2006-08-07 15:48:00 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
Please check if this issue is still present in a current Fedora Core
release. If so, please change the product and version to match, and
check the box indicating that the requested information has been
provided. Note that any bug still open against Red Hat Linux on will be
closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
Comment 4 Bill Nottingham 2006-10-18 13:07:02 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.

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