Bug 1301543

Summary: [abrt] systemd: __read_nocancel(): systemd-journald killed by SIGABRT
Product: [Fedora] Fedora Reporter: Bill Gianopoulos <wgianopoulos>
Component: systemdAssignee: systemd-maint
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: johannbg, jsynacek, lnykryn, msekleta, muadda, s, systemd-maint, wgianopoulos, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/52a6ef2670910c4d769d8c87d61917612faa7055
Whiteboard: abrt_hash:26215adbea2d4d2729a6f8af96e9883c65a01804;VARIANT_ID=workstation;
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-25 17:17:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: mountinfo
none
File: namespaces
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Bill Gianopoulos 2016-01-25 11:06:43 UTC 
Version-Release number of selected component:
systemd-228-7.gite35a787.fc24

Additional info:
reporter:       libreport-2.6.3
backtrace_rating: 4
cmdline:        /usr/lib/systemd/systemd-journald
crash_function: __read_nocancel
executable:     /usr/lib/systemd/systemd-journald
global_pid:     467
kernel:         4.5.0-0.rc0.git8.1.fc24.x86_64
runlevel:       N 5
type:           CCpp
uid:            0

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 __read_nocancel at ../sysdeps/unix/syscall-template.S:84
 #1 _IO_new_file_underflow at fileops.c:592
 #2 _IO_default_uflow at genops.c:413
 #3 _IO_getline_info at iogetline.c:60
 #4 _IO_getline at iogetline.c:34
 #5 _IO_fgets at iofgets.c:53
 #6 fgets at /usr/include/bits/stdio2.h:263
 #7 cg_pid_get_path.constprop.112 at src/basic/cgroup-util.c:836
 #8 cg_pid_get_path_shifted at src/basic/cgroup-util.c:1223
 #9 dispatch_message_real.lto_priv.266 at src/journal/journald-server.c:658

Potential duplicate: bug 1237069
Comment 1 Bill Gianopoulos 2016-01-25 11:06:49 UTC 
Created attachment 1117900 [details]
File: backtrace
Comment 2 Bill Gianopoulos 2016-01-25 11:06:50 UTC 
Created attachment 1117901 [details]
File: cgroup
Comment 3 Bill Gianopoulos 2016-01-25 11:06:51 UTC 
Created attachment 1117902 [details]
File: core_backtrace
Comment 4 Bill Gianopoulos 2016-01-25 11:06:52 UTC 
Created attachment 1117903 [details]
File: dso_list
Comment 5 Bill Gianopoulos 2016-01-25 11:06:53 UTC 
Created attachment 1117904 [details]
File: environ
Comment 6 Bill Gianopoulos 2016-01-25 11:06:54 UTC 
Created attachment 1117905 [details]
File: limits
Comment 7 Bill Gianopoulos 2016-01-25 11:06:55 UTC 
Created attachment 1117906 [details]
File: maps
Comment 8 Bill Gianopoulos 2016-01-25 11:06:56 UTC 
Created attachment 1117907 [details]
File: mountinfo
Comment 9 Bill Gianopoulos 2016-01-25 11:06:57 UTC 
Created attachment 1117908 [details]
File: namespaces
Comment 10 Bill Gianopoulos 2016-01-25 11:06:58 UTC 
Created attachment 1117909 [details]
File: open_fds
Comment 11 Bill Gianopoulos 2016-01-25 11:06:59 UTC 
Created attachment 1117910 [details]
File: proc_pid_status
Comment 12 Bill Gianopoulos 2016-01-25 11:07:00 UTC 
Created attachment 1117911 [details]
File: var_log_messages
Comment 13 Jan Synacek 2016-01-25 12:51:30 UTC 
Any idea what was happening with your computer's hard drive when the crash happened? Any heavy disk loads?
Comment 14 Bill Gianopoulos 2016-01-25 16:18:27 UTC 
(In reply to Jan Synacek from comment #13)
> Any idea what was happening with your computer's hard drive when the crash
> happened? Any heavy disk loads?

So, this has been happening for a week or so now on two of my laptops.  What is going on with the hard drive is it is external hard drive attached via USB, so slower than normal.  The laptops run fedora 23 on the internal drive and i have rawhide installed on the usb drive. I have 2 of these rawhide USB drives BTW and the results are the same with both.

I have a Lenovo All-in-one system and a Samsung Laptop neither of which seem affected by this issue.

However, I have an ASUS and an HP both of which have this problem so bad that I can't even get the system to be able to log in and do anything in graphical mode, in order to do anything I have to boot to the multi-user target and just use command line.  For most of these reports I was running a dnf upgrade.

I can attach the output of an lshw from all 4 of the systems if you think that would help.
Comment 15 Zbigniew Jędrzejewski-Szmek 2016-01-25 17:17:33 UTC 
It's enough info that it's a USB drive. Those are slow, and have high latetency too.

*** This bug has been marked as a duplicate of bug 1300212 ***