Discuss October 2015

discuss@lists.centos.org

140 participants
112 discussions

Debugging Kernel Problems
by Tod 19 Oct '15

19 Oct '15

Not sure if this is the correct subject line but my recently installed Centos build (Linux localhost.localdomain 3.10.0-229.14.1.el7.x86_64 #1 SMP Tue Sep 15 15:05:51 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux) periodically just freezes - completely locks up, no activity, nothing in the logs, just stops dead requiring a power off and reboot. I've really looked around to try and find the _best_ way to set up debugging but there is a lot written about it from a lot of parties but I'm not sure who the definitive source is. I did try booting with the 'CentOS Linux (3.10.0-229.14.1.el7.x86_64) 7 (Core) with debugging' option but that really didn't add anything to finding a solution. Dmesg did report this however: dmesg|grep debug [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.10.0-229.14.1.el7.x86_64 root=UUID=1928d2da-784c-4b18-868c-f9858bceea6d ro crashkernel=auto rhgb quiet LANG=en_US.UTF-8 systemd.debug [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0-229.14.1.el7.x86_64 root=UUID=1928d2da-784c-4b18-868c-f9858bceea6d ro crashkernel=auto rhgb quiet LANG=en_US.UTF-8 systemd.debug [ 0.940176] ehci-pci 0000:00:12.2: debug port 1 [ 0.946472] ehci-pci 0000:00:13.2: debug port 1 [ 1.238335] systemd[1]: Unknown kernel switch systemd.debug. Ignoring. [ 5.083981] SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts [ 5.206423] systemd[1]: Unknown kernel switch systemd.debug. Ignoring. Which I found interesting. So, can anyone point me to a detailed guide to debugging what's going on with my build that will help me solve my locking problem? BTW, I think it might be my wireless Atheros equipped PCI card (dmesg|grep -i atheros [ 2.231264] ath5k: phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45) but can't be sure because I've not any real proof that's the issue. Thanks in advance for your patience and assistance.

4 4

Re: [CentOS] [OT] fail2ban update (epel) breaks logrotate
by tony＠softins.co.uk 18 Oct '15

18 Oct '15

In article <n009u2$85v$1(a)softins.softins.co.uk>, Tony Mountifield <tony(a)softins.co.uk> wrote: > Apologies, this is slightly off-topic being to do with an EPEL package, > although it's running on CentOS6, so I thought others here might have come > across this issue. > > I have five CentOS 6 systems running fail2ban from EPEL, and this > package was updated in the last week from 0.9.2-1.el6 to 0.9.3-1.el6. > > On all these systems, I received an error from logrotate this morning. > > [root@system ~]# /usr/bin/fail2ban-client flushlogs > logs: rolled over > Traceback (most recent call last): > File "/usr/bin/fail2ban-client", line 470, in <module> > if client.start(sys.argv): > File "/usr/bin/fail2ban-client", line 440, in start > return self.__processCommand(args) > File "/usr/bin/fail2ban-client", line 281, in __processCommand > return self.__processCmd([cmd]) > File "/usr/bin/fail2ban-client", line 185, in __processCmd > client.close() > File "/usr/lib/python2.6/site-packages/fail2ban/client/csocket.py", line 55, in close > self.__csock.sendall(CSPROTO.CLOSE + CSPROTO.END) > File "<string>", line 1, in sendall > socket.error: [Errno 32] Broken pipe > [root@system ~]# OK, on further investigation, I found that the fail2ban service had not been restarted by the update script. So I restarted it, and got the same error as it was stopping, but it started up ok. After restarting, the error no longer occurs: [root@system ~]# ps -fC fail2ban-server root 7528 1 0 Sep23 ? 00:10:06 /usr/bin/python -Es /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b [root@system ~]# service fail2ban restart Stopping fail2ban: Traceback (most recent call last): File "/usr/bin/fail2ban-client", line 470, in <module> if client.start(sys.argv): File "/usr/bin/fail2ban-client", line 440, in start return self.__processCommand(args) File "/usr/bin/fail2ban-client", line 281, in __processCommand return self.__processCmd([cmd]) File "/usr/bin/fail2ban-client", line 185, in __processCmd client.close() File "/usr/lib/python2.6/site-packages/fail2ban/client/csocket.py", line 55, in close self.__csock.sendall(CSPROTO.CLOSE + CSPROTO.END) File "<string>", line 1, in sendall socket.error: [Errno 32] Broken pipe [FAILED] Starting fail2ban: [ OK ] [root@system ~]# ps -fC fail2ban-server root 11647 1 1 15:30 ? 00:00:00 /usr/bin/python -Es /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b [root@system ~]# /usr/bin/fail2ban-client flushlogs logs: rolled over [root@system ~]# Hope this info is useful to others... Cheers Tony -- Tony Mountifield Work: tony(a)softins.co.uk - http://www.softins.co.uk Play: tony(a)mountifield.org - http://tony.mountifield.org

1 0

[OT] fail2ban update (epel) breaks logrotate
by tony＠softins.co.uk 18 Oct '15

18 Oct '15

Apologies, this is slightly off-topic being to do with an EPEL package, although it's running on CentOS6, so I thought others here might have come across this issue. I have five CentOS 6 systems running fail2ban from EPEL, and this package was updated in the last week from 0.9.2-1.el6 to 0.9.3-1.el6. On all these systems, I received an error from logrotate this morning. It appears that something has broken the flushlogs option in fail2ban-client: [root@system ~]# cat /etc/logrotate.d/fail2ban # # Gentoo: # http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-analyzer/fail2b… # # Debian: # https://github.com/fail2ban/fail2ban/blob/debian/debian/fail2ban.logrotate # # Fedora view: # http://pkgs.fedoraproject.org/cgit/fail2ban.git/tree/fail2ban-logrotate /var/log/fail2ban.log { rotate 7 missingok compress postrotate /usr/bin/fail2ban-client flushlogs 1>/dev/null || true endscript } [root@system ~]# /usr/bin/fail2ban-client flushlogs logs: rolled over Traceback (most recent call last): File "/usr/bin/fail2ban-client", line 470, in <module> if client.start(sys.argv): File "/usr/bin/fail2ban-client", line 440, in start return self.__processCommand(args) File "/usr/bin/fail2ban-client", line 281, in __processCommand return self.__processCmd([cmd]) File "/usr/bin/fail2ban-client", line 185, in __processCmd client.close() File "/usr/lib/python2.6/site-packages/fail2ban/client/csocket.py", line 55, in close self.__csock.sendall(CSPROTO.CLOSE + CSPROTO.END) File "<string>", line 1, in sendall socket.error: [Errno 32] Broken pipe [root@system ~]# Has anyone else found this today? And even better know how to fix it? There doesn't seem to be any current activity in epel-users, and I found the update announcement in epel-package-announce, but didn't see anything about this in the "IMPORTANT incompatible changes" section. Cheers Tony -- Tony Mountifield Work: tony(a)softins.co.uk - http://www.softins.co.uk Play: tony(a)mountifield.org - http://tony.mountifield.org

1 0

CentOS-announce Digest, Vol 128, Issue 4
by centos-announce-request＠centos.org 17 Oct '15

17 Oct '15

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. Update for centos-release-openstack (Karanbir Singh) ---------------------------------------------------------------------- Message: 1 Date: Fri, 16 Oct 2015 19:14:42 +0100 From: Karanbir Singh <kbsingh(a)centos.org> To: CentOS Announcements List <centos-announce(a)centos.org> Subject: [CentOS-announce] Update for centos-release-openstack Message-ID: <56213E92.2050104(a)centos.org> Content-Type: text/plain; charset=utf-8 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The CentOS Cloud SIG ( https://wiki.centos.org/SpecialInterestGroup/Cloud ) is releasing a new OpenStack metadata package called centos-release-openstack-kilo that replaces centos-release-openstack. Metadata packages in CentOS are used to setup the repositories used by the package manager ( yum ) and the signing keys used to validate content installed from the corresponding repositories. The present metadata package, called centos-release-openstack, does not allow for us to have multiple OpenStack versions available to users, without adding many layers of complexity to the install and update process. This new OpenStack metadata package ( centos-release-openstack-kilo ) effectively sets up the mechanics required for us to deliver OpenStack Liberty as an alternative to users who might prefer the newer codebase, once it's available. However, we would like to still support the users who have a Kilo install at the moment, and would like to run that as long as updates are available for Kilo itself. Kilo to Liberty update process will require administrative actions, for details see "Upgrade Notes" in upstream release notes https://wiki.openstack.org/wiki/ReleaseNotes/Liberty The metadata rpm for OpenStack Liberty will be called centos-release-openstack-liberty and users will be able to install it once released. For more information on our progress with that effort, please join the Cloud SIG meetings that are held weekly on #centos-devel on irc.freenode.net or join us on the centos-devel mailing list ( https://lists.centos.org/ ). The updated metadata package, centos-release-openstack-kilo, is now available on all CentOS mirrors, and can be installed by running either 'yum update centos-release-openstack' or 'yum install centos-release-openstack-kilo' - -- 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) iQEcBAEBAgAGBQJWIT6SAAoJEI3Oi2Mx7xbt5OUH/AoA9RW3H2w2YxzRFDkZJOS9 GFuxBSxX7C1hQ+u/5XQlEYx/hj4oaJSeWEBd5bOCyCxVJRSFakUy2LjenErbaX5n QiUdYtaDh2MP72doiGTbOyMpRbJT9jnbuSrSzd4t9oEVGOWyP+gLlaU0QhL4ST3t 01m1Z6vxd0VYmXWpGYH1gK65GEymYNb5vE/MwLFq+Apm2DXELKoPgtwRkwyiT19d aV+xT4f2qLrtI5YMVKspjNxKYOX72yExzrbcaUersTbTmsJB9zCrbi3sqAy/BOv9 jnCpG677EHre6R23ipQ36rUSi401FC8dnN89kO3+joUBtqsPYZw6P8p9brKKC68= =T+80 -----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 128, Issue 4 ***********************************************

1 0

Incoming rsync connection attempts
by Jeff Boyce 16 Oct '15

16 Oct '15

Greetings - In my logwatch report this morning I noticed reference to an attempt to connect to rsync from an external IP address. It doesn't appear that the connection was successful based on correlating information between /var/log/secure and /var/log/messages. But I am looking for some suggestions for implementing more preventative measures, if necessary. The log information from the last few attempts are shown below. /var/log/secure Oct 13 00:14:08 Bison xinetd[2232]: START: rsync pid=15306 from=180.97.106.36 Oct 13 01:55:51 Bison xinetd[2232]: START: rsync pid=15343 from=85.25.43.94 Oct 13 23:25:35 Bison xinetd[2232]: START: rsync pid=16548 from=114.119.37.86 /var/log/messages Oct 13 00:14:08 Bison rsyncd[15306]: rsync: unable to open configuration file "/etc/rsyncd.conf": No such file or directory (2) Oct 13 00:14:08 Bison rsyncd[15306]: rsync error: syntax or usage error (code 1) at clientserver.c(923) [receiver=3.0.5] Oct 13 01:55:51 Bison rsyncd[15343]: rsync: unable to open configuration file "/etc/rsyncd.conf": No such file or directory (2) Oct 13 01:55:51 Bison rsyncd[15343]: rsync error: syntax or usage error (code 1) at clientserver.c(923) [receiver=3.0.5] Oct 13 23:25:35 Bison rsyncd[16548]: rsync: unable to open configuration file "/etc/rsyncd.conf": No such file or directory (2) Oct 13 23:25:35 Bison rsyncd[16548]: rsync error: syntax or usage error (code 1) at clientserver.c(923) [receiver=3.0.5] There is no /etc/rsyncd.conf file present on the system, so I can see why the connection wasn't successful. Our backups get pushed to this one from other servers using rsync. This is on a RHEL 3.9 box (Dell PE2600, year 2004) that is primarily used as backup storage within our LAN. I will retire it when it dies, until then it runs fairly maintenance free. I do have a public IP address assigned to the WAN because we have a vsftp server running on it for transferring files back and forth to a few clients, and I occasionally access the server remotely. I am wondering if there is anything relatively simple that I can do to address these attempted connections, until I have time to move our vsftp server from it and remove the public IP address from the WAN? Thanks. Jeff -- Jeff Boyce Meridian Environmental

5 4

Semi-OT: torque, pbs_mom, cpuset, loglevel
by m.roth＠5-cent.us 16 Oct '15

16 Oct '15

We're running the current version of torque. On our small supercomputer (an SGI), no updates to torque since July, but just recently - someone may be trying something new - /var/log/messages is on-and-off being spammed with Oct 15 18:02:04 servername pbs_mom: LOG_INFO::create_job_cpuset, creating cpuset for job 1971[656].york.cit.nih.gov: 1 cpus (12), 1 mems (1) and I mean thousands of lines. I tried to adjust the loglevel of pbs_mom, but it appeared to make *no* change, and their "documentation" and "manpage" simply does not describe what message level each value of loglevel produces. Anyone have a clue? I've been googling, and not finding anything of use. mark

1 0

LSI driver and SSD status error in IPMI
by Birta Levente 15 Oct '15

15 Oct '15

Hi to all I have a supermicro server with LSI 3108 with - 2x300GB SAS spin drive in raid1 (virtual drive 0) - 2x300GB SAS spin drive in raid1 (virtual drive 1) - 2x200GB Intel SSD DC S3710 drives configured as JBOD in LSI bios In the IPMI storage health status eveything looks fine until I boot into Centos 7.1 (unfortunatelly I didn't try other OS, but also I'm not interested in other) After boot the status for the SSDs changing in ERROR The same thing happen when boot with the install CD Otherwise everything works fine. Is this hurt? Can I do something? Also I tried to install the latest LSI driver (06.809.18.00), but seems it is not loaded after restart: As the official driver install guide say, before the driver install, I installed the dkms from the epel repo. /var/log/messages: systemd-modules-load: Failed to find module 'override megaraid_sas 3.10.* weak-updates/megaraid_sas' /etc/modules-load.d/megaraid_sas.conf: override megaraid_sas 3.10.* weak-updates/megaraid_sas #modinfo megaraid_sas filename: /lib/modules/3.10.0-229.14.1.el7.x86_64/kernel/drivers/scsi/megaraid/megaraid_sas.ko description: LSI MegaRAID SAS Driver author: megaraidlinux(a)lsi.com version: 06.805.06.01-rh2 license: GPL rhelversion: 7.1 srcversion: C0124BBE9453A621D4086DB alias: pci:v00001000d0000005Fsv*sd*bc*sc*i* alias: pci:v00001000d0000005Dsv*sd*bc*sc*i* alias: pci:v00001000d0000002Fsv*sd*bc*sc*i* alias: pci:v00001000d0000005Bsv*sd*bc*sc*i* alias: pci:v00001028d00000015sv*sd*bc*sc*i* alias: pci:v00001000d00000413sv*sd*bc*sc*i* alias: pci:v00001000d00000071sv*sd*bc*sc*i* alias: pci:v00001000d00000073sv*sd*bc*sc*i* alias: pci:v00001000d00000079sv*sd*bc*sc*i* alias: pci:v00001000d00000078sv*sd*bc*sc*i* alias: pci:v00001000d0000007Csv*sd*bc*sc*i* alias: pci:v00001000d00000060sv*sd*bc*sc*i* alias: pci:v00001000d00000411sv*sd*bc*sc*i* depends: intree: Y vermagic: 3.10.0-229.14.1.el7.x86_64 SMP mod_unload modversions signer: CentOS Linux kernel signing key sig_key: E9:9F:C4:37:BD:9C:BF:B4:F1:B1:DA:87:C1:57:FF:66:56:9B:EE:66 sig_hashalgo: sha256 parm: lb_pending_cmds:Change raid-1 load balancing outstanding threshold. Valid Values are 1-128. Default: 4 (int) parm: max_sectors:Maximum number of sectors per IO command (int) parm: msix_disable:Disable MSI-X interrupt handling. Default: 0 (int) parm: msix_vectors:MSI-X max vector count. Default: Set by FW (int) parm: allow_vf_ioctls:Allow ioctls in SR-IOV VF mode. Default: 0 (int) parm: throttlequeuedepth:Adapter queue depth when throttled due to I/O timeout. Default: 16 (int) parm: resetwaittime:Wait time in seconds after I/O timeout before resetting adapter. Default: 180 (int) parm: smp_affinity_enable:SMP affinity feature enable/disbale Default: enable(1) (int) Can somebody tell me how to get the driver to work? Thanks, -- Levi

1 0

Re: [CentOS] Firefox Flash Update = No Flash
by pro alias 15 Oct '15

15 Oct '15

On Tue, Oct 13, 2015 at 2:48 PM, pro alias <proalia(a)gmail.com> wrote: > None of my Centos 5 boxen can show flash since the update this morning. > Am I alone or do other people have this issue ?? > Centos 7 boxes work properly. I haven't looked at RHEL 6 boxes yet. > > Although I miss using flash on these boxes, it IS a great security > upgrade.... > > Installing the previous version of flash-plugin restores the functionality. It appears to be a Glib2 problem, this version was apparently compiled against another glib2. It wants libgio-2.0.so. Copying the so from /usr/lib/vmware to /usr/lib64/ stopped it's complaining but flash still didn't work. Another good reason to upgrade the remaining Centos 5.11 boxes to rhel/centos 7.1.

1 0

cant reattach to screen session since upgrade of screen rpm?
by Jason Welsh 15 Oct '15

15 Oct '15

hey folks, running CentOS release 6.6 (Final) and I was upgrading some rpms and now since screen (and probably some others) were upgraded, I can no longer reattach to my screen session I had running. monsterjam:~ $ rpm -qi screen Name : screen Relocations: (not relocatable) Version : 4.0.3 Vendor: CentOS Release : 18.el6 Build Date: Thu 23 Jul 2015 01:41:46 PM EDT Install Date: Thu 15 Oct 2015 01:15:28 PM EDT Build Host: c6b8.bsys.dev.centos.org Group : Applications/System Source RPM: screen-4.0.3-18.el6.src.rpm monsterjam:~ $ screen -ls There is a screen on: 13262.stuff (Detached) 1 Socket in /var/run/screen/S-jason. when I try to reattach, it just hangs.. monsterjam:~ $ screen -dr 13262.stuff ive found the following and tried them all.. Try detaching it first with screen -d. If that doesn't work, you can try, in increasing order of emphasis, -d|-D [pid.tty.host] does not start screen, but detaches the elsewhere running screen session. It has the same effect as typing "C-a d" from screen's controlling terminal. -D is the equivalent to the power detach key. If no session can be detached, this option is ignored. In combination with the -r/-R option more powerful effects can be achieved: -d -r Reattach a session and if necessary detach it first. -d -R Reattach a session and if necessary detach or even create it first. -d -RR Reattach a session and if necessary detach or create it. Use the first session if more than one session is available. -D -r Reattach a session. If necessary detach and logout remotely first. -D -R Attach here and now. In detail this means: If a session is running, then reattach. If necessary detach and logout remotely first. If it was not running create it and notify the user. This is the author's favorite. -D -RR Attach here and now. Whatever that means, just do it. but none of them seem to work.. any ideas? Jason

3 3

selinux commands fail on low memory box
by Tim Dunphy 15 Oct '15

15 Oct '15

Hey all, I have 3 web servers hosted at Digital Ocean that all have the same amount of memory at 512MB. They're all running CentOS 7. They are low powered apache servers and don't really need more than that. All they're doing is serving the web, no database on those hosts at all. On the first two hosts I seem to have no trouble running SELinux related commands. It's only on the 3rd web server where I seem to have any trouble at all running the SELinux commands I want to keep the box secure. On box #3 all SElinux commands end up the same way. For example: [root@ops3:~] #semodule -i newrelic.pp Killed And that happened when I had about 280MB free: [root@ops3:~] #free -m total used free shared buff/cache available Mem: 490 96 286 28 107 285 Swap: 0 0 0 Typically what I'll do is stop all the main services on this machine to free up some memory to run the command I want. But to no avail! The commands die with the same errors every time. Whereas on the other two hosts I can run the same commands with only as little as 30 or 40MB free! So would this be some inherent flaw with this box? That the only way to get around it is to scrap it and build a replacement? Not that hard to do. But before I took that measure I was wondering if there was any hocus-pocus I could try that I might not be aware of that could alleviate this scenario. Thanks, Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B

3 3

← Newer
1
...
4
5
6
7
8
9
10
11
12
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss October 2015