[CentOS] default MPM
Hi folks What is the default MPM in apache on CentOS 7? Thanks in advance! -- -- Sergio Belkin http://www.sergiobelkin.com LPIC-2 Certified - http://www.lpi.org ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS-announce Digest, Vol 115, Issue 4
Send CentOS-announce mailing list submissions to centos-annou...@centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-requ...@centos.org You can reach the person managing the list at centos-announce-ow...@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. The epel-release package is now available via Extras (Jim Perrin) 2. CEBA-2014:1140 CentOS 6 avahi BugFix Update (Johnny Hughes) 3. CEBA-2014:1139 CentOS 6 initscripts BugFix Update (Johnny Hughes) 4. CEBA-2014:1141 CentOS 6 openscap BugFix Update (Johnny Hughes) 5. CESA-2014:1146 Important CentOS 7 httpcomponents-client Security Update (Johnny Hughes) 6. CESA-2014:1147 Important CentOS 7 squid Security Update (Johnny Hughes) 7. CESA-2014:1144 Critical CentOS 7 xulrunnerSecurity Update (Johnny Hughes) 8. CESA-2014:1144 Critical CentOS 7 firefox Security Update (Johnny Hughes) 9. CESA-2014:1148 Important CentOS 6 squid Security Update (Johnny Hughes) 10. CESA-2014:1144 Critical CentOS 6 firefox Security Update (Johnny Hughes) 11. CESA-2014:1145 Important CentOS 6 thunderbird Security Update (Johnny Hughes) 12. CESA-2014:1148 Important CentOS 5 squid Security Update (Johnny Hughes) 13. CESA-2014:1144 Critical CentOS 5 firefox Security Update (Johnny Hughes) 14. CESA-2014:1143 Moderate CentOS 5 kernel Security Update (Johnny Hughes) 15. CESA-2014:1145 Important CentOS 5 thunderbird Security Update (Johnny Hughes) 16. CEBA-2014:1150 CentOS 6 cpio BugFix Update (Johnny Hughes) -- Message: 1 Date: Wed, 03 Sep 2014 08:12:06 -0500 From: Jim Perrin jper...@centos.org To: centos-annou...@centos.org Subject: [CentOS-announce] The epel-release package is now available via Extras Message-ID: 540713a6.2000...@centos.org Content-Type: text/plain; charset=ISO-8859-1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The CentOS project is pleased to announce that the epel-release package is now included in the CentOS Extras repositories for all current versions of CentOS. In order to use packages from the EPEL repository, users may 'yum install epel-release' NOTE: This does not change the existing support structure for either EPEL or CentOS. If you encounter a bug with a package from EPEL, please file the bug with EPEL. CentOS will continue to provide best effort support for distribution packages. - -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJUBxOmAAoJEBbHyC76Ca13Jz0QAMLzbG2BOYe+5E06uhAIgw72 tAoLudNTjjs3XLQCbHIjZNrr3RaugX2lxLk5CAHq4VnuVOqv1vBalbb49LJJJlft 3RbdXowASNWU4yihqQjO5STsqIEHX7hfqqBjkWadeQAxA1iZhXT+x5eFsgz84iF6 hN1mUwlr6vv6EW6wKMD1M61LihNM8uqWRyyigD8g6RxmHAdw1Ernr8pXV6U0pbU4 Rk9jAlI6xeYP+m0QVs4ppNnRowk9P6O761pi4wThtrpETJAptWf67aNfLzGHR3zA 1VVoBDKUzMFYcqBczVL/JblHebB0oTfKq7iQF+W7mK6YlaaK/YFRTrcL1kIbpIT/ he6aSJjVC8DGpKLu5kI3shxU1UoI7jmB0IQ0oF/RuX3L1fD/T/pe6dFwQb4n3AEw zzlU6I6+bIZMsjXdWaREFXMFbeGiAQqYFOfUY5GxYAj1HzNWU0zg4duhB7/nfxm8 XOooAp05bnh5U7jFoNkba6zh5b65cXQHBvJn9J9MD7VdKrSNvazaWrrf7tZ2LIXl 9Ci27JUg/PWcWz7fVzcRXGMdIa/9dWQqLhvVaCQAtGog7CZ9cxUTgINYZFkU3wDg 7pvuSpe994tLIEd4ubvOynkgF7BnS3Z369JTUrVkPY3hylL5nn/q3OpzGqOb12YO 8jxBMl9DKWbPEicl8Qth =fA85 -END PGP SIGNATURE- -- Message: 2 Date: Wed, 3 Sep 2014 14:10:28 + From: Johnny Hughes joh...@centos.org To: centos-annou...@centos.org Subject: [CentOS-announce] CEBA-2014:1140 CentOS 6 avahi BugFix Update Message-ID: 20140903141028.ga43...@n04.lon1.karan.org Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2014:1140 Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-1140.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: c05c0eb98850d7593eec0089f6d64c2a81df5bdf2e0cce873cc1b4666dee1191 avahi-0.6.25-12.el6_5.3.i686.rpm 2c50f0628744b47f86a89dfb4f283e6cd56ac611aec8712539fad14538100c1d avahi-autoipd-0.6.25-12.el6_5.3.i686.rpm 83c3e0768d5fcf1a0a4bb0188bfc0249ccc4410aedc3a5b9c191fc2d5e9abf40 avahi-compat-howl-0.6.25-12.el6_5.3.i686.rpm 77c57e79803d17f2740987963484dae2289df53ed7f9b13b6e2ab86d6ccc86e1 avahi-compat-howl-devel-0.6.25-12.el6_5.3.i686.rpm adf9582d2f1dce306949df07ce752c9e647dd2f66df34e7cf35c7323c2ba6f92 avahi-compat-libdns_sd-0.6.25-12.el6_5.3.i686.rpm b4493e6f26c2b36827bbfbd21a83e58b2ecf964bd0e52601be977388fea91948 avahi-compat-libdns_sd-devel-0.6.25-12.el6_5.3.i686.rpm
[CentOS] Kernel errors after updating
Hi all,
I have updated my Centos 6.5 KVM host to kernel 2.6.32-431.23.3 this
morning ... After 2 hours working, the following kernel error appears
and all vm guests goes slowly
device monif4 entered promiscuous mode
monif: port 5(monif4) entering forwarding state
INFO: task cgroup:83 blocked for more than 120 seconds.
Not tainted 2.6.32-431.23.3.el6.x86_64 #1
echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message.
cgroupD 0009 083 2 0x
880411cb9d60 0046
880411cb2aa0
880411cb3058 880411cb9fd8 fbc8 880411cb3058
Call Trace:
[8152a36e] __mutex_lock_slowpath+0x13e/0x180
[810d24d0] ? do_rebuild_sched_domains+0x0/0x50
[8152a20b] mutex_lock+0x2b/0x50
[810c97b5] cgroup_lock+0x15/0x20
[810d24e8] do_rebuild_sched_domains+0x18/0x50
[81094a20] worker_thread+0x170/0x2a0
[8109afa0] ? autoremove_wake_function+0x0/0x40
[810948b0] ? worker_thread+0x0/0x2a0
[8109abf6] kthread+0x96/0xa0
[8100c20a] child_rip+0xa/0x20
[8109ab60] ? kthread+0x0/0xa0
[8100c200] ? child_rip+0x0/0x20
INFO: task cgroup:83 blocked for more than 120 seconds.
Not tainted 2.6.32-431.23.3.el6.x86_64 #1
echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message.
cgroupD 0009 083 2 0x
880411cb9d60 0046
880411cb2aa0
880411cb3058 880411cb9fd8 fbc8 880411cb3058
Call Trace:
[8152a36e] __mutex_lock_slowpath+0x13e/0x180
[810d24d0] ? do_rebuild_sched_domains+0x0/0x50
[8152a20b] mutex_lock+0x2b/0x50
[810c97b5] cgroup_lock+0x15/0x20
[810d24e8] do_rebuild_sched_domains+0x18/0x50
[81094a20] worker_thread+0x170/0x2a0
[8109afa0] ? autoremove_wake_function+0x0/0x40
[810948b0] ? worker_thread+0x0/0x2a0
[8109abf6] kthread+0x96/0xa0
[8100c20a] child_rip+0xa/0x20
[8109ab60] ? kthread+0x0/0xa0
[8100c200] ? child_rip+0x0/0x20
INFO: task cgroup:83 blocked for more than 120 seconds.
Not tainted 2.6.32-431.23.3.el6.x86_64 #1
echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message.
cgroupD 0009 083 2 0x
880411cb9d60 0046
880411cb2aa0
880411cb3058 880411cb9fd8 fbc8 880411cb3058
Call Trace:
[8152a36e] __mutex_lock_slowpath+0x13e/0x180
[810d24d0] ? do_rebuild_sched_domains+0x0/0x50
[8152a20b] mutex_lock+0x2b/0x50
[810c97b5] cgroup_lock+0x15/0x20
[810d24e8] do_rebuild_sched_domains+0x18/0x50
[81094a20] worker_thread+0x170/0x2a0
[8109afa0] ? autoremove_wake_function+0x0/0x40
[810948b0] ? worker_thread+0x0/0x2a0
[8109abf6] kthread+0x96/0xa0
[8100c20a] child_rip+0xa/0x20
[8109ab60] ? kthread+0x0/0xa0
[8100c200] ? child_rip+0x0/0x20
INFO: task cgroup:83 blocked for more than 120 seconds.
Not tainted 2.6.32-431.23.3.el6.x86_64 #1
echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message.
cgroupD 0009 083 2 0x
880411cb9d60 0046
880411cb2aa0
880411cb3058 880411cb9fd8 fbc8 880411cb3058
Call Trace:
[8152a36e] __mutex_lock_slowpath+0x13e/0x180
[810d24d0] ? do_rebuild_sched_domains+0x0/0x50
[8152a20b] mutex_lock+0x2b/0x50
[810c97b5] cgroup_lock+0x15/0x20
[810d24e8] do_rebuild_sched_domains+0x18/0x50
[81094a20] worker_thread+0x170/0x2a0
[8109afa0] ? autoremove_wake_function+0x0/0x40
[810948b0] ? worker_thread+0x0/0x2a0
[8109abf6] kthread+0x96/0xa0
[8100c20a] child_rip+0xa/0x20
[8109ab60] ? kthread+0x0/0xa0
[8100c200] ? child_rip+0x0/0x20
INFO: task cgroup:83 blocked for more than 120 seconds.
Not tainted 2.6.32-431.23.3.el6.x86_64 #1
echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message.
cgroupD 0009 083 2 0x
880411cb9d60 0046
880411cb2aa0
880411cb3058 880411cb9fd8 fbc8 880411cb3058
Call Trace:
[8152a36e] __mutex_lock_slowpath+0x13e/0x180
[810d24d0] ? do_rebuild_sched_domains+0x0/0x50
[8152a20b] mutex_lock+0x2b/0x50
[810c97b5] cgroup_lock+0x15/0x20
[810d24e8]
Re: [CentOS] *very* ugly mdadm issue
On 09/02/2014 07:36 PM, Joseph L. Casale wrote: Wait just a minute. How can you use the raw device but still have a GPT on it? That doesn't seem right, to have a GUID Partition Table but no partitions. Have you never deleted all the partitions on a disk under any scheme before? Of course; but in the context of an MD RAID device with member devices as raw disks I would not expect a partition table of any kind, GPT or otherwise. Whether it can be there or not is not my point; it's whether it's expected or not. Now, for C6 the default RAID superblock is version 1.2; but if you were to create a version 1.1 superblock it would go on the very first sector of the raw device, and would overwrite the partition table. (The 1.2 superblock goes 4K in from the first sector; prior to 1.1 the superblock went to the last sector of the drive). Of course, ext4 at least for block group 0 skips the first 1k bytes. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel errors after updating
Here I have the same error, but we're using VMware. I tried to change de
type os SCSI controller on VMware and the CentOS loaded other module too,
but the VMs continues to displays this timeout erros on dmesg. The machine
just do not respond to anything, and 3~5min after, it turns back to life.
I tried the MPT (mptscsih) and de VMware (vmw_pvscsi) module, in many
kernel and CentOS version; all with the same error. I've also found this
same error on old kernels like 2.6.18-308.4.1.el5.
Did you got this erros too?
mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=8801378bdb80)
mptscsih: ioc0: attempting task abort! (sc=88013782b2c0)
Or:
sd 2:0:1:0: [sdb] task abort on host 2, 880432fdb8c0
sd 2:0:5:0: [sdf] task abort on host 2, 880432fdb1c0
--
Rodrigo Bezerra Brasil
Belém, PA, BR
Intelligence is the ability to avoid doing work, yet getting the work done.
-Linus Torvalds
OpenPGP hex keyID: 0xB05DAFA91AA38CA7
On Thu, Sep 4, 2014 at 11:19 AM, C. L. Martinez carlopm...@gmail.com
wrote:
Hi all,
I have updated my Centos 6.5 KVM host to kernel 2.6.32-431.23.3 this
morning ... After 2 hours working, the following kernel error appears
and all vm guests goes slowly
device monif4 entered promiscuous mode
monif: port 5(monif4) entering forwarding state
INFO: task cgroup:83 blocked for more than 120 seconds.
Not tainted 2.6.32-431.23.3.el6.x86_64 #1
echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message.
cgroupD 0009 083 2 0x
880411cb9d60 0046
880411cb2aa0
880411cb3058 880411cb9fd8 fbc8 880411cb3058
Call Trace:
[8152a36e] __mutex_lock_slowpath+0x13e/0x180
[810d24d0] ? do_rebuild_sched_domains+0x0/0x50
[8152a20b] mutex_lock+0x2b/0x50
[810c97b5] cgroup_lock+0x15/0x20
[810d24e8] do_rebuild_sched_domains+0x18/0x50
[81094a20] worker_thread+0x170/0x2a0
[8109afa0] ? autoremove_wake_function+0x0/0x40
[810948b0] ? worker_thread+0x0/0x2a0
[8109abf6] kthread+0x96/0xa0
[8100c20a] child_rip+0xa/0x20
[8109ab60] ? kthread+0x0/0xa0
[8100c200] ? child_rip+0x0/0x20
INFO: task cgroup:83 blocked for more than 120 seconds.
Not tainted 2.6.32-431.23.3.el6.x86_64 #1
echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message.
cgroupD 0009 083 2 0x
880411cb9d60 0046
880411cb2aa0
880411cb3058 880411cb9fd8 fbc8 880411cb3058
Call Trace:
[8152a36e] __mutex_lock_slowpath+0x13e/0x180
[810d24d0] ? do_rebuild_sched_domains+0x0/0x50
[8152a20b] mutex_lock+0x2b/0x50
[810c97b5] cgroup_lock+0x15/0x20
[810d24e8] do_rebuild_sched_domains+0x18/0x50
[81094a20] worker_thread+0x170/0x2a0
[8109afa0] ? autoremove_wake_function+0x0/0x40
[810948b0] ? worker_thread+0x0/0x2a0
[8109abf6] kthread+0x96/0xa0
[8100c20a] child_rip+0xa/0x20
[8109ab60] ? kthread+0x0/0xa0
[8100c200] ? child_rip+0x0/0x20
INFO: task cgroup:83 blocked for more than 120 seconds.
Not tainted 2.6.32-431.23.3.el6.x86_64 #1
echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message.
cgroupD 0009 083 2 0x
880411cb9d60 0046
880411cb2aa0
880411cb3058 880411cb9fd8 fbc8 880411cb3058
Call Trace:
[8152a36e] __mutex_lock_slowpath+0x13e/0x180
[810d24d0] ? do_rebuild_sched_domains+0x0/0x50
[8152a20b] mutex_lock+0x2b/0x50
[810c97b5] cgroup_lock+0x15/0x20
[810d24e8] do_rebuild_sched_domains+0x18/0x50
[81094a20] worker_thread+0x170/0x2a0
[8109afa0] ? autoremove_wake_function+0x0/0x40
[810948b0] ? worker_thread+0x0/0x2a0
[8109abf6] kthread+0x96/0xa0
[8100c20a] child_rip+0xa/0x20
[8109ab60] ? kthread+0x0/0xa0
[8100c200] ? child_rip+0x0/0x20
INFO: task cgroup:83 blocked for more than 120 seconds.
Not tainted 2.6.32-431.23.3.el6.x86_64 #1
echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message.
cgroupD 0009 083 2 0x
880411cb9d60 0046
880411cb2aa0
880411cb3058 880411cb9fd8 fbc8 880411cb3058
Call Trace:
[8152a36e] __mutex_lock_slowpath+0x13e/0x180
[810d24d0] ? do_rebuild_sched_domains+0x0/0x50
[8152a20b]
[CentOS] Dojo at Fossetcon (Orlando, FL) 11 Sep.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If any of you are attending Fossetcon next week in Orlando, FL, please join us for a CentOS Dojo on Thursday 11 Sep. http://wiki.centos.org/Events/Dojo/Orlando2014 * Garrett Honeycutt - Why Automation is Important * Dmitri Pal - Active Directory Integration * Greg Sheremeta - oVirt all-in-one tutorial Jim Perrin and Johnny Hughes will be running the event. (You can also find them at the event all week, and Jim is giving a talk on Software Collections on Friday afternoon[1].) After lunch is a hackfest working on Xen, Docker, and oVirt around CentOS Linux. If you wish to attend, register here: http://www.eventbrite.co.uk/e/centos-dojo-orlando-fl-2014-tickets-12923345073 Thanks! - - Karsten [1] http://fossetcon.org/2014/schedule - -- Karsten 'quaid' Wade.^\ CentOS Doer of Stuff http://TheOpenSourceWay.org\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQIokwACgkQ2ZIOBq0ODEGyCgCgzJWMgyiKa33AcDNATB82ik7E QsgAoJ3dBeJ2fQssx+9hflFbS8RA1Sja =wNPM -END PGP SIGNATURE- ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] *very* ugly mdadm issue
On Thu, Sep 4, 2014 at 9:59 AM, Lamar Owen lo...@pari.edu wrote: Of course; but in the context of an MD RAID device with member devices as raw disks I would not expect a partition table of any kind, GPT or otherwise. Whether it can be there or not is not my point; it's whether it's expected or not. Now, for C6 the default RAID superblock is version 1.2; but if you were to create a version 1.1 superblock it would go on the very first sector of the raw device, and would overwrite the partition table. (The 1.2 superblock goes 4K in from the first sector; prior to 1.1 the superblock went to the last sector of the drive). Does that mean autodetection/assembly would be possible with 1.2 but not 1.1? I've always considered that to be one of the best features of software raid. Of course, ext4 at least for block group 0 skips the first 1k bytes. How does this mesh with the ability to mount a RAID1 member as a normal non-raid partition? I've done that for data recovery but never knew if it was safe to write that way. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] *very* ugly mdadm issue [Solved, badly]
Ok, folks, Here's the answer: making a software RAID on a bare drive with no GPT works fine. If it has a GPT, and no partition, it fails on reboot, even with an /etc/mdadm.conf. I've proved this: first, I created the array on the bare drive, rebooted, and /dev/md0 was there; then, I used parted to create a gpt, then the array, reboot, no md0, even with mdadm --assemble, even with /etc/mdadm.conf. finally, I got rid of the disk label (parted to make an msdos label, the zeroing out the beginning of the disk), and again made the RAID on the bare drives, reboot, and md0 is there. So that's what killed me. Admins, take heed mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] *very* ugly mdadm issue [Solved, badly]
On Thu, Sep 4, 2014 at 3:30 PM, m.r...@5-cent.us wrote: Ok, folks, Here's the answer: making a software RAID on a bare drive with no GPT works fine. If it has a GPT, and no partition, it fails on reboot, even with an /etc/mdadm.conf. I've proved this: first, I created the array on the bare drive, rebooted, and /dev/md0 was there; then, I used parted to create a gpt, then the array, reboot, no md0, even with mdadm --assemble, even with /etc/mdadm.conf. finally, I got rid of the disk label (parted to make an msdos label, the zeroing out the beginning of the disk), and again made the RAID on the bare drives, reboot, and md0 is there. So that's what killed me. Admins, take heed mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Thanks for the followup. :) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] *very* ugly mdadm issue [Solved, badly]
Tom Bishop wrote: On Thu, Sep 4, 2014 at 3:30 PM, m.r...@5-cent.us wrote: Here's the answer: making a software RAID on a bare drive with no GPT works fine. If it has a GPT, and no partition, it fails on reboot, even with an /etc/mdadm.conf. I've proved this: first, I created the array on the bare drive, rebooted, and /dev/md0 was there; then, I used parted to create a gpt, then the array, reboot, no md0, even with mdadm --assemble, even with /etc/mdadm.conf. finally, I got rid of the disk label (parted to make an msdos label, the zeroing out the beginning of the disk), and again made the RAID on the bare drives, reboot, and md0 is there. So that's what killed me. Admins, take heed Thanks for the followup. :) Yup. My manager had asked me to figure it out, and as it just so happened our director wound up needing more space on another machine, that I could reboot as I will, I could do the testing. mark, watch out for the gotchas ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
