Discuss

discuss@lists.centos.org

34758 discussions

ext4 deadlock issue
by Joakim Ziegler 30 Mar '13

30 Mar '13

I'm having an occasional problem with a box. It's a Supermicro 16-core Xeon, running CentOS 6.3 with kernel 2.6.32-279.el6.x86_64, 96 gigs of RAM, and an Areca 1882ix-24 RAID controller with 24 disks, 23 in RAID6 plus a hot spare. The RAID is divided into 3 partitions, two of 25 TB plus one for the rest. Lately, I've noticed sporadic hangs on writing to the RAID, which "resolve" themselves with the following message in dmesg: INFO: task jbd2/sdb2-8:3607 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. jbd2/sdb2-8 D 000000000000000a 0 3607 2 0x00000080 ffff881055d03d20 0000000000000046 ffff881055d03ca0 ffffffff811ada77 ffff8810552e2400 ffff88109c6566e8 0000000000002f38 ffff8810546e1540 ffff8810546e1af8 ffff881055d03fd8 000000000000fb88 ffff8810546e1af8 Call Trace: [<ffffffff811ada77>] ? __set_page_dirty+0x87/0xf0 [<ffffffff810923be>] ? prepare_to_wait+0x4e/0x80 [<ffffffffa01e881f>] jbd2_journal_commit_transaction+0x19f/0x14b0 [jbd2] [<ffffffff810096f0>] ? __switch_to+0xd0/0x320 [<ffffffff8107e00c>] ? lock_timer_base+0x3c/0x70 [<ffffffff810920d0>] ? autoremove_wake_function+0x0/0x40 [<ffffffffa01eef78>] kjournald2+0xb8/0x220 [jbd2] [<ffffffff810920d0>] ? autoremove_wake_function+0x0/0x40 [<ffffffffa01eeec0>] ? kjournald2+0x0/0x220 [jbd2] [<ffffffff81091d66>] kthread+0x96/0xa0 [<ffffffff8100c14a>] child_rip+0xa/0x20 [<ffffffff81091cd0>] ? kthread+0x0/0xa0 [<ffffffff8100c140>] ? child_rip+0x0/0x20 I get two of these messages in close succession, then things proceed normally. It doesn't happen often, and only under load. I'm uncertain, but think it might just happen once per boot, once it's happened, it doesn't repeat until rebooting. I'm not sure of this, however. Things otherwise seem fine, other logs, RAID controller event logs, RAID controller physical disk status and health reports are normal, etc. After getting this error once, attempting to re-write the exact same file on the filesystem gets no errors and works normally, so I doubt it's a physical thing with the drives anyway. Anyone seen anything like this before? It's not very frequent, but it's very annoying. -- Joakim Ziegler - Supervisor de postproducción - Terminal joakim(a)terminalmx.com - 044 55 2971 8514 - 5264 0864

2 7

cronie: /usr/bin/run-parts
by Max Pyziur 30 Mar '13

30 Mar '13

Greetings, Per the subject line, what controls the time of the running of scripts located in the /etc/cron.[daily|weekly|hourly] directories? Specifically with CentOS 6.* I've noticed that scripts in /etc/cron.daily and /etc/cron.weekly run at different times of the day, or on different days. In my experience on other rpm-based distributions, cron daily and weekly scripts run at 4am; those that are run weekly run at 4am on Sunday morning. Much thanks in advance, Max Pyziur pyz(a)brama.com

3 3

iptables settings for X11 forwarding in CentOS 6.2
by Pat Haley 30 Mar '13

30 Mar '13

Hi, We recently installed CentOS 6.2 on our cluster. During the installation/debugging of various secondary software, we had disabled iptables. When we re-enabled them, we found that the front-end would no longer X11 forward (although it does so when the iptables are off). What do we need to set in the iptables to permit X11 forwarding? Currently we're using iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT iptables -A INPUT -m limit --limit 15/minute -j LOG --log-level 7 --log-prefix "Dropped by firewall: " iptables -A INPUT -i eth1 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth1 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth1 -p tcp --dport 8080 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth1 -p tcp --dport 6000 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth1 -p tcp --dport 6001 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth1 -p tcp --dport 6002 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth1 -p tcp --dport 6003 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth1 -p tcp --dport 6004 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth1 -p tcp --dport 6005 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth1 -p udp --dport 177 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth1 -p udp --dport 6000 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth1 -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i eth1 -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Pat Haley Email: phaley(a)mit.edu Center for Ocean Engineering Phone: (617) 253-6824 Dept. of Mechanical Engineering Fax: (617) 253-8125 MIT, Room 5-213 http://web.mit.edu/phaley/www/ 77 Massachusetts Avenue Cambridge, MA 02139-4301

4 5

Re: [CentOS] a-gnome-oyences
by m.roth＠5-cent.us 30 Mar '13

30 Mar '13

Gordon Messmer wrote: > On 03/28/2013 07:00 AM, m.roth(a)5-cent.us wrote: >> Most of my users are on kde, as am I (I really don't like gnome). I've got one on gnome, though, CentOS 6.4, and I have a problem: I have to start >> an agent running ->on login<-, so that the same one is in the environment >> of every term window he opens. > That would be the normal configuration. >> In kde, no problem, I modify /etc/X11/xinit/xinitrc-common so that code >> in there calls our (newer) ssh-agent instead of the stock one. >> (And, of course, it's killed on logout, and there's only one running, >> not one every time that never go away unless killed manually.) > You're already making things more complicated than they should be. The ssh agent is supposed to be the parent process of your login session. That is, your login session should be: > ssh-agent startkde > or: > ssh-agent gnome-session Well, no. If you look at the stock /etc/X11/xinit/xinitrc-common. at the bottom of the file, that's where it sets this stuff. As I said, we *have* to use the compiled from more recent versions of ssh, because the current stock version doesn't support US gov't PIV cards for authentication. And doing this, I only get one agent, and it gets killed automagically when I log out, as expected. > With GDM, you'd modify the session file in /usr/share/xsessions. You'd a) /usr/share? Why are system-wide configuration files NOT IN /etc? b) UTF-8? What freakin' morons decided it shouldn't be plain ascii, like everything else? #$%^&*$%^&*($%^&*($%^&*(%^&*()_+ No matter what I open it in, it keeps showing up with garbage chars. So I look at /etc/gdm, as I said, and I see it sourcing /etc/X11/xinit/xinitrc-common, where I've got it set to reference our agent. Then I go further down, and see <snip>*************** case "$1" in failsafe) exec -l $SHELL -c "xterm -geometry 80x24-0-0" ;; gnome|gnome-session) # lack of SSH_AGENT is intentional, see #441123. though # the whole thing should really happen in xinitrc.d anyway. exec -l $SHELL -c gnome-session exec /bin/sh -c "exec -l $SHELL -c \"gnome-session\"" ;; kde|kde1|kde2) exec $CK_XINIT_SESSION $SSH_AGENT /bin/sh -c "exec -l $SHELL -c \"startkde\"" <snip>*************** Pause for some googling, ah, here's my answer that's less ugly, from <https://ask.fedoraproject.org/question/10225/is-it-possible-to-replace-gnom…>, which is to create /etc/X11/xinit/Xclients.d/Xclients.gnome-session.sh, whose contents are #!/bin/sh exec -l $SHELL -c "$SSH_AGENT gnome-session" > prefix the "Exec" line with "ssh-agent ", and be done. As those files would be <snip> > Xclients, which runs your session. You shouldn't need to change > anything at all, unless your newer ssh-agent is at a different path. > So, in that case, the only thing you should need to change is to > run gnome-session-properties, and uncheck "SSH Key Agent". First, of course it's in a different path. Second, no, I do *not* want to run a gnome thing - I need to a) do this from a command line, and b) fix it so it can be built that way, or updated. This isn't my machine, I've got dozens of users, and need to administer this remotely, without having to make them stop what they're doing so I can screw with this. Ok, I followed the guy's instructions, but a) I'm afraid to let the keyring not run, and b) I get the one agent running... but gnome-keyring-agent runs *after* it, and so overwrites the environment variables, which means this is the final trick I need to resolve. As a first question on that, in that created file, /etc/X11/xinit/Xclients.d/Xclients.gnome-session.sh, I've got the one line; however, in /etc/gdn/Xession (really /etc/X11/Xsession), to start gnome, it has, as you can see above, *two* execs. Any idea why, and any idea where I can start the agent so that the environment variables are *not* overwritten by gnome-keyring-agent. mark

2 3

new version of wireshark
by Steve Clark 29 Mar '13

29 Mar '13

Hello, Has anyone seen an el6 rpm of wireshark-1.8.6 Thanks, -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark(a)netwolves.com http://www.netwolves.com

3 2

CentOS 6.4, TigerVNC, and always-on feature
by Mark Holloway 29 Mar '13

29 Mar '13

I just finished a fresh install of CentOS 6.4 and successfully configured Tiger VNC. I can now VNC to the server. In previous version of CentOS 5.x, I could modify /etc/X11/xorg.conf so that when I VNC to the server I am seeing the same desktop as someone who is sitting in front of the machine (ie. their session, all open windows, etc.). The tutorial for creating this "always on" type of VNC connection is here --> http://wiki.centos.org/HowTos/VNC-Server#head-7e0dadd72b0ddd9c84381b053b440… The tutorial says to modify /etc/X11/xorg.conf but this file no longer exists in CentOS 6.4. Is there another way to configure VNC for "always on"? Thanks, Mark

2 2

CentOS Dojo at Antwerp on the 8th Apr 2013
by Karanbir Singh 29 Mar '13

29 Mar '13

hi guys, I just want to drop in a quick note about the first ever CentOS Dojo that is taking place in Antwerp on the 8th April - if you are in the area, or can get there - I highly recommend you come along. Its going to be a great day, with lots of face to face tech conversations and user stories on and around real world challenges on CentOS. http://wiki.centos.org/Events/Dojo/Antwerp2013 has the lineup of people doing the sessions; Plus we have sponsored Lunch and maybe a few beers at the end, along with lots of socialising and networking opportunities during the day. In addition to the lineup, we also have an open CentOS forum that runs for an hour, where anyone can ask any question about the CentOS project, its past, its present and where we are heading - and any concern that people might have about the project. We will also have open spaces, where people can get up, do a quick ignite like 5 min talk about pretty much anything ( we just ask that everyone imagine their grand mother is also watching, so keep content sanity in mind ). The sessions run like Dojo sessions, so they are not like talks at a conference, this is a lot more user interactive and driven around the CentOS mindset - so no one is trying to sell you anything or make their toys look better than someone elses. There are only a few tickets left, so register soon! http://centosdojoantwerp2013.eventbrite.com/ Note: For all you US side people, hang tight - we have something coming you way soon as well. Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

Re: [CentOS] yum configuration
by m.roth＠5-cent.us 29 Mar '13

29 Mar '13

Ron Loftin wrote: > > On Fri, 2013-03-29 at 15:22 +0200, Andreas K. wrote: >> On 29-03-2013 14:59, Stephen Harris wrote: >> > On Fri, Mar 29, 2013 at 02:54:58PM +0200, Andreas K. wrote: >> >> >> >> baseurl=ftp://yum.xx.xx.xx.xx/pub/linux/centos/$releasever/os/$basearch/ Is there a way to force a 6.3 machine to remain at 6.3 until a human being decides that is is time to do so? >> > >> > Change releasever to 6.3 for base and updates and any other repo that might refer to it. >> >> thanks for replying. >> I was hoping ot a more dynamic approach though since the number of affected machines is in excess of 150. > > If you're dealing with that number of machines you may wish to consider setting up your own internal repo. Then you can sync your repo to the mirrors on your schedule, move to a later version on your schedule, and so on. <snip> Seconded. And in the repo, all you'd have to do is have a symlink of 6 -> 6.3. mark

2 1

yum configuration
by Andreas K. 29 Mar '13

29 Mar '13

As it stands now (or at least that is what I think) when CentOS moves from one minor version to another (6.3 to 6.4) the 6.3 version machines automatically pick up the upgrade and the next time you do yum upgrade all of the upgrades are applied. This happens because in the repo configs (in our case) we have baseurl=ftp://yum.xx.xx.xx.xx/pub/linux/centos/$releasever/os/$basearch/ Is there a way to force a 6.3 machine to remain at 6.3 until a human being decides that is is time to do so? thanx

3 3

CentOS-announce Digest, Vol 97, Issue 17
by centos-announce-request＠centos.org 29 Mar '13

29 Mar '13

Send CentOS-announce mailing list submissions to centos-announce(a)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-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. CESA-2013:0690 Important CentOS 5 bind97 Update (Johnny Hughes) 2. CESA-2013:0689 Important CentOS 6 bind Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Thu, 28 Mar 2013 23:25:41 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CESA-2013:0690 Important CentOS 5 bind97 Update To: centos-announce(a)centos.org Message-ID: <20130328232541.GA7954(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2013:0690 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2013-0690.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 42079863147d415c4ba6e04364762964bc422df93ae6dd8c3db177b5974775ff bind97-9.7.0-17.P2.el5_9.1.i386.rpm 8b92ac3a40c297fcc49e8c68acfa63b59476976dfdf77b6e1b96dad252301b6f bind97-chroot-9.7.0-17.P2.el5_9.1.i386.rpm bc949ba766120d1afd36b0011abef24dedf4c8a1495dd65fa1624ab0270c970c bind97-devel-9.7.0-17.P2.el5_9.1.i386.rpm f946b80f0a1b0a7e7ac3d36b1d52ac86eb86cb19d140f6f6a66b4d83882a1dfb bind97-libs-9.7.0-17.P2.el5_9.1.i386.rpm 80855bc857e8891efdc99c18e0845be3e6dbc55e76fa12b8c60655843a1a5f37 bind97-utils-9.7.0-17.P2.el5_9.1.i386.rpm x86_64: b2892bd9869b16158951dbc387cec469af74ca9ed549d80ae21b95342da91662 bind97-9.7.0-17.P2.el5_9.1.x86_64.rpm 5db4729f775229f984f9fa6a5132b2bc3ebd2151b2c5545ee0b9fd9d45ba4189 bind97-chroot-9.7.0-17.P2.el5_9.1.x86_64.rpm bc949ba766120d1afd36b0011abef24dedf4c8a1495dd65fa1624ab0270c970c bind97-devel-9.7.0-17.P2.el5_9.1.i386.rpm 527e53e13a9eb7248e0b0336c549141d095c3b13e2035b130d47e99f7868b47d bind97-devel-9.7.0-17.P2.el5_9.1.x86_64.rpm f946b80f0a1b0a7e7ac3d36b1d52ac86eb86cb19d140f6f6a66b4d83882a1dfb bind97-libs-9.7.0-17.P2.el5_9.1.i386.rpm fb3909c52a321f0261b6617b4e5d66c6fa07c3f52870f9330280603006856c73 bind97-libs-9.7.0-17.P2.el5_9.1.x86_64.rpm 64051a5297427ebfe8f7d7075a0a51edf805651e10d6cc43c6d286167e7dc140 bind97-utils-9.7.0-17.P2.el5_9.1.x86_64.rpm Source: b2dbca781e4e513a6b1852f5d6e44c7513c4507390949486e9a6b1bffaed959c bind97-9.7.0-17.P2.el5_9.1.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Fri, 29 Mar 2013 00:19:00 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CESA-2013:0689 Important CentOS 6 bind Update To: centos-announce(a)centos.org Message-ID: <20130329001900.GA11087(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2013:0689 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2013-0689.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 7fc8986003f534ddd06038b6bb8d964936ae4f54d77d1a5dc82884eb3adb6e93 bind-9.8.2-0.17.rc1.el6_4.4.i686.rpm 3b54ec24dbd6fc7c8e4bcd06108db9e0806bd70c2820571bc5b94353f72863fd bind-chroot-9.8.2-0.17.rc1.el6_4.4.i686.rpm 9184ddc07f88468a6790fea719631faf2609d5cf2ac3c4c172dc02985c3573af bind-devel-9.8.2-0.17.rc1.el6_4.4.i686.rpm 17b559f44e2f08b046b603884ad79ef730e29e7d4b08c3c4c4ce75df152176f2 bind-libs-9.8.2-0.17.rc1.el6_4.4.i686.rpm 2e0df9c026015936388bd86faabaf097889a90055f0c9fd4676e97bdff521078 bind-sdb-9.8.2-0.17.rc1.el6_4.4.i686.rpm da2b841d3cdbbdb9f87e54e0936a7978c2237d80d7c3e78ac84c6b4e731abfcd bind-utils-9.8.2-0.17.rc1.el6_4.4.i686.rpm x86_64: 5e6775a1bb0dfd3e130deec98b9ea3ff645f1feb378cf8604df6a10de26a6e0b bind-9.8.2-0.17.rc1.el6_4.4.x86_64.rpm 603502fd0ad6435921bb1d067f935e2f583ccefcb77a4f4854befe7a86388c60 bind-chroot-9.8.2-0.17.rc1.el6_4.4.x86_64.rpm 9184ddc07f88468a6790fea719631faf2609d5cf2ac3c4c172dc02985c3573af bind-devel-9.8.2-0.17.rc1.el6_4.4.i686.rpm 27e0ef453dd6a9f0186bddef6948ae40ec324d26aaeeaef296b97184e17235c7 bind-devel-9.8.2-0.17.rc1.el6_4.4.x86_64.rpm 17b559f44e2f08b046b603884ad79ef730e29e7d4b08c3c4c4ce75df152176f2 bind-libs-9.8.2-0.17.rc1.el6_4.4.i686.rpm 160f95883fab038a8d6abc0386a5bd72b2c73921ee1e7cf946ea4c2c287d1d89 bind-libs-9.8.2-0.17.rc1.el6_4.4.x86_64.rpm c3217d931429c09c7b13b4f5adcfc818e94370be538de24baf9f482c19d63623 bind-sdb-9.8.2-0.17.rc1.el6_4.4.x86_64.rpm fee7dca53a94e5db7ef476569cf5175442a550c317477a7e0d784e7d1efdd209 bind-utils-9.8.2-0.17.rc1.el6_4.4.x86_64.rpm Source: edece99dd18f10e5fa72f7ded608c842ae56da1e17df8f503d07e00f470f073d bind-9.8.2-0.17.rc1.el6_4.4.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org http://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 97, Issue 17 ***********************************************

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss