Description of problem: I set up a serial console on ttyS0 and two gettys are being started making the serial console unusable Version-Release number of selected component (if applicable): upstart-0.3.9-19.fc9.x86_64 How reproducible: All the time. Steps to Reproduce: 1. I added the following lines to /etc/grub.conf serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 terminal --timeout=10 serial console kernel /vmlinuz-2.6.26.2-14.fc9.x86_64 ro root=/dev/mapper/Fedora64-Root console=tty0 console=ttyS0,115200n8
Can you post a process tree from single-user mode?
Is this what you are looking for? # pstree -al init |-bash | `-pstree -al |-sh -e -cwhile\040/bin/true\040;\040do\012\011LANG=C\040/sbin/initctl\040stat us\040rcS\040|\040grep\040-wq\040"rcS\040(stop)\040waiting"\040&&\040break\012\0 11sleep\0401\012done\012while\040/bi | `-sleep 1 `-udevd -d
So, there's only one at that point. Once you exit from single user mode, is the second one already there when you get to full boot?
Yes... two getty pop up after the full boot. Now, unless I'm missing something, the process tree is only showing one running.. # pstree -al init |-acpid |-agetty /dev/ttyS0 115200 vt100-nav |-anacron -s |-atd |-auditd | |-audispd | | `-{audispd} | `-{auditd} |-automount | |-{automount} | |-{automount} | |-{automount} | `-{automount} |-avahi-daemon | `-avahi-daemon |-console-kit-dae | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | |-{console-kit-dae} | `-{console-kit-dae} |-crond |-cupsd |-dbus-daemon --system | `-{dbus-daemon} |-dhclient -1 -q -lf /var/lib/dhclient/dhclient-virtbr0.leases -pf/var/run/ |-gam_server |-gpm -m /dev/input/mice -t exps2 |-hald | `-hald-runner | |-hald-addon-acpi | |-hald-addon-cpuf | |-hald-addon-inpu | `-hald-addon-stor |-hcid -s |-iscsid |-iscsid |-libvirtd --daemon | `-dnsmasq --keep-in-foreground --strict-order --bind-interfaces--pid-fi |-login | `-bash |-mingetty tty4 |-mingetty tty5 |-mingetty tty2 |-mingetty tty3 |-mingetty tty1 |-mingetty tty6 |-pcscd | `-{pcscd} |-restorecond |-rpc.idmapd -vvvv |-rpc.statd |-rpcbind |-rsyslogd -c 3 | |-{rsyslogd} | |-{rsyslogd} | `-{rsyslogd} |-sendmail |-sendmail |-setroubleshootd -E /usr/sbin/setroubleshootd | |-{setroubleshootd} | `-{setroubleshootd} |-sshd | `-sshd | `-sshd | `-bash | `-su | `-bash | `-pstree -al |-udevd -d `-yum-updatesd -tt /usr/sbin/yum-updatesd madhat#
OK, I'm confused. If only one is running, how are you seeing two? What's the
When I open the open the serial console I see two also when I run 'initctl status serial' I get two instances... # initctl status serial serial (instance) (start) running, process 17460 (start) running, process 17473 It seems it takes a few seconds or so because after a while the second getty does indeed show up in the pstree: # pstree -al init |-acpid |-agetty /dev/ttyS0 115200 vt100-nav |-agetty /dev/ttyS0 115200 vt100-nav : : :
... random guess ... What's the output of 'grep trigger /etc/init.d/*'?
$ grep trigger /etc/init.d/* /etc/init.d/openibd: # loaded. The udevtrigger in load_hardware_modules will immediately /etc/init.d/openibd: udevtrigger
Does it go away if you turn off openibd?
Yes... 'chkconfig openidb off' and then rebooting does seem to fix the problem. Adding Doug to see if he can shed some light on why two gettys are getting started when openibd is enabled....
You evidently still have the older openibd script from way back when you first started working on IB stuff ;-) That was the openib package that you copied from RHEL if you recall correctly. Since then I've pushed the rdma package through the fedora review process and specifically cleaned up the trigger usage during review. Can you check out the rdma package from fedora cvs and install it on your system (removing openib at the same time obviously)? That should solve this issue (I haven't pushed it to stable yet, or to testing on some versions of fedora, so depending on what version of fedora you are one yum won't be able to find it even with testing enabled).
Ok... so I'll close this as fixed in RAWHIDE... thanks!
Well, I'm glad the bug is closed, but you didn't say if the new openibd init script actually solved your problem...
well I took your word for it... ;-) But since you asked.... I installed rdma-1.0-2.fc9.noarch.rpm (from koji.fedoraproject.org) after removing the openib package. Then I turned rdma on with 'chkconfig rdma on' and then rebooted. Got the "Loading OpenIB kernel modules:[ OK ]" messsage when coming up and only one getty on ttyS0 (the serial console) was started. So in my book... the problem is solved!
Thanks for checking it for me ;-) The init script indeed changed the udevtrigger method to (hopefully) only effect devices with class infiniband or class network that don't already have drivers. Obviously, the old trigger everything method was causing the serial port to get triggered twice, causing the bug. But, since I don't run a serial console, I couldn't easily test it. The confirmation is therefore helpful ;-)