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
Created attachment 1117900 [details] File: backtrace
Created attachment 1117901 [details] File: cgroup
Created attachment 1117902 [details] File: core_backtrace
Created attachment 1117903 [details] File: dso_list
Created attachment 1117904 [details] File: environ
Created attachment 1117905 [details] File: limits
Created attachment 1117906 [details] File: maps
Created attachment 1117907 [details] File: mountinfo
Created attachment 1117908 [details] File: namespaces
Created attachment 1117909 [details] File: open_fds
Created attachment 1117910 [details] File: proc_pid_status
Created attachment 1117911 [details] File: var_log_messages
Any idea what was happening with your computer's hard drive when the crash happened? Any heavy disk loads?
(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.
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 ***