XFS change in kernel-2.6.32-279.14.1
Since upgrading to kernel-2.6.32-279.14.1 all my systems running XFS have been reporting high load averages even when idle. Has anyone else noticed this? In particular, do you see something similar to this root 1431 0.0 0.0 0 0 ?DNov07 1:48 [xfsaild/sda4] when you run ps aux? Keh-Cheng
SC Linux 6.2 Python 2.6 /usr/lib64/python2.6/smtplib.py host/port confusion.
Hello, I am running Python 2.6.6-29.el6_3.3 on Scientific Linux 6.2. Basically the Python SMTP code opens a socket and passes the host and por t arguments in the wrong order. There is a related Python bug report but it looks like the problem may only be fixed in Python 2.7 and 3.2: http://bugs.python.org/issue13163 line number 273 in /usr/lib64/python2.6/smtplib.py opens a socket with th e following arguments: return socket.create_connection((port, host), timeout) The arguments are in the wrong order and it should be: return socket.create_connection((host, port), timeout) create_connection is defined as def create_connection(address, timeout=_GLOBAL_DEFAULT_TIMEOUT): at line number 540 in /usr/lib64/python2.6/socket.py The second line of code in the functions does the following: host, port = address Which means that host will be assigned the port value and port will be assigned to the host. Will there be a fix for this for SC 6.2? Thanks Mick Timony
Re: SC Linux 6.2 Python 2.6 /usr/lib64/python2.6/smtplib.py host/port confusion.
On Fri, 9 Nov 2012, Mick Timony wrote: Hello, I am running Python 2.6.6-29.el6_3.3 on Scientific Linux 6.2.=20 Basically the Python SMTP code opens a socket and passes the host and por= t arguments in the wrong order. There is a related Python bug report but it= looks like the problem may only be fixed in Python 2.7 and 3.2: http://bugs.python.org/issue13163 line number 273 in /usr/lib64/python2.6/smtplib.py opens a socket with th= e following arguments: return socket.create_connection((port, host), timeout) The arguments are in the wrong order and it should be: return socket.create_connection((host, port), timeout) create_connection is defined as def create_connection(address, timeout=3D_GLOBAL_DEFAULT_TIMEOUT): at line number 540 in=20 /usr/lib64/python2.6/socket.py=20 The second line of code in the functions does the following: host, port =3D address Which means that host will be assigned the port value and port will be assigned to the host. Will there be a fix for this for SC 6.2? We only provide patches via TUV. So TUV will have to put a patch in. Do you have example python code that uses smtplib.py and fails? -Connie Sieh Thanks Mick Timony
bonded interfaces with dhcp
I've been encountering a problem when trying to configure bonded network interfaces using (static) dhcp. These experiences have all been on SL 5.5 through SL 5.8 machines... Baically it seems to work as intended, but after some period of time, up to a day, the machine will lose its default route and never re-acquire it. You can get the route back by either restarting the network service, or just killing off and rerunning the dhclient for the interface. But, to be clear, dhclient IS still present and running, and successfully renewing the lease, it's just the route that disappears... To give an example, to see if my config looks sensible, my ifcfg-eth0 and ifcfg-eth1 files might look something like: DEVICE=eth0 BOOTPROTO=none HWADDR=00:24:81:FC:63:78 ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no NM_CONTROLLED=no and ifcfg-bond0 might look like: DEVICE=bond0 BOOTPROTO=dhcp ONBOOT=yes USERCTL=no PERSISTENT_DHCLIENT=yes BONDING_OPTS=miimon=80 mode=4 xmit_hash_policy=layer3+4 Has anyone else come across this issue? Graham -- - Graham Allan - I.T. Manager - al...@physics.umn.edu - (612) 624-5040 School of Physics and Astronomy - University of Minnesota -
Re: bonded interfaces with dhcp
It sounds like your bonded interface is flaping The persistant dhcp setting will reload the ip if the original lease is still valid but network manager will remove your route if the interface flaps unless you set nm_controled to no. You should check your logs though first to see if your interface is flaping On Nov 9, 2012 6:59 PM, Graham Allan al...@physics.umn.edu wrote: I've been encountering a problem when trying to configure bonded network interfaces using (static) dhcp. These experiences have all been on SL 5.5 through SL 5.8 machines... Baically it seems to work as intended, but after some period of time, up to a day, the machine will lose its default route and never re-acquire it. You can get the route back by either restarting the network service, or just killing off and rerunning the dhclient for the interface. But, to be clear, dhclient IS still present and running, and successfully renewing the lease, it's just the route that disappears... To give an example, to see if my config looks sensible, my ifcfg-eth0 and ifcfg-eth1 files might look something like: DEVICE=eth0 BOOTPROTO=none HWADDR=00:24:81:FC:63:78 ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no NM_CONTROLLED=no and ifcfg-bond0 might look like: DEVICE=bond0 BOOTPROTO=dhcp ONBOOT=yes USERCTL=no PERSISTENT_DHCLIENT=yes BONDING_OPTS=miimon=80 mode=4 xmit_hash_policy=layer3+4 Has anyone else come across this issue? Graham -- - Graham Allan - I.T. Manager - al...@physics.umn.edu - (612) 624-5040 School of Physics and Astronomy - University of Minnesota -
Bug report: label problem in gparted
Hi All, According to: https://www.scientificlinux.org/news/archive/bug.feature.tracker.removed If you have found a bug in Scientific Linux, or have a feature request, please send them to the scientific-linux-users mailling list. So here goes. Would one of our intrepid heroes please fix this for me? Currently in our version of gparted (0.6.0), on fat32 flash drives, the labeling utility converts labels to all upper case. This is reported and solved by the following gparted bug report: https://bugzilla.gnome.org/show_bug.cgi?id=625337 Currently, the only way I have to get lower case letters in labels is to reformat the drive: # mkfs.vfat -n MyCDs /dev/sdc1 I would really like to be able to change my labels without having to reformat. As stated in the above gparted bug report, to solve this will require us to upgrade to GParted 0.11.0. Would one of our heroes please re-spin this for us/me? Many thanks, -T $ rpm -qi gparted Name: gparted Relocations: (not relocatable) Version : 0.6.0 Vendor: Fedora Project Release : 1.el6 Build Date: Thu 01 Jul 2010 05:45:31 AM PDT Install Date: Fri 03 Jun 2011 08:52:34 PM PDT Build Host: x86-06.phx2.fedoraproject.org Group : Applications/System Source RPM: gparted-0.6.0-1.el6.src.rpm Size: 3598093 License: GPLv2+ Signature : RSA/8, Thu 01 Jul 2010 01:57:06 PM PDT, Key ID 3b49df2a0608b895 Packager: Fedora Project URL : http://gparted.sourceforge.net Summary : Gnome Partition Editor
