mgetty doesnot respawn
zix
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
September Storm
I'm curious to know if putting the runlevel(s) will change that for you?
zix
>
> 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.
output of ps is below:
12117 root 1736 S /sbin/mgetty -x 9 -D ttyS0
Any idea? Thanks a lot for the help
zix
Mark Hobley
> Hi,
> my inittab enty for that is:
> 1::respawn:/sbin/mgetty -x 9 -D ttyS0
|
There are no runlevels listed for this entry.
Try:
1:12345:respawn:/sbin/mgetty -x 9 -D ttyS0
Regards,
Mark.
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
zix
> 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
Doug Mitton
This may be out in left field ... but ... did you re-start init so it
would re-read inittab?
--
-------------------------------------------------
http://www3.sympatico.ca/dmitton
SPAM Reduction: Remove ".invalid" from my domain.
-------------------------------------------------
Rainer Weikusat
> zix <zix...@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).
Mark Hobley
> 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.
I'm not sure what you mean by this. I think you are telling me that you
are using a remote dial in, and can login once, but cannot log in again
after logging out. (Presumably there is a modem involved here).
This might not be an init problem. The mgetty process will only respawn
after it has died.
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.
zix
> 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). Well, as setup I am having 2 machines
(1) One machine where from I dial out (2)the other host machine where
mgetty runs. In case of (2), I have tried with 2 machines on different
occasions(with arm and with i386 machine). With i386 machine, I could
see mgetty respawns(after 1st call and subsequent calls). But with arm
target, its not happenning. I am trying to simulate the same env over
arm as in i386. I have the mgetty, mgetty.config, login.config. I
think I am missig out in configuration. Can someone highlight any
thing which might be an issue?
Thanks,
zix
Mark Hobley
> 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).
Right ... I think the hangup is not being detected.
> I think I am missig out in configuration. Can someone highlight any
> thing which might be an issue?
There are a couple of switches that cause RS232 line status to change as
the client modem hangs up. This enables the server to restart the mgetty.
I will have a look to see what information I can find. I remember looking at
this many years ago.
Mark Hobley
> 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,
André Gillibert
init can re-exec itself, which may be useful if the executable file is replaced with another one (e.g. when exiting from an initrd).
telinit U asks init to call exec(myname, ...), where myname is the argv[0] that had been passed to init.
--
André Gillibert
André Gillibert
Maybe the serial line or terminal config gets broken after you login.
You may play with stty once your logged in.
e.g.
stty crtscts
stty hup (this one will automatically hang up when the last process closes the tty)
setserial may help too...
Maybe something like ^callout_nohup.
--
André Gillibert
Joe Beanfish
>> 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.
Make sure the key (first field) "1" doesn't occur in any other line
of inittab. Look in syslog, typically /var/log/messages, to see if
init is complaining about anything.
After the hangup do you see anything using that tty in ps?
zix
Hobley) wrote:
Hi Mark and Everybody,
thanks a lot for your help. I
think I have got the issue, but needs to test though. I have seen that
when the call gets disconnected, the dcd line does not go low. So I
went deep inside to check. In our hardware, that is connected via gpio
which has been set as output(which is wrong, as this should be input
as modem should update). So, hopefully if I am able to solve that, I
think the issue will get resolved. Will keep updated.
Thanks,
zix