Bug 528834

Summary: Regression: Subversion ends with "Killed by signal 15"
Product: [Fedora] Fedora Reporter: Robert Scheck <redhat-bugzilla>
Component: subversionAssignee: Joe Orton <jorton>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 10CC: jorton, robert.scheck, vanmeeuwen+fedora, voelker
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: https://admin.fedoraproject.org/updates/F10/FEDORA-2009-9475
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-14 11:43:32 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:

Description Robert Scheck 2009-10-13 22:16:37 UTC
Description of problem:
Why is subversion getting killed all the time by signal 15 since the update?

$ svn update
Revision 603.
Killed by signal 15.
$

Version-Release number of selected component (if applicable):
subversion-1.6.5-1.fc10.1

How reproducible:
Everytime, see e.g. above.
  
Actual results:
Message "Killed by signal 15." at each SVN action as far as I can see.

Expected results:
No message "Killed by signal 15." like at versions before 1.6.5.

Comment 1 Joe Orton 2009-10-14 10:18:02 UTC
Please run:

 # debuginfo-install subversion

and send in the output of

 # rpm -qa subversion\*
 $ gdb --args /usr/bin/svn update
 ...
 (gdb) run
 (gdb) bt
 (gdb) bt full

Comment 2 Friedel Völker 2009-10-14 11:32:27 UTC
% rpm -qa subversion\*
subversion-debuginfo-1.6.5-1.fc11.x86_64
subversion-1.6.5-1.fc11.x86_64
% gdb --args /usr/bin/svn update
GNU gdb (GDB) Fedora (6.8.50.20090302-38.fc11)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) run
Starting program: /usr/bin/svn update
[Thread debugging using libthread_db enabled]
Detaching after fork from child process 11402.
Revision 0.
Killed by signal 15.

Program exited normally.
Missing separate debuginfos, use: debuginfo-install e2fsprogs-libs-1.41.4-12.fc11.x86_64 gnutls-2.6.6-3.fc11.x86_64 keyutils-libs-1.2-5.fc11.x86_64 krb5-libs-1.6.3-20.fc11.x86_64 libgcrypt-1.4.4-6.fc11.x86_64 libgpg-error-1.6-3.x86_64 libselinux-2.0.80-1.fc11.x86_64 libtasn1-1.8-2.fc11.x86_64 nss-softokn-freebl-3.12.4-3.fc11.x86_64 openssl-0.9.8k-5.fc11.x86_64 pakchois-0.4-2.x86_64
(gdb) bt
No stack.
(gdb) bt full
No stack.
(gdb)

Comment 3 Joe Orton 2009-10-14 11:35:13 UTC
So... this is an svn+ssh repos, right?

That message is coming from ssh.

Comment 4 Joe Orton 2009-10-14 11:43:32 UTC
I think this is expected behaviour.  The change is caused by the upstream fix for:

http://subversion.tigris.org/issues/show_bug.cgi?id=2580

and should work correctly in the default configuration.  I'll bet you have:

[tunnels]
ssh = ssh

or similar configured in your ~/.subversion/config? If so, simply tweak that to be

  ssh = ssh -q

to fix it (effectively restoring the default configuration).  The message is only cosmetic, in any case.

Comment 5 Robert Scheck 2009-10-14 11:46:09 UTC
Yes, it's svn+ssh. We have an empty [tunnels] section as created by the 
subversion shipped with Fedora 11 initially.

Comment 6 Robert Scheck 2009-10-14 11:47:00 UTC
(or as from Fedora 10 initially for the Fedora 10 issue of course)

Comment 7 Robert Scheck 2009-10-14 11:58:13 UTC
Colleagues and me had a

  export SVN_SSH="ssh -i $HOME/.ssh/subversion/id_rsa"

in our .bashrc, changed that now to 

  export SVN_SSH="ssh -q -i $HOME/.ssh/subversion/id_rsa"

to get it working. The ~/.subversion/config is not relevant here as changes
to that have simply no effect.

Joe, thanks for your help.