Re: [PATCH] init: Add handshake to poweroff/reboot for signal handler setup

[Deb McLemore]

>From the original thread, we tried the suggestion, but when the do_execve is 
>done from kernel_init

for Busybox /sbin/init (to start PID=1) all process zombies are flushed (the 
usermode helper that kicks

Busybox /sbin/poweroff started by PID=2, before PID=1 is do_execve'd from 
kernel init).  So when the line is crossed

when PID=1 begins all zombies and pre-work are flushed, so nothing is carried 
over into the life of PID=1

to synchronize with or detect when the signals are properly setup.  The only 
solution which worked was doing the abstract socket handshake which stays 
persistent across the boundary from PID=0 heritage to when PID=1 is properly 
instantiated.

proc_flush_task_mnt from linux/fs/proc/base.c


On 02/13/2018 08:32 PM, Laurent Bercot wrote:
>> Even when process=1 is started, it still leaves a window when the
>> signal handler setup has not been completed.
>
>  Yes, but you can still use kill(pid, 0) to check whether init is
> ready to receive signals: doublefork a zombie and repeatedly kill it
> with signal 0. When you get -1 ESRCH, it means init has reapt the
> zombie, so it's in its reaping loop, and at that point you know it
> has installed its signal handlers.
>
>  See http://lists.busybox.net/pipermail/busybox/2017-October/085888.html
>
>  That's arguably uglier than using abstract sockets, but it can
> be done without modifying the init code at all.
>
> -- 
>  Laurent
>

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] init: Add handshake to poweroff/reboot for signal handler setup

[Laurent Bercot]

Even when process=1 is started, it still leaves a window when the
signal handler setup has not been completed.


 Yes, but you can still use kill(pid, 0) to check whether init is
ready to receive signals: doublefork a zombie and repeatedly kill it
with signal 0. When you get -1 ESRCH, it means init has reapt the
zombie, so it's in its reaping loop, and at that point you know it
has installed its signal handlers.

 See http://lists.busybox.net/pipermail/busybox/2017-October/085888.html

 That's arguably uglier than using abstract sockets, but it can
be done without modifying the init code at all.

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] init: Add handshake to poweroff/reboot for signal handler setup

[Laurent Bercot]

+   fdrc = connect(fdBB2,
+   (struct sockaddr *)_addr2,
+   sizeof(sa_family_t) +
+   BB_SIGNALS_SOCKET_STR_LEN);
+   if (fdrc == 0)
+   break;


 This will not work, because connect() will not succeed if the
server does not listen(). And you cannot listen() in init without
significantly rewriting its execution flow.

 However, you can still use this: connect() on an unbound socket
will return -1 ENOENT, connect() on a bound socket that is not
listening will return -1 ECONNREFUSED. So if you change your
fdrc test to an (errno == ECONNREFUSED) test, it should work.

 See http://lists.busybox.net/pipermail/busybox/2017-October/085893.html
and the whole surrounding thread.

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] init: Add handshake to poweroff/reboot for signal handler setup

[Deb McLemore]

Even when process=1 is started, it still leaves a window when the

signal handler setup has not been completed.


bb_signals is for all signal handling setup.


On 02/13/2018 02:41 PM, Denys Vlasenko wrote:
> On Sat, Nov 25, 2017 at 3:09 AM, Deb McLemore  
> wrote:
>> Add an abstract socket to synchronize the readiness of init to receive
>> the SIGUSR2 to catch poweroff/reboot during an IPL phase (e.g. soft power
>> off via BMC).
>>
>> Signed-off-by: Deb McLemore 
>> ---
>>  include/libbb.h |  5 +
>>  init/halt.c | 33 +
>>  init/init.c | 22 ++
>>  3 files changed, 60 insertions(+)
>>
>> diff --git a/include/libbb.h b/include/libbb.h
>> index daccf15..9f9bfc2 100644
>> --- a/include/libbb.h
>> +++ b/include/libbb.h
>> @@ -174,6 +174,11 @@
>>  # define STRERROR_ERRNO  ,strerror(errno)
>>  #endif
>>
>> +#ifdef __linux
>> +#define BB_SIGNALS_SOCKET_STRING "\0bb_signals"
> Probably should be "\0bb_init_signals".
>
> But I wonder. Can't you probe for existence of process 1
> using kill(1,0) syscall returning 0 or ESRCH?
>

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] init: Add handshake to poweroff/reboot for signal handler setup

[Denys Vlasenko]

On Sat, Nov 25, 2017 at 3:09 AM, Deb McLemore  wrote:
> Add an abstract socket to synchronize the readiness of init to receive
> the SIGUSR2 to catch poweroff/reboot during an IPL phase (e.g. soft power
> off via BMC).
>
> Signed-off-by: Deb McLemore 
> ---
>  include/libbb.h |  5 +
>  init/halt.c | 33 +
>  init/init.c | 22 ++
>  3 files changed, 60 insertions(+)
>
> diff --git a/include/libbb.h b/include/libbb.h
> index daccf15..9f9bfc2 100644
> --- a/include/libbb.h
> +++ b/include/libbb.h
> @@ -174,6 +174,11 @@
>  # define STRERROR_ERRNO  ,strerror(errno)
>  #endif
>
> +#ifdef __linux
> +#define BB_SIGNALS_SOCKET_STRING "\0bb_signals"

Probably should be "\0bb_init_signals".

But I wonder. Can't you probe for existence of process 1
using kill(1,0) syscall returning 0 or ESRCH?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] Prevent arping from freezing when no packet is received

[Denys Vlasenko]

On Mon, Feb 12, 2018 at 3:23 PM, Ortmann, Michael
 wrote:
> I'm not sure. The last sigprocmask call restores the original signal mask of 
> the thread.
> It looks kind of pointless since the two blocked signals are unblocked by the 
> sigprocmask(SIG_UNBLOCK) call in the next loop iteration.
>
> The comment added in the iputils code talks about signal mask inheritance. In 
> my case arping was called via system() from a boost io_service thread for 
> which most signals were blocked. At least the SIG_UNBLOCK before recvfrom 
> makes sense in this case.

Expect many other programs to get confused in such a case.

> Since I don't know the consequences of removing that last sigprocmask() call 
> I would let it stay like in the iputils arping at GitHub.

I deleted it since now it's superfluous.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [BUG] 'case' does not match double-quoted backslash

[Denys Vlasenko]

Fixed in git, thanks.

On Tue, Feb 13, 2018 at 11:42 AM, Martijn Dekker  wrote:
> Op 13-02-18 om 08:12 schreef dietmar.schind...@manroland-web.com:
>> Von: Kang-Che Sung
>> Gesendet: Dienstag, 13. Februar 2018 04:52
>>> It says the backslash is special only when followed by the $ ` " \
>>>  characters.
>>> That is, \$ \` \" \\ and \ are special, but none of these
>>> includes the \z you
>>> mentioned, so what you described is an undefined behavior.
>>
>> "The  shall retain its special meaning ... only when
>> followed ..." means that in other cases it has no special meaning.
>> Having no special meaning does not mean undefined behavior, but
>> rather normal behavior (as an ordinary character).
>
> Precisely. If the standard meant that to be undefined behaviour, it
> would explicitly say so (as it does in many cases of actual undefined
> behaviour). Also, compare the behaviour of *any* other shell. There is a
> clear consensus there.
>
> But, even if the behaviour were undefined, it should not silently change
> from one busybox version to the next. It breaks backwards compatibility.
>
> - M.
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [BUG] 'case' does not match double-quoted backslash

[Martijn Dekker]

Op 13-02-18 om 08:12 schreef dietmar.schind...@manroland-web.com:
> Von: Kang-Che Sung
> Gesendet: Dienstag, 13. Februar 2018 04:52
>> It says the backslash is special only when followed by the $ ` " \
>>  characters.
>> That is, \$ \` \" \\ and \ are special, but none of these
>> includes the \z you
>> mentioned, so what you described is an undefined behavior.
> 
> "The  shall retain its special meaning ... only when
> followed ..." means that in other cases it has no special meaning.
> Having no special meaning does not mean undefined behavior, but
> rather normal behavior (as an ordinary character).

Precisely. If the standard meant that to be undefined behaviour, it
would explicitly say so (as it does in many cases of actual undefined
behaviour). Also, compare the behaviour of *any* other shell. There is a
clear consensus there.

But, even if the behaviour were undefined, it should not silently change
from one busybox version to the next. It breaks backwards compatibility.

- M.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox