Discuss

discuss@lists.centos.org

3 participants
34748 discussions

Hung kernel task on CentOS 7.2, fprintd and libvirtd
by Warren Young 01 Mar '16

01 Mar '16

A CentOS 7 box here recently started being very slow to give the Password prompt when using sudo. (25 seconds!) I eventually tracked this down to the following complaint in the kernel message log: > Feb 26 12:55:05 badboy kernel: INFO: task fprintd:1932 blocked for more than 120 seconds. > Feb 26 12:55:05 badboy kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Feb 26 12:55:05 badboy kernel: fprintd D ffff88021f7300f8 0 1932 1 0x00000080 > Feb 26 12:55:05 badboy kernel: ffff88022354bdc0 0000000000000086 ffff8800c54e8000 ffff88022354bfd8 > Feb 26 12:55:05 badboy kernel: ffff88022354bfd8 ffff88022354bfd8 ffff8800c54e8000 ffff88021f7300f0 > Feb 26 12:55:05 badboy kernel: ffff88021f7300f4 ffff8800c54e8000 00000000ffffffff ffff88021f7300f8 > Feb 26 12:55:05 badboy kernel: Call Trace: > Feb 26 12:55:05 badboy kernel: [<ffffffff8163b9e9>] schedule_preempt_disabled+0x29/0x70 > Feb 26 12:55:05 badboy kernel: [<ffffffff816396e5>] __mutex_lock_slowpath+0xc5/0x1c0 > Feb 26 12:55:05 badboy kernel: [<ffffffff81638b4f>] mutex_lock+0x1f/0x2f > Feb 26 12:55:05 badboy kernel: [<ffffffff81449729>] read_descriptors+0x39/0x110 > Feb 26 12:55:05 badboy kernel: [<ffffffff8125c28b>] ? read+0x6b/0x1f0 > Feb 26 12:55:05 badboy kernel: [<ffffffff8125c2fb>] read+0xdb/0x1f0 > Feb 26 12:55:05 badboy kernel: [<ffffffff811de43c>] vfs_read+0x9c/0x170 > Feb 26 12:55:05 badboy kernel: [<ffffffff811def8f>] SyS_read+0x7f/0xe0 > Feb 26 12:55:05 badboy kernel: [<ffffffff81645909>] system_call_fastpath+0x16/0x1b Since fprintd is the fingerprint reader daemon and this server doesn’t have such a peripheral, I removed the service. Now sudo is fast again. [*] Although that solves my immediate problem, while debugging all of this I noticed substantially the same error message also appearing for libvirtd: > Feb 26 12:57:05 badboy kernel: INFO: task libvirtd:1514 blocked for more than 120 seconds. > Feb 26 12:57:05 badboy kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Feb 26 12:57:05 badboy kernel: libvirtd D ffff88021f7300f8 0 1514 1 0x00000080 > Feb 26 12:57:05 badboy kernel: ffff8800c08ffde0 0000000000000086 ffff8800c550e780 ffff8800c08fffd8 > Feb 26 12:57:05 badboy kernel: ffff8800c08fffd8 ffff8800c08fffd8 ffff8800c550e780 ffff88021f7300f0 > Feb 26 12:57:05 badboy kernel: ffff88021f7300f4 ffff8800c550e780 00000000ffffffff ffff88021f7300f8 > Feb 26 12:57:05 badboy kernel: Call Trace: > Feb 26 12:57:05 badboy kernel: [<ffffffff8163b9e9>] schedule_preempt_disabled+0x29/0x70 > Feb 26 12:57:05 badboy kernel: [<ffffffff816396e5>] __mutex_lock_slowpath+0xc5/0x1c0 > Feb 26 12:57:05 badboy kernel: [<ffffffff81638b4f>] mutex_lock+0x1f/0x2f > Feb 26 12:57:05 badboy kernel: [<ffffffff81449100>] manufacturer_show+0x20/0x50 > Feb 26 12:57:05 badboy kernel: [<ffffffff813f1c20>] dev_attr_show+0x20/0x60 > Feb 26 12:57:05 badboy kernel: [<ffffffff8125928a>] sysfs_read_file+0x9a/0x1a0 > Feb 26 12:57:05 badboy kernel: [<ffffffff811de43c>] vfs_read+0x9c/0x170 > Feb 26 12:57:05 badboy kernel: [<ffffffff811def8f>] SyS_read+0x7f/0xe0 > Feb 26 12:57:05 badboy kernel: [<ffffffff81645909>] system_call_fastpath+0x16/0x1b I don’t want to employ the same solution in this case — i.e. disable libvirtd — because while I don’t yet use KVM on that server, I actually had plans to do so soon. I could host those VMs elsewhere, but that feels like sweeping the problem under the rug. I want to fix this, but I’m now stuck. I’ve ruled out several possible causes already: 1. It isn’t DNS. DNS responds quickly. 2. It isn’t a flaky OS drive. Swapping the spinning rust drive out for an SSD was already on the wish list for this system, so I took the opportunity to reinstall the OS fresh on a brand new SSD. The same problem occurred shortly after booting CentOS 7.2 for the first time, and it continues to happen periodically. The only thing I’ve copied over from the old spinning drive so far is /home and /usr/local, and I can’t see how that could affect the kernel. Besides, the problem still occurs while booted into single-user mode. 3. It isn’t the RAID card. A RAID verify pass completed successfully, as did smartctl -t long tests on all of the individual drives. I even disabled the RAID card’s OPROM and blacklisted its driver at one point, just to see if the driver or RAID BIOS were the cause of the problem. I haven’t actually pulled the card yet, but that seems unlikely to solve anything, given that the array seems to be storing data reliably. 4. It isn’t the RAM. It just passed a memtest86+ run. That probably exonerates the CPU and north bridge, too. (I used v4.20 from the CentOS 7.2 install ISO.) 5. It isn’t stale packages. The OS reinstall proves that. It’s currently running the tip of CentOS 7.2 and still showing the same symptoms. 6. It isn’t high-uptime kernel space cruft, since it’s been rebooted a bunch of times during all of this, including several hard reboots. Rebooting is especially painful at the moment because the system hangs on shutdown waiting for libvirtd to respond. While I had fprintd installed, that was causing 3-minute hangs on boot, too. Very frustrating! [*] In case it isn’t clear how fprintd could affect sudo, it’s because fprintd installs a PAM module, and sudo uses PAM for authentication. If fprintd is stuck, the PAM call stalls until it gives up and moves on. I tracked this down with strace. The 25 seconds above is the timeout value passed to poll(2); that timeout is hit while sudo (via PAM) is trying to talk to dbus, since apparently fprintd communicates via dbus. Because the problem is in PAM and not sudo, it also affected su. It did not affect console or ssh user logins for some reason. I’m posting these details in case this diagnosis helps someone. While chasing this, I found a bunch of postings on the net from people who have run into such problems before, but none of the threads mentioned this particular failure mode. For all I know, I’m the first person it’s ever happened to, so this needs to be in the archives.

2 2

Discarding empty lines in rsyslog
by Anand Buddhdev 29 Feb '16

29 Feb '16

Dear CentOS folk, I've been try to solve one issue with rsyslog on CentOS 6, but can't figure it out. I've searched through rsyslog documentation, and used Google but not found anything that matches my issue. I'm sending output of a program to rsyslog using "logger -t progname". I've got the following config snippet in /etc/rsyslog.d: $FileCreateMode 0644 if $programname == 'progname' then /var/log/prog.log & ~ This works. However, the program sometimes produces blank lines its output, and they get logged by rsyslog as well. I want to make rsyslog ignore empty lines. I am trying the following, but it doesn't work: if $programname == 'progname' and $msg != '\n' then /var/log/prog.log Does anyone know how to get this to work in rsyslog? This is rsyslog 5 on CentOS 6. Regards, Anand

1 1

Odd selinux complaints on new, fully updated CentOS 7
by m.roth＠5-cent.us 29 Feb '16

29 Feb '16

Just installed 7.2, and I'm seeing this - is this a bug in the policy? ************************** SELinux is preventing systemd-readahe from add_name access on the directory .readahead.new. ***** Plugin catchall_labels (83.8 confidence) suggests ******************* If you want to allow systemd-readahe to have add_name access on the .readahead.new directory Then you need to change the label on .readahead.new Do # semanage fcontext -a -t FILE_TYPE '.readahead.new' where FILE_TYPE is one of the following: device_t, init_var_run_t, readahead_var_lib_t, readahead_var_run_t, root_t, var_run_t. Then execute: restorecon -v '.readahead.new' ***** Plugin catchall (17.1 confidence) suggests ************************** If you believe that systemd-readahe should be allowed add_name access on the .readahead.new directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep systemd-readahe /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:readahead_t:s0 Target Context system_u:object_r:mnt_t:s0 Target Objects .readahead.new [ dir ] Source systemd-readahe Source Path systemd-readahe Port <Unknown> Host <hostname> Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-60.el7_2.3.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name <hostname> Platform Linux <hostname> 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 Alert Count 4 First Seen 2016-02-29 10:06:27 EST Last Seen 2016-02-29 16:50:22 EST Local ID 0ba32e6a-e502-45be-a2dc-cda4c380a2bb Raw Audit Messages type=AVC msg=audit(1456782622.230:435): avc: denied { add_name } for pid=410 comm="systemd-readahe" name=".readahead.new" scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Hash: systemd-readahe,readahead_t,mnt_t,dir,add_name ***************************************** mark

1 0

Changing default file type in Centos 6
by H 28 Feb '16

28 Feb '16

It turns out my markdown files - extension .md - are of the "Genesis ROM" file type in Centos 6. Googling did not turn up any obvious places to change this in Gnome - neither in my local directory or in /etc/gnome. Where would I be able to change this default file type for files with the extension .md? I have already changed the default application to geany (with the markdown extension.) Thank you.

4 12

Restoring session status
by H 27 Feb '16

27 Feb '16

I am running CentOS 6.6 on both a couple of servers and on a laptop. When I let the laptop sleep, window states and positions are restored correctly when I awaken it. However, when I shut down the laptop, later turn it on and log in, none of the terminal windows and directory windows are restored correctly to e.g. minimized state, instead they are restored to when they last were in use. Naturally, this is a little bit annoying: have I missed a setting somewhere? Thanks.

2 2

CentOS-announce Digest, Vol 132, Issue 7
by centos-announce-request＠centos.org 27 Feb '16

27 Feb '16

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. Release for CentOS Linux 7 Rolling media Feb 2016 (Karanbir Singh) ---------------------------------------------------------------------- Message: 1 Date: Sat, 27 Feb 2016 00:37:51 +0000 From: Karanbir Singh <kbsingh(a)centos.org> To: CentOS Announcements List <centos-announce(a)centos.org> Subject: [CentOS-announce] Release for CentOS Linux 7 Rolling media Feb 2016 Message-ID: <56D0EFDF.5040304(a)centos.org> Content-Type: text/plain; charset=utf-8 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am pleased to announce general availability of the Feb 2016 snapshot for CentOS Linux. This release includes CentOS Linux 7 iso based install media, Generic Cloud images, Atomic Host, Docker containers, Vagrant images, vendor hosted cloud images. This release set is tag'd 1602 CentOS Linux rolling builds are point in time snapshot media rebuild from original release time, to include all updates pushed to mirror.centos.org's repositories. This includes all security, bugfix, enhancement and general updates for CentOS Linux. Machines installed from this media will have all these updates pre-included and will look no different when compared with machines installed with older media that have been yum updated to the same point in time. All rpm/yum repos remain on mirror.centos.org with no changes in either layout or content. - -------- CentOS Linux 7 / x86_64 install media is available at http://buildlogs.centos.org/rolling/7/isos/x86_64/ File: CentOS-7-x86_64-Minimal-1602-01.iso Sha: 741a28e3d42c40ded2e42b83eda4d8d09137b36ceef584753b94abd298d4dfed File: CentOS-7-x86_64-Everything-1602-01.iso Sha: 6cc79d3f3183318d0089cb04dbfd97418ff009f6fb01bce4849289ede96df45d File: CentOS-7-x86_64-DVD-1602-01.iso Sha: 34120f3bc02e1edd6d5b19516876c8456a1300de4b98da79fb0a7d444d1df3d8 - -------- CentOS Linux 7 / x86_64 Cloud Images are available at : http://cloud.centos.org/centos/7/images/ File: CentOS-7-x86_64-GenericCloud-1602.qcow2 Sha: 1b777fa1ea2b2cf0be7ed6ecce54ef18ece5c6551fb291549b887e33b78d7c78 File: CentOS-7-x86_64-GenericCloud-1602.qcow2c Sha: bc0f51d9376001f8973595b71105b9d53c8c27b3e0969676aab2ab036cc4d835 File: CentOS-7-x86_64-GenericCloud-1602.qcow2.xz Sha: dd0f5e610e7c5ffacaca35ed7a78a19142a588f4543da77b61c1fb0d74400471 File: CentOS-7-x86_64-GenericCloud-1602.raw.tar.gz Sha: f4e679eef79af695bd8f2cb32d37fa93c7cb4644eb79f689bde6bd86100e4af5 - -------- CentOS Atomic Host was released earlier, details for the release are available at : https://lists.centos.org/pipermail/centos-devel/2016-February/014446.htm l - -------- CentOS Linux 6 and 7 AMIs have been updated as well, as follows: CentOS Linux 6 : https://aws.amazon.com/marketplace/pp/B00NQAYLWO/ CentOS Linux 7 : https://aws.amazon.com/marketplace/pp/B00O7WM7QW/ These images are also now enabled across all Amazon EC2 regions, and available on all HVM instance types. This includes the Amazon AWS free tier. - -------- CentOS Linux 7 / x86_64 Vagrant images are updated at https://vagrantcloud.com/centos/boxes/7 and the backing files can be downloaded for libvirt and virtualbox providers at : Libvirt: http://cloud.centos.org/centos/7/vagrant/x86_64/images/CentOS-7-x86_64-V agrant-1602_02.LibVirt.box Virtualbox: http://cloud.centos.org/centos/7/vagrant/x86_64/images/CentOS-7-x86_64-V agrant-1602_02.VirtualBox.box - -------- CentOS Linux 5 / 6 and 7 docker images are updated at http://index.docker.io/_/centos - -------- We welcome all feedback around these rolling builds and media updates at the centos-devel mailing list ( http://lists.centos.org/ ). enjoy! - -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJW0O/fAAoJEI3Oi2Mx7xbt0KwH/RUBoINSas2fADErpw0HFJI+ 8QmRa5sH6X5vvBodWMT5qiulkof06IgX6psrniCzYejt88OP0XUjuA0lEh9MUq4a Ie7X5TnXIndH0eGU3UQIivXRojeSTdDjNmbdTQehxTN5WfA/tml29eppMBRt6xEi K56/Ml2FxdU/b1EkCBO68VWcZvAl6gxmtLJv38sFn2WxepDjyrHGF+A10sJqGYt6 V7E32iZqZDwkSmuWwHdf7T0NH9DE9TxcIH/IsRUnYAcwqLcGZm+WqFoD6KRafVAM e2KvLr/L9NwaU6C6rZVWJ1yHwBaYH87xNEGcr69mpR2HJQt3PrlkiTC4wXVKpRg= =015B -----END PGP SIGNATURE----- ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 132, Issue 7 ***********************************************

1 0

Question about cleanly unmounting slave bind mounts
by likan_999.student＠sina.com 27 Feb '16

27 Feb '16

Hi, I asked the question on stackexchange (http://unix.stackexchange.com/questions/264931/centos-7-unable-to-cleanly-u…) and CentOS 7 bug report (https://bugs.centos.org/view.php?id=10414) but didn't get any useful response, so I am thinking if I can get some help here. The problem arose when I tried to rbind mount /dev and /proc to a chroot sandbox and to unmount it, I have to set the mount to slave so that unmounting submounts of <sandbox-root>/dev (e.g. /dev/pts) won't unmount submounts of /dev. This works for other distributions such as Fedora 23 and Ubuntu 14.04, but under CentOS 7, umount succeeds but the directory can't be removed. For some reason, I have to stick to CentOS 7, so I wonder if there is a work around for it. The steps to reproduce: [hidden]$ mkdir -p A B/a C/b [hidden]$ sudo mount --bind A B/a [hidden]$ sudo mount --rbind B C/b [hidden]$ sudo mount --make-rslave C/b [hidden]$ sudo umount C/b/a [hidden]$ sudo umount C/b [hidden]$ rmdir C/b rmdir: failed to remove ‘C/b’: Device or resource busy None of mount, cat /proc/mounts, cat /etc/mtab, sudo lsof, sudo fuser C/b shows any process using the directory C/b; stat C/b shows it is different inode than B, meaning it has already been unmounted successfully. The kernel version is 3.10.0-327.10.1.el7.x86_64. Any suggestion is welcomed.附件（0个）全部下载超大附件（0个）

1 0

CentOS Extras SRPMs for 7.1 / 7.2
by Pierre Riteau 26 Feb '16

26 Feb '16

Hello, I noticed that recent source repositories for CentOS Extras packages do not have SRPMs for each available RPM. In particular, I wanted to download the SRPM for cloud-init. After enabling the extras-source repository, `yumdownloader --source cloud-init` doesn't find any package. This used to work on CentOS 7.0. See the content of the following two repos: http://vault.centos.org/7.2.1511/extras/Source/SPackages/ http://vault.centos.org/7.1.1503/extras/Source/SPackages/ compared with http://vault.centos.org/7.0.1406/extras/Source/SPackages/ It looks like only packages which were updated have made it in the newer repositories. Thanks, Pierre

2 1

Internet Storm Center blogpost on rootcheck (a system auditor)
by Gilbert Sebenste 26 Feb '16

26 Feb '16

Hello everyone, If you haven't seen it: https://isc.sans.edu/forums/diary/Quick+Audit+of+NIX+Systems/20771/ I just compiled and ran it on CentOS 5 and 6. The audit came up clean for me. It's worth a run to see if you have anything blatant wrong...or to see if you have been rooted. Gilbert ******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************

1 0

Skylake Installs on CentOS-7
by Johnny Hughes 26 Feb '16

26 Feb '16

We were informed that many people were having issues on newer intel (Skylake) platforms installing the latest CentOS-7 and asked if we could find/fix the problem. We found that the latest kernel, kernel-3.10.0-327.10.1.el7, fixes this issue on some machines, so we rebuilt the installer for people having issues. Please see this mail for the new isos: https://lists.centos.org/pipermail/centos-devel/2016-February/014444.html If you are not having issues, you will want to continue to use the standard installers as they provide better support for 3rd party kernel modules, etc. Thanks, Johnny Hughes

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss