Bug 856212 - ssh is consuming 100% of CPU
ssh is consuming 100% of CPU
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Lautrbach
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-11 09:03 EDT by Mauro Carvalho Chehab
Modified: 2013-08-01 05:13 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 05:13:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mauro Carvalho Chehab 2012-09-11 09:03:30 EDT
Description of problem:

I use a fetchmail process that starts ssh to fetch email from one of my inboxes.
Typically, it starts one ssh session on every minute, fetches IMAP4 data from it and closes.

From time to time, one of those ssh clients enter into some dead lock condition, eating almost 100% of the CPU time, like those:

mchehab  11437 97.9  0.0  75368  1860 ?        R    09:46   8:00 ssh -a -2 -4 -x -q -C mchehab@some_server exec /usr/sbin/dovecot --exec-mail imap
mchehab  15751 92.6  0.1  75368  4072 ?        R    09:53   1:28 ssh -a -2 -4 -x -q -C mchehab@some_server exec /usr/sbin/dovecot --exec-mail imap

I can't remember exactly when it started to appear, but I didn't notice the bug when I upgraded this machine to F17. So, I suspect it is due to some changes either at openssh or on some of its library dependencies.

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

openssh-5.9p1-26.fc17.x86_64

How reproducible:

On my environment with one ssh fetch on every minute, the bug hits a few times during the day.

Steps to Reproduce:
1. set fetchmail to use imap by adding the lines below at .fetchmailrc:

poll some_server
	with proto IMAP auth ssh
	plugin "ssh -a -2 -4 -x -q -C my_user@%h exec /usr/sbin/dovecot --exec-mail imap"
	folder INBOX
	mda "/usr/libexec/dovecot/deliver"

2. start fetchmail with "fetchmail -d60"
3. wait for a while for the ssh proccess to eat 100% of the CPU.
Comment 1 Tomas Mraz 2012-09-11 09:36:53 EDT
We would need a backtrace from such ssh process to be able to investigate further.
Comment 2 Mauro Carvalho Chehab 2012-09-11 11:10:08 EDT
(In reply to comment #1)
> We would need a backtrace from such ssh process to be able to investigate
> further.

#0  0x00007f622b347b84 in __GI___poll (fds=fds@entry=0x7f622f311528, nfds=1, 
    timeout=timeout@entry=-973651) at ../sysdeps/unix/sysv/linux/poll.c:83
#1  0x00007f622bacf0eb in cm_select_or_poll (sret=<synthetic pointer>, out=0x7f622f311528, 
    in=0x7f622f30f510) at sendto_kdc.c:530
#2  service_fds (context=context@entry=0x7f622f30b0c0, selstate=selstate@entry=0x7f622f30f510, 
    interval=interval@entry=1, conns=conns@entry=0x7f622f30cf30, 
    seltemp=seltemp@entry=0x7f622f311528, 
    msg_handler=msg_handler@entry=0x7f622bace880 <check_for_svc_unavailable>, 
    msg_handler_data=msg_handler_data@entry=0x7fff22eca458, 
    winner_out=winner_out@entry=0x7fff22eca328) at sendto_kdc.c:1163
#3  0x00007f622bacff3c in k5_sendto (context=context@entry=0x7f622f30b0c0, 
    message=message@entry=0x7fff22eca4f0, servers=servers@entry=0x7fff22eca460, 
    socktype1=socktype1@entry=2, socktype2=1, callback_info=callback_info@entry=0x0, 
    reply=reply@entry=0x7fff22eca500, remoteaddr=remoteaddr@entry=0x0, 
    remoteaddrlen=remoteaddrlen@entry=0x0, server_used=server_used@entry=0x7fff22eca45c, 
    msg_handler=msg_handler@entry=0x7f622bace880 <check_for_svc_unavailable>, 
    msg_handler_data=msg_handler_data@entry=0x7fff22eca458) at sendto_kdc.c:1290
#4  0x00007f622bad03e4 in krb5_sendto_kdc (context=context@entry=0x7f622f30b0c0, 
    message=message@entry=0x7fff22eca4f0, realm=realm@entry=0x7fff22eca510, 
    reply=reply@entry=0x7fff22eca500, use_master=use_master@entry=0x7fff22eca4ec, 
    tcp_only=tcp_only@entry=0) at sendto_kdc.c:339
#5  0x00007f622ba9fc55 in krb5_tkt_creds_get (context=context@entry=0x7f622f30b0c0, 
    ctx=0x7f622f30c520) at get_creds.c:1151
#6  0x00007f622ba9fde4 in krb5_get_credentials (context=context@entry=0x7f622f30b0c0, 
    options=options@entry=0, ccache=<optimized out>, in_creds=in_creds@entry=0x7fff22eca5e0, 
    out_creds=out_creds@entry=0x7fff22eca5d8) at get_creds.c:1229
#7  0x00007f622bd3629a in get_credentials (context=context@entry=0x7f622f30b0c0, 
    cred=cred@entry=0x7f622f30dc20, now=1347375165, endtime=<optimized out>, 
    out_creds=out_creds@entry=0x7fff22eca850, server=<optimized out>) at init_sec_context.c:195
#8  0x00007f622bd4f430 in kg_new_connection (exts=0x7fff22eca960, context=0x7f622f30b0c0, 
---Type <return> to continue, or q <return> to quit---
    time_rec=0x0, ret_flags=0x0, output_token=0x7fff22ecab10, actual_mech_type=0x0, 
    input_token=0x7f622f30e640, input_chan_bindings=0x0, time_req=0, req_flags=34, 
    mech_type=<optimized out>, target_name=0x7f622f30d6e0, context_handle=0x7f622f30d640, 
    cred=0x7f622f30dc20, minor_status=0x7f622f30ae24) at init_sec_context.c:610
#9  krb5_gss_init_sec_context_ext (minor_status=0x7f622f30ae24, 
    claimant_cred_handle=0x7f622f30dc20, context_handle=0x7f622f30d640, 
    target_name=0x7f622f30d6e0, mech_type=<optimized out>, req_flags=34, 
    time_req=time_req@entry=0, input_chan_bindings=input_chan_bindings@entry=0x0, 
    input_token=input_token@entry=0x0, actual_mech_type=actual_mech_type@entry=0x0, 
    output_token=output_token@entry=0x7fff22ecab10, ret_flags=ret_flags@entry=0x0, 
    time_rec=time_rec@entry=0x0, exts=exts@entry=0x7fff22eca960) at init_sec_context.c:1000
#10 0x00007f622bd4fbc7 in krb5_gss_init_sec_context (minor_status=<optimized out>, 
    claimant_cred_handle=<optimized out>, context_handle=<optimized out>, 
    target_name=<optimized out>, mech_type=<optimized out>, req_flags=<optimized out>, 
    time_req=0, input_chan_bindings=0x0, input_token=0x0, actual_mech_type=0x0, 
    output_token=0x7fff22ecab10, ret_flags=0x0, time_rec=0x0) at init_sec_context.c:1108
#11 0x00007f622bd3f644 in gss_init_sec_context (minor_status=minor_status@entry=0x7f622f30ae24, 
    claimant_cred_handle=0x0, context_handle=context_handle@entry=0x7f622f30ae28, 
    target_name=0x7f622f30af90, req_mech_type=<optimized out>, req_flags=34, 
    time_req=time_req@entry=0, input_chan_bindings=input_chan_bindings@entry=0x0, 
    input_token=input_token@entry=0x0, actual_mech_type=actual_mech_type@entry=0x0, 
    output_token=0x7fff22ecab10, ret_flags=0x0, time_rec=time_rec@entry=0x0)
    at g_init_sec_context.c:211
#12 0x00007f622da76510 in ssh_gssapi_init_ctx (ctx=0x7f622f30ae20, 
    deleg_creds=deleg_creds@entry=0, recv_tok=recv_tok@entry=0x0, 
    send_tok=send_tok@entry=0x7fff22ecab10, flags=flags@entry=0x0) at gss-genr.c:354
#13 0x00007f622da7680e in ssh_gssapi_check_mechanism (ctx=ctx@entry=0x7fff22ecab70, 
    oid=<optimized out>, host=host@entry=0x7f622f3080a0 "canuck.infradead.org", client=0x0)
    at gss-genr.c:478
#14 0x00007f622da49c99 in userauth_gssapi (authctxt=0x7fff22ecac70) at sshconnect2.c:727
---Type <return> to continue, or q <return> to quit---
#15 0x00007f622da4b951 in userauth (authctxt=0x7fff22ecac70, 
    authlist=0x7f622f3098b0 "publickey,gssapi-keyex,gssapi-with-mic,password")
    at sshconnect2.c:526
#16 0x00007f622da6e757 in dispatch_run (mode=mode@entry=0, done=done@entry=0x7fff22ecac98, 
    ctxt=ctxt@entry=0x7fff22ecac70) at dispatch.c:98
#17 0x00007f622da4b5be in ssh_userauth2 (local_user=local_user@entry=0x7f622f2fe010 "mchehab", 
    server_user=server_user@entry=0x7f622f2eb380 "mchehab", 
    host=host@entry=0x7f622f2fdff0 "canuck.infradead.org", 
    sensitive=sensitive@entry=0x7f622dc9e920) at sshconnect2.c:490
#18 0x00007f622da473dd in ssh_login (sensitive=sensitive@entry=0x7f622dc9e920, 
    orighost=<optimized out>, hostaddr=hostaddr@entry=0x7f622dc9e8a0, port=22, 
    pw=pw@entry=0x7f622f2ec800, timeout_ms=-1000) at sshconnect.c:1178
#19 0x00007f622da3bceb in main (ac=<optimized out>, av=<optimized out>) at ssh.c:929
Comment 3 Fedora End Of Life 2013-07-03 22:42:13 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 5 Fedora End Of Life 2013-08-01 05:13:14 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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