Bug 48367
| Summary: | telnet service fails after a couple of hours with xinetd-2.3.0 | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <bmilner> |
| Component: | xinetd | Assignee: | Jay Fenlason <fenlason> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | aander07, andyj, bbraun, christof, daniel, d.bz-redhat, herrold, jfeeney, john, kin, mark_h_johnson, simmonsjw, tmcsween, tsombakos_mark |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-08-04 20:24:05 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: | |||
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. 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 No heavy load on server. Temporary resolution : service xinetd reload 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)
...
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? 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 ! 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. 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)
Running xinetd-2.3.0-2.1 for a solid 18 hours now (light load) without any error messages (knock wood). 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.
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. *** Bug 49347 has been marked as a duplicate of this bug. *** 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. 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
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
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...
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).
Could people please try 2.3.0-6 from http://people.redhat.com/teg/xinetd/ and give feedback? 2.3.0-7 is now available... please give it a try. *** Bug 52365 has been marked as a duplicate of this bug. *** *** Bug 52752 has been marked as a duplicate of this bug. *** 2.3.3-1 was released as an errata for this xinetd 2.3.3-1 was released as an errata last week. *** Bug 48445 has been marked as a duplicate of this bug. *** *** Bug 54005 has been marked as a duplicate of this bug. *** *** Bug 53883 has been marked as a duplicate of this bug. *** 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.
Can you reproduce it? Nothing more showed when using memory debugging tools. Closing for lack of feedback - not seen any other reports of this issue. Reopen if it still happens with a current version. 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 !
i have this problem too with the xinetd-2.3.9-0.70.i386.rpm errata update. 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. > 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.
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...
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.
same here. it works with most services, but not when trying to use tftp. I then get a load of the same segmentation faults. 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. 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.)
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. |
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)