On Thu, Aug 28, 2014 at 4:38 PM, Harald Becker ra...@gmx.de wrote:
Denys !
My argument is that before adding code, it makes sense to ponder
whether we really have a real problem here.
Do you really insist on this endless respawning NOT BEING A BUG???
I'm saying it is not clear-cut.
If
Hi Denys !
Problem means it may make diagnosing other problems a hell.
Why is it hell? strace -p1 works.
If you have a working strace ...
... or in other words: Do you have a working Busybox applet for this?
You are right, I do not use init. Respawn on error is not the only,
or the
Just for the record, I am now working around this as follows:
console::respawn:/sbin/ifconsole /sbin/getty -L 115200 ttyS0 vt100
/sbin/ifconsole is a shell script that checks if /dev/console can be
opened; if so, the line is executed; otherwise it just sleeps forever
(to prevent the respawning).
Hi !
console::respawn:/sbin/getty -L 115200 ttyS0 vt100
This is a special Busybox feature. BB uses the id field to specify a tty
device, used to start the inittab command. If the device open fails, the
inittab line is skipped.
From examples/inittab:
# id: WARNING: This field has a
Hello Harald,
Thank you for your lightning fast answer :)
2014-08-28 9:58 GMT+02:00 Harald Becker ra...@gmx.de:
console::respawn:/sbin/getty -L 115200 ttyS0 vt100
This is a special Busybox feature. BB uses the id field to specify a tty
device, used to start the inittab command.
Yes I knew
But I didn't know this. So it seems that if I use console as the id,
the device open succeeds when the system boots with console=ttyS0 but
fails when booting with console=null (not sure why -- shouldn't it be
possible to open /dev/null ?).
Have not looked into code, but I ought it depends on
2014-08-28 10:17 GMT+02:00 Harald Becker ra...@gmx.de:
But I didn't know this. So it seems that if I use console as the id,
the device open succeeds when the system boots with console=ttyS0 but
fails when booting with console=null (not sure why -- shouldn't it be
possible to open /dev/null
On Thu, Aug 28, 2014 at 10:08 AM, Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com wrote:
2014-08-28 9:58 GMT+02:00 Harald Becker ra...@gmx.de:
console::respawn:/sbin/getty -L 115200 ttyS0 vt100
This is a special Busybox feature. BB uses the id field to specify a tty
device, used to
Hi Denys,
2014-08-28 11:05 GMT+02:00 Denys Vlasenko vda.li...@googlemail.com:
On Thu, Aug 28, 2014 at 10:08 AM, Guillermo Rodriguez Garcia
But I didn't know this. So it seems that if I use console as the id,
the device open succeeds when the system boots with console=ttyS0 but
fails when
Hi Denys !
If that open fails, then respawning will not be done.
Actually I'm testing this and it seems that init keeps spawning child
processes forever, every second. Inside run(), vfork succeds but then
the device open fails and the child process _exits().
Is there a way to have init
Hi Denys!
If that open fails, then respawning will not be done.
Actually I'm testing this and it seems that init keeps spawning child
processes forever, every second. Inside run(), vfork succeds but then
the device open fails and the child process _exits().
Is there a way to have init
On Thu, Aug 28, 2014 at 2:45 PM, Harald Becker ra...@gmx.de wrote:
If that open fails, then respawning will not be done.
Actually I'm testing this and it seems that init keeps spawning child
processes forever, every second. Inside run(), vfork succeds but then
the device open fails and the
Denys !
I don't like special-casing exit code values.
The proper fix is to open the file in the parent, before fork.
Then the failure can be detected in the parent.
This patch not only disables entries due to open failure of the console,
it also disables endless respawning of processes
On Thu, Aug 28, 2014 at 3:14 PM, Harald Becker ra...@gmx.de wrote:
I don't like special-casing exit code values.
The proper fix is to open the file in the parent, before fork.
Then the failure can be detected in the parent.
This patch not only disables entries due to open failure of the
Denys !
What if /dev/FOO does not exist YET? (E.g. USB-based serial TTY).
What if execve fails because /usr/bin/BAR does not exist YET?
Both cases can be solved when startup code send a SIGHUP to init when
all this stuff is available (at end of rc scripts do kill -SIGHUP 1)
Not to talk
2014-08-28 15:48 GMT+02:00 Harald Becker ra...@gmx.de:
What if /dev/FOO does not exist YET? (E.g. USB-based serial TTY).
What if execve fails because /usr/bin/BAR does not exist YET?
Both cases can be solved when startup code send a SIGHUP to init when all
this stuff is available (at end of
On Thu, Aug 28, 2014 at 3:48 PM, Harald Becker ra...@gmx.de wrote:
What if /dev/FOO does not exist YET? (E.g. USB-based serial TTY).
What if execve fails because /usr/bin/BAR does not exist YET?
Both cases can be solved when startup code send a SIGHUP to init when all
this stuff is available
Denys !
My argument is that before adding code, it makes sense to ponder
whether we really have a real problem here.
Do you really insist on this endless respawning NOT BEING A BUG???
I don't understand your stand point.
If one respawn per second a big problem? I'm not sure.
Problem
2014-08-28 16:38 GMT+02:00 Harald Becker ra...@gmx.de:
My argument is that before adding code, it makes sense to ponder
whether we really have a real problem here.
Do you really insist on this endless respawning NOT BEING A BUG???
I don't understand your stand point.
If one respawn per
19 matches
Mail list logo
