Hi,
I am maintaining /etc/inittab to respawn mgetty. But I am finding
that it somehow quits after 1st call. Wondering why it should behave
like that.

my inittab enty for that is:
1::respawn:/sbin/mgetty -x 9 -D ttyS0

Regards,
zix

I'm curious to know if putting the runlevel(s) will change that for you?

Hi,
my inittab enty for that is:
1::respawn:/sbin/mgetty -x 9 -D ttyS0
^

Try:

1:12345:respawn:/sbin/mgetty -x 9 -D ttyS0

Regards,

Mark.

--
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

Try:

1:12345:respawn:/sbin/mgetty -x 9 -D ttyS0

Regards,

Mark.

--
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

Hi Mark, I am afraid it didnt help . anyways, I have observed more
stuff...If I login to the target, then only mgetty does not respawn.
But, in the middle of dialing, or if we hang up before we log in or if
we enter wrong password and hang up the phone, mgetty is fine. Only
when we do enter successfully, mgetty does not respawn.

here is the output from /var/log/mgetty.ttyS0

01/01 00:56:39 yS0 input finished with '\r', setting ICRNL ONLCR
01/01 00:56:39 yS0 tio_get_rs232_lines: status: RTS CTS DSR DTR DCD
01/01 00:56:39 yS0 login: use login config file /usr/local/etc/
mgetty+sendfax/login.config
01/01 00:56:39 yS0 login: stat('/usr/local/etc/mgetty+sendfax/
login.config') failed: No such file or directory
01/01 00:56:39 yS0 login: fall back to /bin/login
01/01 00:56:39 yS0 calling login: cmd='/bin/login', argv[]='login
root'
01/01 00:56:39 yS0 setenv: 'CALLER_ID=none'
01/01 00:56:39 yS0 setenv: 'CONNECT=33600/ARQ'
01/01 00:56:39 yS0 setenv: 'DEVICE=ttyS0'
01/01 00:56:39 ##### data dev=ttyS0, pid=2817, caller='none',
conn='33600/ARQ', name='', cmd='/bin/login', user='root'


This is when I am logging in. But when I hang up after that, there is
nothing like release and stuff and mgetty waiting...I mean if we hang
up after this, there is no output..in other words the hangup fails to
somehow send the signal back to my target in case of succesful login.

Any idea?

Thanks a lot,
zix

zix <zixenus at (no spam) gmail.com> wrote:

Try:

1:12345:respawn:/sbin/mgetty -x 9 -D ttyS0

Hi Mark, I am afraid it didnt help .

This may be out in left field ... but ... did you re-start init
so it would re-read inittab?

This is when I am logging in. But when I hang up after that, there is
nothing like release and stuff and mgetty waiting...I mean if we hang
up after this, there is no output..in other words the hangup fails to
somehow send the signal back to my target in case of succesful login.

It might be that the mgetty process has not died.

You need to get someone on the console of the local machine to see what
mgetty processes are running before and after you dial in, and again after you
hang up and again after you dial back in again.

I think that you may be having a different problem in that hangup is not
clean. If this is the case, I have some notes in an archive somewhere, which
may resolve this issue, but before I start looking, I need to know that what
you are seeing is the problem that my notes apply to.

Regards,

Mark.

--
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

Hi Mark, thanks for your help. btw, mgetty dies after it receives the
call, which i fell is perfectly normal. I guess, when mgetty spawns
itself as login, which shows the prompt in the far away host machine.
But again somehow it should get intimated when the far away host dies
(the modem should signal).

I think I am missig out in configuration. Can someone highlight any
thing which might be an issue?

I will have a look to see what information I can find. I remember looking at
this many years ago.

Doug Mitton <doug_mitton at (no spam) hotmail.com.invalid> writes:
zix <zixenus at (no spam) gmail.com> wrote:

Try:

1:12345:respawn:/sbin/mgetty -x 9 -D ttyS0

[...]

Hi Mark, I am afraid it didnt help .

[...]

This may be out in left field ... but ... did you re-start init
so it would re-read inittab?

'init' cannot be restarted for the simple reason that the kernel will
panic, should it ever terminate . The 'telinit q' command can be used
to instruct init to re-read /etc/inittab (for sysv init).

Try:

1:12345:respawn:/sbin/mgetty -x 9 -D ttyS0

Regards,

Mark.

--
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

Hi Mark, I am afraid it didnt help . anyways, I have observed more
stuff...If I login to the target, then only mgetty does not respawn.
But, in the middle of dialing, or if we hang up before we log in or if
we enter wrong password and hang up the phone, mgetty is fine. Only
when we do enter successfully, mgetty does not respawn.

here is the output from /var/log/mgetty.ttyS0

01/01 00:56:39 yS0 input finished with '\r', setting ICRNL ONLCR
01/01 00:56:39 yS0 tio_get_rs232_lines: status: RTS CTS DSR DTR DCD
01/01 00:56:39 yS0 login: use login config file /usr/local/etc/
mgetty+sendfax/login.config
01/01 00:56:39 yS0 login: stat('/usr/local/etc/mgetty+sendfax/
login.config') failed: No such file or directory
01/01 00:56:39 yS0 login: fall back to /bin/login
01/01 00:56:39 yS0 calling login: cmd='/bin/login', argv[]='login
root'
01/01 00:56:39 yS0 setenv: 'CALLER_ID=none'
01/01 00:56:39 yS0 setenv: 'CONNECT=33600/ARQ'
01/01 00:56:39 yS0 setenv: 'DEVICE=ttyS0'
01/01 00:56:39 ##### data dev=ttyS0, pid=2817, caller='none',
conn='33600/ARQ', name='', cmd='/bin/login', user='root'


This is when I am logging in. But when I hang up after that, there is
nothing like release and stuff and mgetty waiting...I mean if we hang
up after this, there is no output..in other words the hangup fails to
somehow send the signal back to my target in case of succesful login.

Any idea?

I'm curious to know if putting the runlevel(s) will change that for you?

well, I gave the runlevel.."1:2345:respawn:/sbin/mgetty -x 9 -D
ttyS0". It did not help. There are 2 things I have observed. If I do
this 2 steps, then again mgetty starts working.
Observation:
(1) Initially: mgetty is not running(after the first incoming call).
Now, if I do kill -1 1, it does not work(mgetty stil doesnot run)
(2) Initially: mgetty is not running(after the first incoming call).
Now disable the mgetty line in /etc/inittab. Then run kill -1 1. Then
enable the line of mgetty in /etc/inittab. Then again run the command
"kill -1 1". mgetty runs.

Mark Hobley <markhob... at (no spam) hotpop.donottypethisbit.com> wrote:
I will have a look to see what information I can find. I remember looking at
this many years ago.

Right ... I have found some information:

The /etc/gettydefs file allows a Hangup Control (HUPCTL) entry to be
added. This causes the getty to send a hangup signal to the controlling
program if the carrier detect signal from the modem is lost. This
terminates the shell and any other running processes when the line is
hung up and will return the getty to its initial listening state.

The man page you require is mgettydefs(4).
You may want to google for HUPCTL for more information.

Regards,

Mark.

--
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/