fix vgetty failure before office hours monday?

Hi all, I would really like to replace our current voice mail system (Communicate Pro running on a Windows XP system) with a linux based system.

Obviously, the voicemail system as managed by webmin would be a nice start. There doesn’t seem to be much out there… other than vocp, and it doesn’t seem like that’s been updated since 2003 or so.

I took my best shot at it.

I installed every getty file that appears when you run
yum list |grep getty

then, I refreshed the system modules in webmin.

I set the path to vgetty in webmin voicemail config to /sbin/vgetty

The original big problem at that point was that XEN had taken ttyS0 for itself. I made some changes to grub.conf: I changed the module lines that included a xen entry by adding xencons=tty.

That seemed to work - Xen reported a warning about not being to spawn on tty1 after that, but I really don’t see any negative effects… seeing as how I’m not real clear on what xen is doing for my system, that’s not surprising. The modem was able to get a handle to ttyS0, as well… as reported by ps waux | grep getty
root 5280 0.0 0.0 1912 744 ? Ss 09:14 0:00 /sbin/vgetty ttyS0

In any case, /var/log/vgetty.log.ttyS0 reports that it can’t communicate with my 15 year old zoom 56K fax modem.
05/10 09:15:30 yS0 vgetty: timeout while reading character from voice modem
05/10 09:15:30 yS0 modem detection failed

What I want to do is get vgetty to stop trying to respawn before the office opens in the morning. That seems like an unsafe waste of resources.

Here’s my intention:
a) comment out the respawn command for vgetty in /etc/inittab
and optionally b) remove the xenscons =tty in grub.conf to restore xen to ttyS0 (but I don’t really know if I need to do this)

Ummm… does that seem it will stop vgetty from doing… uh, anything until I can mess with it some more?

(and restore xen?)


It’s been so long since I’ve played with vgetty that I’m going to be utterly hopeless on helping you. But, yes, it sounds like undoing what you did with the inittab and grub.conf, is the way to get back to normal. :wink:

There may also be a service related to vgetty, but I don’t remember. I’d check /etc/init.d for anything related. Might need to also be shut down.

I don’t see anything running as a service, although it’s possible I could have missed it. I feel reasonably confident I cleaned up my mess because

#dmesg | grep tty
Xen virtual console successfully installed as ttyS0

and /var/log/vgetty.log.ttyS0 aint growing since I rebooted the machine…

top shows nothing I don’t expect.