Bug 462141 - serial console
serial console
Product: Fedora
Classification: Fedora
Component: upstart (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Casey Dahlin
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-09-12 19:11 EDT by Dimitri Maziuk
Modified: 2014-06-18 04:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-09-15 15:24:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dimitri Maziuk 2008-09-12 19:11:25 EDT
Description of problem:

no documentation on how to enable serial console in the new init system. My reading of /etc/event.d/serial is that it should work after fedora.serial-console-available event is emitted, but I coudn't find anything whatsoever in manpages and /usr/share/doc on how emit that.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Casey Dahlin 2008-09-12 19:50:38 EDT
You don't.

fedora.serial-console-available is emitted when a serial device is plugged in. There's no manual intervention involved.
Comment 2 Dimitri Maziuk 2008-09-12 21:31:18 EDT
Well then it's broken because I have a bunch of servers whose serial ports are plugged into a lantronix SLC terminal server, and I don't see the console on Fedora 9. All I see is grub boot menu. On all Fedora 8 and earlier machines serial console works just fine.
Comment 3 Dimitri Maziuk 2008-09-12 21:46:24 EDT

initctl emit --no-wait fedora.serial-console-available ttyS0 9600 

starts it up just fine. So I repeat, how do I tell upstart that serial console is plugged in, and has been since before machine was even powered on?

(I can of course put the above line in rc.local and chattr +i it to make sure it doesn't get overwritten, but I'd rather not)
Comment 4 Bill Nottingham 2008-09-15 09:46:36 EDT
See /etc/udev/rules.d/10-console.rules.

I'm assuming running (post-boot) '/lib/udev/console_check console' does not start it?
Comment 5 Dimitri Maziuk 2008-09-15 13:32:15 EDT
I hate computers.

I couldn't figure out what to emit to make serial console unavailable, so I rebooted the machine. Now I get all the bootup messages and login prompt. Go figure.

I have more servers to set up, I'll see if that's consistent or a one-off glitch and post an update (hopefully later today).

BTW, what's "ttySG*" referenced in /etc/udev/rules.d/10-console.rules?
Comment 6 Bill Nottingham 2008-09-15 13:42:02 EDT
Sort-of-serial-but-not-exactly console on SGI Altix boxes.
Comment 7 Dimitri Maziuk 2008-09-15 15:13:15 EDT
(In reply to comment #6)
> Sort-of-serial-but-not-exactly console on SGI Altix boxes.

Ah. Thanks.

OK, I fired up another machine: identical hardware, os may be one yum update off -- the console is there from the start. So I guess we can write it off as weird one-off thing.
Comment 8 Bill Nottingham 2008-09-15 15:24:49 EDT
OK, will do.

The automatic stuff should trigger whenever the old automatic code (from kudzu) did before. If you need to configure additional serial gettys that are always on (such as for ones that aren't actually the 'console' device), you can copy /etc/event.d/tty* as a starting point - it should be fairly obvious from there.
Comment 9 Dimitri Maziuk 2008-10-27 13:37:43 EDT
More failures:

when I telnet to console, about 1 in 6 times there's no login prompt, even though it worked the last time. A look at ps shows agetty isn't running, emitting fedora.serial-console-available fixes it.

It seems every once in a while agetty is not respawned after logoff. Unfortunately, it's not consistently reproducible -- all I can tell you it's happening regularly on different machines.

All of the machines are x86_64 w/ DB9 serial port hooked to Lantronix slc32 console server.

Note You need to log in before you can comment on or make changes to this bug.