Bug 48367 - telnet service fails after a couple of hours with xinetd-2.3.0
telnet service fails after a couple of hours with xinetd-2.3.0
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
:
: 48445 49347 52365 52752 53883 54005 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-10 10:21 EDT by Need Real Name
Modified: 2014-08-31 19:24 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-04 16:24:05 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)

  None (edit)
Description Need Real Name 2001-07-10 10:21:20 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010626

Description of problem:
Telnet works as a service for a while and then starts failing with

xinetd[15716]: execv( /usr/sbin/in.tel ) failed: No such file or directory
(errno = 2)

This was working properly before updating the errata xinetd-2.3.0-1.71

Other services are not failing.


How reproducible:
Sometimes

Steps to Reproduce:
1. Restart Xinetd
2. Wait for a while (telnet works fine)
3. Telnet dead. Can't find command.
	

Additional info:

Here is the telnet entry from /etc/xinetd.d/telnet
--------------------------------------------------------
# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
# only_from = 10.1.1.0/24
server = /usr/sbin/in.telnetd
log_on_failure += USERID
}


Kernel 2.2.19 (not 2.4.3). This is the only difference from the
standard RedHat 7.1

---------------------logs-------------------------------------
Jul  9 16:57:22 wolf xinetd[30865]: {general_handler} (30865) Unexpected
signal: 11 (Segmentation fault)
Jul  9 16:57:22 wolf last message repeated 9 times
Jul  9 16:57:22 wolf xinetd[30865]: {bad_signal} Received 10 signals in 1
seconds. Exiting...
Jul  9 16:57:42 wolf xinetd[31128]: {general_handler} (31128) Unexpected
signal: 11 (Segmentation fault)
Jul  9 16:57:42 wolf last message repeated 9 times
Jul  9 16:57:42 wolf xinetd[31128]: {bad_signal} Received 10 signals in 1
seconds. Exiting...
Jul  9 16:57:44 wolf xinetd[31129]: {general_handler} (31129) Unexpected
signal: 11 (Segmentation fault)
Jul  9 16:57:44 wolf last message repeated 9 times
Jul  9 16:57:44 wolf xinetd[31129]: {bad_signal} Received 10 signals in 1
seconds. Exiting...
Jul  9 16:57:45 wolf xinetd[31130]: {general_handler} (31130) Unexpected
signal: 11 (Segmentation fault)
Jul  9 16:57:45 wolf last message repeated 9 times
Jul  9 16:57:45 wolf xinetd[31130]: {bad_signal} Received 10 signals in 1
seconds. Exiting...
Jul 10 07:54:14 wolf xinetd[15716]: execv( /usr/sbin/in.tel ) failed: No
such file or directory (errno = 2)
Comment 1 Trond Eivind Glomsrxd 2001-07-13 17:48:27 EDT
Doesn't occur under light testing on a standard RHL 7.1 system here, with a
supported kernel. I'll try some heavier testing next week.
Comment 2 Didier 2001-07-18 08:24:34 EDT
Same story here : after upgrade of a 7.1 server with all RH-supplied errata
(including kernel 2.4.3 and xinetd 2.3.0/release 1.71 , all xinetd-initiated
services (pop3, imap, imaps) die alltogether after a certain time interval
(anywhere from one to several hours).

Same error messages as bmilner@cimsoft.com

No heavy load on server.

Temporary resolution : service xinetd reload
Comment 3 Didier 2001-07-18 11:28:46 EDT
Recompiled & installed xinetd-2.3.0-2.src.rpm from RawHide : same errors.

Jul 18 17:01:18 testhost xinetd[14620]: {general_handler} (14620) Unexpected
signal: 11 (Segmentation fault)
Jul 18 17:01:18 testhost xinetd[14620]: {bad_signal} Received 10 signals in 1
seconds. Exiting...
...
(error messages subsequently repeated several times)
...


Comment 4 Trond Eivind Glomsrxd 2001-07-18 11:35:06 EDT
That rpm is the same one, compiled in a different environment.

Could you try the one at http://people.redhat.com/teg/xinetd/ and see if it helps?
Comment 5 Didier 2001-07-18 16:43:51 EDT
Running a recompiled xinetd-2.3.0-2.1 for approx. 2 hours now without any
problems, but system load has been minimal (holidays period, late evening hours).
I'll provide you with an updated status in another 12 hours, when there's been
some local system activity.
Thanks, btw !
Comment 6 Need Real Name 2001-07-18 17:36:28 EDT
I am also trying the new xinetd-2.3.0-2.1 . With the old rpm the failure
was between 5 minutes and 2 days depending on load, so I'll see what
happens for the next couple of days.
Comment 7 Need Real Name 2001-07-18 19:40:17 EDT
Still broken ... xinetd-2.3.0-2.1


Jul 18 16:50:15 wolf xinetd[1355]: {bad_signal} Received 10 signals in 1 seconds
. Exiting...
Jul 18 16:50:34 wolf xinetd[1358]: {general_handler} (1358) Unexpected signal: 1
1 (Segmentation fault)
Jul 18 16:50:34 wolf last message repeated 9 times

Jul 18 17:42:24 wolf xinetd[3859]: execv( /usr/sbin/in.tel ) failed: No such fil
e or directory (errno = 2)


Comment 8 Didier 2001-07-19 09:02:43 EDT
Running xinetd-2.3.0-2.1 for a solid 18 hours now (light load) without any error
messages (knock wood).
Comment 9 Didier 2001-07-19 12:24:04 EDT
After 20 hours, I'v received the same error messages again :

Jul 19 17:43:53 dmb xinetd[21229]: {general_handler} (21229) Unexpected signal:
11 (Segmentation fault)
Jul 19 17:43:53 dmb xinetd[21229]: {bad_signal} Received 10 signals in 1
seconds. Exiting...
Jul 19 18:08:06 dmb xinetd[21361]: {general_handler} (21361) Unexpected signal:
11 (Segmentation fault)
Jul 19 18:08:06 dmb xinetd[21361]: {bad_signal} Received 10 signals in 1
seconds. Exiting...
Jul 19 18:08:51 dmb xinetd[21363]: {general_handler} (21363) Unexpected signal:
11 (Segmentation fault)
Jul 19 18:08:51 dmb xinetd[21363]: {bad_signal} Received 10 signals in 1
seconds. Exiting...


Contrary to the previous xinetd-2.3.0-2 though, the xinetd-initiated services
(imap, imaps, pop3) continue to run : I did not need to reload xinetd.



Comment 10 Didier 2001-07-21 14:51:06 EDT
Xinetd-2.3.0-2.1 still broken ; after 30 hours, xinetd-initiated services ceased
to function (same error messsages as previous bug reports) ; a complete restart
of xinetd was necessary.
Comment 11 Trond Eivind Glomsrxd 2001-07-23 23:28:56 EDT
*** Bug 49347 has been marked as a duplicate of this bug. ***
Comment 12 Andy Johnson 2001-07-25 04:22:16 EDT
Suffering the same problem on RedHat 7.0 with 2.3. Site is using network
attached serial concentrators for dumb terminal telnet sessions, with some
terminals sat just at the login prompt: causing 15-20 telnet session starts a
minute as login times out and terminates each time. Once problem occurs no-one
can start a new telnet session.

A work around seemed to be to periodically send signal 12's to the xinetd daemon
as re-reading its configuration file cures a jam but having got this down to
re-reading the setup every 3 minutes I've just downgraded to 2.1.8.9pre15 in the
hope this one works. Looks as the the 'boundary checking case fixed in 2.3.0'
added a different problem.
Comment 13 Jim Simmons 2001-07-25 07:37:38 EDT
I'm seeing the same type messages on several RedHat 7.1 i386 machines with
all errata installed.  The only thing I use through xinetd is amanda (the
amanda-client that came with 7.1).  This usually happens the first time amanda
is run after the system is booted.  Restarting xinetd usually fixes it and it
started after xinetd-2.3.0-1.71 was installed.

However, it doesn't happen on all machines.  I have a 1.33G Athlon system that
it keeps happening to but a 1.2G system (same motherboard etc) doesn't have the
problem.  From the logs:

Jul 24 21:50:01 trnpc xinetd[1758]: {general_handler} (1758) Unexpected signal: 
11 (Segmentation fault)
Jul 24 21:50:01 trnpc last message repeated 9 times
Jul 24 21:50:01 trnpc xinetd[1758]: {bad_signal} Received 10 signals in 1 second
s. Exiting...

and then eventually...
Jul 24 21:50:01 trnpc xinetd[1766]: {bad_signal} Received 10 signals in 1 second
s. Exiting...
Jul 24 21:50:01 trnpc xinetd[1767]: {general_handler} (1767) Unexpected signal: 
11 (Segmentation fault)
Jul 24 21:50:01 trnpc last message repeated 9 times
Jul 24 21:50:01 trnpc xinetd[1767]: {bad_signal} Received 10 signals in 1 second
s. Exiting...
Jul 24 21:50:01 trnpc xinetd[962]: amanda service was deactivated because of loo
Comment 14 Daniel Veillard 2001-08-06 11:39:00 EDT
Using vsftpd launched from xinetd I can report the same problems on the
rpmfind.net boxes this can break very fast ! Example:

Aug  6 17:30:36 rpmfind xinetd[12219]: {general_handler} (12219) Unexpected
signal: 11 (Segmentation fault) 
Aug  6 17:30:36 rpmfind xinetd[12219]: {bad_signal} Received 10 signals in 1
seconds. Exiting... 

I'm wondering if this could lead to a security hazard :-\

Daniel
Comment 15 Need Real Name 2001-08-09 23:57:23 EDT
I've seen "exec( (null) )" errors pop up, and if you try to start xinetd in
debugging mode, with ports that are already bound, you'll get something like
this as well:

01/8/9@19:56:55: ERROR: {activate_normal} bind failed (Address already in use
(errno = 98rNpq>?zg?r?rtz?r,r(rc). service = ftp
01/8/9@19:56:55: DEBUG: {cnf_start_services} mask_max = 0, services_started = 0
01/8/9@19:56:55: CRITICAL: {init_services} no services. Exiting...
Comment 16 Need Real Name 2001-08-10 00:50:12 EDT
OK, a little more debugging info.  On an xinetd hacked to sleep in
general_handler, the backtrace looks like this during a segv:

(gdb) bt
#0  0x2abb4c41 in __libc_nanosleep () from /lib/libc.so.6
#1  0x2abb4bcd in __sleep (seconds=30) at ../sysdeps/unix/sysv/linux/sleep.c:82
#2  0x8057a7c in general_handler ()
#3  0x2ab41c48 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#4  0x8055cf8 in server_start ()
#5  0x8055bb5 in server_run ()
#6  0x8056a54 in svc_generic_handler ()
#7  0x80569c6 in svc_request ()
#8  0x8051945 in main_loop ()
#9  0x8051809 in main ()
#10 0x2ab3b9cb in __libc_start_main (main=0x8051770 <main>, argc=2, 
    argv=0x7ffffb74, init=0x8049e18 <_init>, fini=0x80652ac <_fini>, 
    rtld_fini=0x2aab5ea0 <_dl_fini>, stack_end=0x7ffffb6c)
    at ../sysdeps/generic/libc-start.c:92

And something is definately trouncing memory.  When I get the "exec( (null) )"
message, the in-memory structures look like this (sorry, I forgot to save the
backtrace on this one):

(gdb) print *serp
$20 = {svr_pid = 0, svr_start_time = 0, svr_conn = 0x809a948, 
  svr_sp = 0x8090208, svr_fork_failures = 0, svr_exit_status = 0, 
  svr_log_remote_user = 0, svr_writes_to_log = 0}
(gdb) print *serp->svr_sp  
$21 = {svc_state = SVC_ACTIVE, svc_ref_count = 153, svc_conf = 0x809afc8, 
  svc_fd = 5, svc_running_servers = 75, svc_retry_servers = 0, 
  svc_attempts = 0, svc_start_time = 0, svc_shutdown_func = 0, 
  svc_handler_func = 0x805bfe8 <svc_generic_handler>, svc_no_access = 0x0, 
  svc_only_from = 0x0, svc_last_dgram_addr = {sin_family = 0, sin_port = 0, 
    sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, 
  svc_last_dgram_time = 0, svc_log = 0x8090258}
(gdb) print *serp->svr_sp->svc_conf
$22 = {sc_specified_attributes = 555347972331, 
  sc_attributes_present = 555347972587, sc_type = 0, sc_xflags = 2, 
  sc_name = 0x809afb8 "ftp", sc_id = 0x809bba0 "ftp", sc_port = 0, 
  sc_socket_type = 0, sc_protocol = {name = 0x0, value = 0}, sc_wait = NO, 
  sc_uid = 0, sc_user_gid = 0, sc_gid = 0, sc_server = 0x0, 
  sc_server_argv = 0x0, sc_instances = 0, sc_nice = 10, sc_env_var_defs = 0x0, 
  sc_pass_env_vars = 0x0, sc_access_times = 0x0, sc_only_from = 0x0, 
  sc_no_access = 0x0, sc_log_on_success = 85, sc_log_on_failure = 1, sc_log = {
    l_type = L_SYSLOG, l_fl = {fl_filename = 0x0, fl_soft_limit = 0, 
      fl_hard_limit = 0}, l_sl = {sl_facility = 80, sl_level = 6}}, sc_rd = {
    rd_min_version = 0, rd_max_version = 0, rd_program_number = 0}, 
  sc_disabled = 0x0, sc_enabled = 0x0, sc_environment = {env_type = STD_ENV, 
    env_handle = 0x808f1a0}, sc_builtin = 0x0, sc_redir_port = 0, 
  sc_redir_addr = 0x0, sc_bind_addr = 0x8095010, sc_banner = 0x0, 
  sc_per_source = -1, sc_groups = NO, sc_banner_success = 0x0, 
  sc_banner_fail = 0x0, sc_max_load = 0, sc_time_limit = 0, sc_time_conn = 0, 
  sc_time_conn_max = 0, sc_time_wait = 0, sc_time_reenable = 0, 
  sc_rlim_as = 0, sc_rlim_cpu = 0, sc_rlim_data = 0, sc_rlim_rss = 0, 
  sc_rlim_stack = 0, sc_umask = 0, sc_deny_time = 0}
(gdb) print *serp->svr_sp->svc_conf->sc_server
Cannot access memory at address 0x0

and the exec is called on *serp->svr_sp->svc_conf->sc_server, thus the (null).
Comment 17 Trond Eivind Glomsrxd 2001-08-15 15:57:15 EDT
Could people please try 2.3.0-6 from http://people.redhat.com/teg/xinetd/ and
give feedback?
Comment 18 Trond Eivind Glomsrxd 2001-08-15 18:56:11 EDT
2.3.0-7 is now available... please give it a try.
Comment 19 Trond Eivind Glomsrxd 2001-08-23 00:15:36 EDT
*** Bug 52365 has been marked as a duplicate of this bug. ***
Comment 20 Zenon Mousmoulas 2001-08-28 17:49:42 EDT
*** Bug 52752 has been marked as a duplicate of this bug. ***
Comment 21 Trond Eivind Glomsrxd 2001-09-12 10:49:25 EDT
2.3.3-1 was released as an errata for this
Comment 22 Trond Eivind Glomsrxd 2001-09-12 10:50:00 EDT
xinetd 2.3.3-1 was released as an errata last week.
Comment 23 Trond Eivind Glomsrxd 2001-09-12 10:50:09 EDT
*** Bug 48445 has been marked as a duplicate of this bug. ***
Comment 24 Trond Eivind Glomsrxd 2001-09-25 11:29:55 EDT
*** Bug 54005 has been marked as a duplicate of this bug. ***
Comment 25 Trond Eivind Glomsrxd 2001-09-26 16:56:09 EDT
*** Bug 53883 has been marked as a duplicate of this bug. ***
Comment 26 Need Real Name 2001-10-27 21:13:48 EDT
It looks like this is still an issue in xinetd-2.3.3-1, perhaps down a different
code path this time:

xinetd[21763]: {general_handler} (21763) Unexpected signal: 11 (Segmentation
fault)
last message repeated 9 times
xinetd[21763]: Resetting...
xinetd[21763]: ftp: fork failed: Resource temporarily unavailable (errno = 11)
xinetd[21763]: {general_handler} (21763) Unexpected signal: 11 (Segmentation
fault)
last message repeated 9 times
xinetd[21763]: Resetting...
xinetd[21763]: {general_handler} (21763) Unexpected signal: 11 (Segmentation
fault)
last message repeated 9 times
xinetd[21763]: Resetting...
xinetd[21763]: {general_handler} (21763) Unexpected signal: 11 (Segmentation
fault)
last message repeated 9 times
xinetd[21763]: Resetting...
xinetd[21763]: {general_handler} (21763) Unexpected signal: 11 (Segmentation
fault)
last message repeated 9 times
xinetd[21763]: {bad_signal} Received 50 bad signals. Exiting...

And after this, xinetd shuts down completely.  I don't have any more debugging
than this right now.
Comment 27 Trond Eivind Glomsrxd 2001-11-30 19:14:52 EST
Can you reproduce it? Nothing more showed when using memory debugging tools.
Comment 28 Trond Eivind Glomsrxd 2002-07-25 17:55:59 EDT
Closing for lack of feedback - not seen any other reports of this issue. Reopen
if it still happens with a current version.
Comment 29 Jerome Neuveglise 2002-10-16 14:51:34 EDT
The new version (xinetd-2.3.9-0.71.i386.rpm) downloaded today from RHN 
produces the same bug !! (RH7.1 fully updated via up2date, no home made kernel)

Here is an exctrat of /var/log/messages

Oct 16 20:38:58 horus xinetd[22361]: {general_handler} (22361) Unexpected 
signal: 11 (Segmentation fault)
Oct 16 20:38:58 horus xinetd[22361]: {bad_signal} Received 10 signals in 1 
seconds. Exiting...
Oct 16 20:38:58 horus xinetd: xinetd startup succeeded

And of course no xinetd process running 

Plz help !
Comment 30 Christof Damian 2002-10-22 05:24:18 EDT
i have this problem too with the xinetd-2.3.9-0.70.i386.rpm errata update.
Comment 31 mitchell mcgee 2002-10-23 09:15:28 EDT
After installing xinetd-2.3.9-0.70 cannot telnet.  Message in /var/log/messages 
is: "libwrap refused connection".  We're running RH 7.0 on i686.
Comment 32 Michael Schwendt 2002-10-23 09:30:00 EDT
> After installing xinetd-2.3.9-0.70 cannot telnet.
> Message in /var/log/messages is: "libwrap refused connection".
> We're running RH 7.0 on i686.

That sounds unrelated. You disallow connections via /etc/hosts.deny and don't
have a proper entry in /etc/hosts.allow to allow telnet.
Comment 33 Need Real Name 2002-12-21 14:07:45 EST
xinetd-2.3.7-4.7x still has some problem:

xinetd[18403]: {general_handler} (18403) Unexpected signal: 11 (Segmentation fault)
xinetd[18403]: Resetting...
xinetd[18403]: {general_handler} (18403) Unexpected signal: 11 (Segmentation fault)
xinetd[18403]: Resetting...
xinetd[18403]: {general_handler} (18403) Unexpected signal: 11 (Segmentation fault)
xinetd[18403]: Resetting...
xinetd[18403]: {general_handler} (18403) Unexpected signal: 11 (Segmentation fault)
xinetd[18403]: Resetting...
xinetd[18403]: {general_handler} (18403) Unexpected signal: 11 (Segmentation fault)
xinetd[18403]: Resetting...
xinetd[18403]: {general_handler} (18403) Unexpected signal: 11 (Segmentation fault)
xinetd[18403]: {general_handler} (18403) Unexpected signal: 11 (Segmentation fault)
xinetd[18403]: {bad_signal} Received 50 bad signals. Exiting...
Comment 34 John Fredrik Ølstørn 2003-02-13 17:55:53 EST
I'm running RH8.0 with xinetd-2.3.7-5. Seems like the problem still exist:

------
xinetd[22417]: {general_handler} (22417) Unexpected signal: 11 (Segmentation fault)
last message repeated 9 times
xinetd[22417]: Resetting...
xinetd[22417]: {general_handler} (22417) Unexpected signal: 11 (Segmentation fault)
last message repeated 9 times
xinetd[22417]: {bad_signal} Received 50 bad signals. Exiting...
------I do a 'service xinetd restart'----
xinetd: xinetd shutdown failed
xinetd[13252]: xinetd Version 2.3.7 started with libwrap options compiled in.
...blabla...

Additional info:
I've got apache with sqirrelmail running on the same server (imapd). The httpd
process was using all available CPU at the time xinetd seg.faulted...
Other packages: httpd-2.0.40-11, imap-2001a-15.
Comment 35 Terje Kvernes 2003-03-13 09:06:34 EST
same here.  it works with most services, but not when trying to use tftp.  I
then get a load of the same segmentation faults.
Comment 36 Jay Fenlason 2003-08-12 15:44:46 EDT
Has anyone tried to reproduce this while running the xinetd-2.3.11-1.7x 
erratum?  I wasn't able to reproduce the problem here. 
 
If I don't hear from folks that this problem is still active, I'll mark it as 
closed by the erratum. 
Comment 37 Kin-ichi Watanabe 2003-08-18 03:18:56 EDT
I'm running RH7.3 with xinetd-2.3.11-1.7x.
I used pop3 and pop3s services on xined.

xinetd-2.3.11-1.7x seems like the problem still exist:

Aug 16 02:35:03 hostname xinetd[608]: 608 {general_handler} (608) Unexpected
signal: 11 (Segmentation fault)
Aug 16 02:35:03 hostname last message repeated 9 times
Aug 16 02:35:03 hostname xinetd[608]: Resetting...
(xinetd process don't shutdown.)
Comment 38 Bill Nottingham 2006-08-04 16:24:05 EDT
Red Hat Linux and Red Hat Powertools are currently no longer supported by Red
Hat, Inc. In an effort to clean up bugzilla, we are closing all bugs in MODIFIED
state for these products.

However, we do want to make sure that nothing important slips through the
cracks. If, in fact, these issues are not resolved in a current Fedora Core
Release (such as Fedora Core 5), please open a new issues stating so. Thanks.

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