It seems to be more kernel or initscripts issue for me.

What exactly do you have in your kernel command line? Which versions of upstart, initscripts and kernel? I've just tried this in virtual machine (libvirtd + kvm):

kernel /vmlinuz-2.6.32-25.el6.x86_64 ro root=/dev/mapper/vg_rhel6beta-lv_root LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=ttyS1 init=/sbint/init --verbose crashkernel=auto

and everything is as expected, boot messages are printed, agetty on /dev/ttyS1 is spawned.

# initctl status serial DEV=ttyS1
serial (ttyS1) start/running, process 1665

1665 ttyS1    Ss+    0:00 /sbin/agetty /dev/ttyS1 9600 vt100-nav

initscripts-9.03.8-2.el6.x86_64
upstart-0.6.5-5.el6.x86_64
kernel-2.6.32-31.el6.x86_64

# cat /proc/cmdline 
ro root=/dev/mapper/vg_megadeth-lv_root rd_LVM_LV=vg_megadeth/lv_root rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=ttyS1,115200n8 console=tty1 crashkernel=129M@0M

# initctl status serial DEV=ttyS1
initctl: Unknown instance: ttyS1

"console=ttyS1,115200n8 console=tty1"

Primary console should given last, see /etc/init/serial.conf:

# How this works:
#
# On boot, a udev helper examines /dev/console. If a serial console is the
# primary console (last console on the commandline in grub),  the event
# 'fedora.serial-console-available <port name> <speed>' is emitted, which
# triggers this script. It waits for the runlevel to finish, ensures
# the proper port is in /etc/securetty, and starts the getty.
#
# If your serial console is not the primary console, or you want a getty
# on serial even if it's not the console, create your own event by copying
# /etc/init/tty.conf, and changing the getty line in that file.

Even if this isn't the primary console, shouldn't a getty be spawned?  I may be wrong, but I'm fairly sure this used to be the case in RHEL 5.

No, the only automatically spawned gettys are for the primary console.

*** Bug 606294 has been marked as a duplicate of this bug. ***

(In reply to comment #5)
> Even if this isn't the primary console, shouldn't a getty be spawned?  I may be
> wrong, but I'm fairly sure this used to be the case in RHEL 5.    

I just confirmed that a getty is spawned for every console specified in the kernel command line in RHEL5. See the following serial console output I just took:

EXT3-fs: mounted filesystem with ordered data mode.
type=1404 audit(1277107121.112:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
type=1403 audit(1277107121.374:3): policy loaded auid=4294967295 ses=4294967295
Bridge firewalling registered

intel-piketon-tpm-01.lab.bos.redhat.com login: 
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
Kernel 2.6.18-194.el5 on an x86_64

intel-piketon-tpm-01.lab.bos.redhat.com login: root
Password: 
Last login: Mon Jun 21 08:00:53 from ovpn01.gateway.prod.ext.phx2.redhat.com
root.bos.redhat.com:~> cat /proc/cmdline 
ro root=/dev/VolGroup00/LogVol00 loglevel=7 crashkernel=128M@16M console=ttyS0,115200n81 console=tty0


I think the whole purpose for specifying multiple consoles on the kernel command line is to have them spawned automatically. Looks like a regression to RHEL5 to me, reopening.

I just tested a RHEL 5 VM, and it does *not* behave as you describe out of the box.

Kernel command line: ro root=/dev/VolGroup00/LogVol00  console=ttyS0,115200n81 console=tty0 => no getty is spawned.


Kernel command line: ro root=/dev/VolGroup00/LogVol00  console=tty0 console=ttyS0,115200n81 => getty is spawned.

Perhaps your lab box had its configuration modified by hand? I'm not sure.
In any case, in my testing the RHEL 6 behavior is consistent with RHEL 5.

Hi Bill thanks for checking again,

I guess the reason Jeff and myself thought about this is that the lab machines are altered for serial console access by default. I looked at a newly provisioned RHEL5 machine and found
co:2345:respawn:/sbin/agetty ttyS0 115200 vt100-nav
in /etc/inittab, which is probably not there in the normal RHEL5 setup.