[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-bash] readline does not always handle SIGTERM on reboot
From: |
john smith |
Subject: |
Re: [Help-bash] readline does not always handle SIGTERM on reboot |
Date: |
Fri, 6 Apr 2018 16:25:10 +0200 |
On Fri, Apr 6, 2018 at 3:47 PM, Chet Ramey <address@hidden> wrote:
> On 4/6/18 9:11 AM, john smith wrote:
>> Hello,
>>
>> I'm using bash 4.4.18 with busybox. When reboot is done SIGTERM is
>> sent to all processes by busybox init. The problem is that while
>> SIGTERM is always handled by sigterm_sighandler() in bash at reboot
>> it's not always handled by rl_getc(). I did 10 attempts and SIGTERM
>> has been not handled by rl_getc() in 8 cases. It's problematic
>> because rl_get() returns EOF on SIGTERM and it makes bash perform
>> logout and save history.
>>
>> When I start a new session via telnet and kill a previously started
>> bash session opened on serial console I can see that SIGTERM is
>> handled in rl_getc() every time.
>>
>> What can be the reson rl_getc() does not handle SIGTERM on reboot?
>
> What does `handled' mean?
Sorry for not being clear enough. By not handled I mean that this
part rl_getc() is not run because apparently _rl_caught_signal is 0:
#if defined (SIGHUP)
else if (_rl_caught_signal == SIGHUP || _rl_caught_signal == SIGTERM)
#else
else if (_rl_caught_signal == SIGTERM)
#endif
return (RL_ISSTATE (RL_STATE_READCMD) ? READERR : EOF);
> If readline's signal handlers are installed,
> the SIGTERM signal handler sets a flag. If the SIGTERM doesn't interrupt
> read, nothing else happens until the read returns. If it does interrupt the
> read, and readline is reading a command, it returns EOF. If it's not (for
> instance, if it's reading an incremental search string), it returns an
> error to allow the command to deal with it. The public interface that the
> rest of readline uses (rl_read_key) checks for signal receipt and calls
> the signal handler immediately after rl_getc returns.
>
> There's no difference in how readline and bash handle signals between
> receiving them from init and from another process.
That's my understanding as well, doing reboot should do the same to
bash as kill <BASH_INSTANCE_PID> from another session.
--
<address@hidden>
- [Help-bash] readline does not always handle SIGTERM on reboot, john smith, 2018/04/06
- Re: [Help-bash] readline does not always handle SIGTERM on reboot, Chet Ramey, 2018/04/06
- Re: [Help-bash] readline does not always handle SIGTERM on reboot,
john smith <=
- Re: [Help-bash] readline does not always handle SIGTERM on reboot, Chet Ramey, 2018/04/06
- Re: [Help-bash] readline does not always handle SIGTERM on reboot, john smith, 2018/04/06
- Message not available
- Message not available
- Re: [Help-bash] readline does not always handle SIGTERM on reboot, john smith, 2018/04/06
- Re: [Help-bash] readline does not always handle SIGTERM on reboot, john smith, 2018/04/07
- Re: [Help-bash] readline does not always handle SIGTERM on reboot, Chet Ramey, 2018/04/09
- Re: [Help-bash] readline does not always handle SIGTERM on reboot, Chet Ramey, 2018/04/09
- Re: [Help-bash] readline does not always handle SIGTERM on reboot, john smith, 2018/04/09
- Re: [Help-bash] readline does not always handle SIGTERM on reboot, Chet Ramey, 2018/04/09
- Re: [Help-bash] readline does not always handle SIGTERM on reboot, john smith, 2018/04/09
- Re: [Help-bash] readline does not always handle SIGTERM on reboot, Chet Ramey, 2018/04/09