Re: [CentOS] INIT: Id "snmp" respawning too fast: disabled for 5 minutes
I finally had a eureka moment this morning and figured out the issues. Our Centos 5 servers are all running on Sun x4100 hardware which has a service processor that runs a firmware Debian install. Since the console for the Centos 5 server is effectively the same console as the service processor, what we were really seeing was the service processor init complaining. Once I figured that out it was easy enough to confirm. Thanks for your time. David Halik wrote: > Thanks for the reply. I've tried both "init q" and "init u" without any > luck, the message still appeared five minutes later. Init did post a > message that it was reloaded, so the command worked, yet the process is > still complaining about this "snmp" id. > > Here's my inittab. It's fairly standard and I don't think any custom > changes were made. > > # > # inittab This file describes how the INIT process should set up > # the system in a certain run-level. > # > # Author: Miquel van Smoorenburg, > # Modified for RHS Linux by Marc Ewing and Donnie Barnes > # > > # Default runlevel. The runlevels used by RHS are: > # 0 - halt (Do NOT set initdefault to this) > # 1 - Single user mode > # 2 - Multiuser, without NFS (The same as 3, if you do not have > networking) > # 3 - Full multiuser mode > # 4 - unused > # 5 - X11 > # 6 - reboot (Do NOT set initdefault to this) > # > id:3:initdefault: > > # System initialization. > si::sysinit:/etc/rc.d/rc.sysinit > > l0:0:wait:/etc/rc.d/rc 0 > l1:1:wait:/etc/rc.d/rc 1 > l2:2:wait:/etc/rc.d/rc 2 > l3:3:wait:/etc/rc.d/rc 3 > l4:4:wait:/etc/rc.d/rc 4 > l5:5:wait:/etc/rc.d/rc 5 > l6:6:wait:/etc/rc.d/rc 6 > > # Trap CTRL-ALT-DELETE > ca::ctrlaltdel:/sbin/shutdown -t3 -r now > > # When our UPS tells us power has failed, assume we have a few minutes > # of power left. Schedule a shutdown for 2 minutes from now. > # This does, of course, assume you have powerd installed and your > # UPS connected and working correctly. > pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down" > > # If power was restored before the shutdown kicked in, cancel it. > pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled" > > > # Run gettys in standard runlevels > co:2345:respawn:/sbin/agetty ttyS0 9600 vt100-nav > 1:2345:respawn:/sbin/mingetty tty1 > 2:2345:respawn:/sbin/mingetty tty2 > 3:2345:respawn:/sbin/mingetty tty3 > 4:2345:respawn:/sbin/mingetty tty4 > 5:2345:respawn:/sbin/mingetty tty5 > 6:2345:respawn:/sbin/mingetty tty6 > > # Run xdm in runlevel 5 > x:5:respawn:/etc/X11/prefdm -nodaemon > > > > Filipe Brandenburger wrote: > >> Hi, >> >> On Tue, Feb 10, 2009 at 14:23, David Halik wrote: >> >> >>> INIT: Id "snmp" respawning too fast: disabled for 5 minutes >>> INIT: Id "snmp" respawning too fast: disabled for 5 minutes >>> INIT: Id "snmp" respawning too fast: disabled for 5 minutes >>> >>> >> What does "grep -i snmp /etc/inittab" say? >> >> If there is really nothing, try "init q" to see if init is still using >> old contents of that file. If that does not help, try "init u" as >> well. >> >> If it still does not fix it, please post the full contents of your >> inittab so that we can help you fix the problem. >> >> HTH, >> Filipe >> ___ >> CentOS mailing list >> CentOS@centos.org >> http://lists.centos.org/mailman/listinfo/centos >> >> > > > -- David Halik System Administrator OIT-CSS Rutgers University dha...@jla.rutgers.edu ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] INIT: Id "snmp" respawning too fast: disabled for 5 minutes
Thanks for the reply. I've tried both "init q" and "init u" without any luck, the message still appeared five minutes later. Init did post a message that it was reloaded, so the command worked, yet the process is still complaining about this "snmp" id. Here's my inittab. It's fairly standard and I don't think any custom changes were made. # # inittab This file describes how the INIT process should set up # the system in a certain run-level. # # Author: Miquel van Smoorenburg, # Modified for RHS Linux by Marc Ewing and Donnie Barnes # # Default runlevel. The runlevels used by RHS are: # 0 - halt (Do NOT set initdefault to this) # 1 - Single user mode # 2 - Multiuser, without NFS (The same as 3, if you do not have networking) # 3 - Full multiuser mode # 4 - unused # 5 - X11 # 6 - reboot (Do NOT set initdefault to this) # id:3:initdefault: # System initialization. si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 # Trap CTRL-ALT-DELETE ca::ctrlaltdel:/sbin/shutdown -t3 -r now # When our UPS tells us power has failed, assume we have a few minutes # of power left. Schedule a shutdown for 2 minutes from now. # This does, of course, assume you have powerd installed and your # UPS connected and working correctly. pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down" # If power was restored before the shutdown kicked in, cancel it. pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled" # Run gettys in standard runlevels co:2345:respawn:/sbin/agetty ttyS0 9600 vt100-nav 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 # Run xdm in runlevel 5 x:5:respawn:/etc/X11/prefdm -nodaemon Filipe Brandenburger wrote: > Hi, > > On Tue, Feb 10, 2009 at 14:23, David Halik wrote: > >> INIT: Id "snmp" respawning too fast: disabled for 5 minutes >> INIT: Id "snmp" respawning too fast: disabled for 5 minutes >> INIT: Id "snmp" respawning too fast: disabled for 5 minutes >> > > What does "grep -i snmp /etc/inittab" say? > > If there is really nothing, try "init q" to see if init is still using > old contents of that file. If that does not help, try "init u" as > well. > > If it still does not fix it, please post the full contents of your > inittab so that we can help you fix the problem. > > HTH, > Filipe > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > -- David Halik System Administrator OIT-CSS Rutgers University dha...@jla.rutgers.edu ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] INIT: Id "snmp" respawning too fast: disabled for 5 minutes
Hello all, I recently started seeing these messages on the consoles of three production Centos 5.2 servers. They have been occurring nonstop for the past few days and show up routinely every five minutes. INIT: Id "snmp" respawning too fast: disabled for 5 minutes INIT: Id "snmp" respawning too fast: disabled for 5 minutes INIT: Id "snmp" respawning too fast: disabled for 5 minutes Despite trying to debug this and googling for the last couple of hours, I haven't had any luck as to why the errors are generated or how to fix them. There are a ton of posts on the web related to other Id's, such as various tty ports and "x", but I haven't seen a single thing related to "snmp". The answer usually seems to be that there are misconfigured lines in /etc/inittab, but in my case there is nothing even remotely related to "Id snmp" in inittab. The make matters more confusing, snmp isn't installed or being used on these machines. I doubled checked and the extent of any snmp packages are these two: # rpm -qa | grep -i snmp perl-Net-SNMP-5.2.0-1.2.el5.rf net-snmp-libs-5.3.1-24.el5_2.1 Both only contain a couple of libraries, so I hardly believe they have anything to do with it. According to what I've learned, this error is usually generated when init tries to continually respawn a process that dies immediately... but as to what process it could possible be I have no idea. I even tried to strace init (-p1), but apparently this is a forbidden operation: # strace -p1 attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted That's a shame too, but at least I could see what init is trying to do. Any ideas? I'm just about stumped as to how to proceed at this point. Thanks in advance. -- David Halik System Administrator OIT-CSS Rutgers University dha...@jla.rutgers.edu ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] nss_ldap 5.2 update question
Great, I didn't realize it was going to be so fast. Thanks for the info. Johnny Hughes wrote: David Halik wrote: Hi all, I was just wondering when this update will trickle down into the Centos repo: http://rhn.redhat.com/errata/RHBA-2008-0611.html Obviously, it just came out yesterday, so I'm not expecting it to suddenly appear. ;) Just curious what the turn around time usually is for RHEL bug fixes that get released and when we should expect it. As a side note, does anyone know if there is a way to get a hold of an update like this without having support access to the RHN? I'm guessing I just have to wait for a Centos release. it is released ... you should be able to get it from mirror.centos.org ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- ======== David Halik System Administrator OIT-CSS Rutgers University [EMAIL PROTECTED] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: nss_ldap 5.2 update question
Scott Silva wrote: on 7-29-2008 11:41 AM David Halik spake the following: Hi all, I was just wondering when this update will trickle down into the Centos repo: http://rhn.redhat.com/errata/RHBA-2008-0611.html Obviously, it just came out yesterday, so I'm not expecting it to suddenly appear. ;) Just curious what the turn around time usually is for RHEL bug fixes that get released and when we should expect it. As a side note, does anyone know if there is a way to get a hold of an update like this without having support access to the RHN? I'm guessing I just have to wait for a Centos release. Thanks! -Dave If they have released the src.rpm you can try and rebuild that. I'd love to, but I'm not sure where to find it. The update links RH sent out only give file names. They claim the actual updates are in RHn, but I'm guessing you need a support contract to get an account. Are they public somewhere? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- ==== David Halik System Administrator OIT-CSS Rutgers University [EMAIL PROTECTED] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] nss_ldap 5.2 update question
Hi all, I was just wondering when this update will trickle down into the Centos repo: http://rhn.redhat.com/errata/RHBA-2008-0611.html Obviously, it just came out yesterday, so I'm not expecting it to suddenly appear. ;) Just curious what the turn around time usually is for RHEL bug fixes that get released and when we should expect it. As a side note, does anyone know if there is a way to get a hold of an update like this without having support access to the RHN? I'm guessing I just have to wait for a Centos release. Thanks! -Dave -- ======== David Halik System Administrator OIT-CSS Rutgers University [EMAIL PROTECTED] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] nfsnobody 65534 vs 4294967294
Hi, I just had a couple of questions about nfsnobody. We run a very large NFS infrastructure based off of a NetApp, and we're been discussing whether or not it is necessary to have 64 bit nfsnobody as 4294967294. I understand the reasoning behind this (2^32 - 2 gives you a max UID), but we're having issues since we run multiple architectures. The UID doesn't play nice across Solairs, Centos, 32 vs 64bit, etc. Are there any obvious security risks or problems with using nfsnobody as 65534 (2^16 - 2) on 64bit, or even just assigning it a random value, 300 for example? I can't see any particular reason for having such a high number other than to keep it above any possible real UID space. Also, the NetApp automatically generates quota tables based off of the highest UID, so obviously this is a *major* problem if suddenly we have billions of users as far as the NetApp is concerned. Ultimately, we'd like to just assign it a low value in the range with our other system account, but we are not sure of the potential risks with NFS etc. Any comments would be appreciated. Thanks! -- ==== David Halik System Administrator OIT-CSS Rutgers University [EMAIL PROTECTED] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
