Re: bash handles terminate signals incorrectly, when it is run as the init process in a pid namespace
On Thu, Mar 22, 2018 at 6:25 PM, Chet Ramey wrote: > On 3/22/18 3:38 PM, Andrei Vagin wrote: > >> I am thinking how to fix this issue properly. Here are a few points: >> * bash should know that signals are ignored if a process is the init >> process in a pid namespace. > > Why should it know this? It's not documented, not portable, and conflicts > with the way signals are documented to behave. This is a situation-specific > problem. It is "documented" in many places. For exmaple: https://lwn.net/Articles/532748/ """ Signals and the init process The traditional Linux init process is treated specially with respect to signals. The only signals that can be delivered to init are those for which the process has established a signal handler; all other signals are ignored. This prevents the init process—whose presence is essential for the stable operation of the system—from being accidentally killed, even by the superuser. PID namespaces implement some analogous behavior for the namespace-specific init process. Other processes in the namespace (even privileged processes) can send only those signals for which the init process has established a handler. This prevents members of the namespace from inadvertently killing a process that has an essential role in the namespace. Note, however, that (as for the traditional init process) the kernel can still generate signals for the PID namespace init process in all of the usual circumstances (e.g., hardware exceptions, terminal-generated signals such as SIGTTOU, and expiration of a timer). """ I'm agree that this is a situation-specific problem. Unfortunate, this situation is quite popular in our days. > >> * user and kernel signals (SEGV, SIGFPE, SIGBUS, etc) are handled differently > > Fatal signals (signals whose default disposition is to exit the process) > are pretty much handled identically. Let's I try to elaborate what I mean. If we have an init process in a pid namespace, SEGV from the kernel will kill this process, but SEGV from user will be ignored. So if we want to handle a kernel SEGV properly, we have to set a default handler and return back from our handler, the kernel will try to repeat an instruction what triggered SEGV in a previous time, this instruction will trigger SEGV again, and the kernel will kill this process and generate a core file. This trick works for SEGV and FPE, but it will not work for SIGBUS in some cases... > >> * bash should not return back from termsig_sighandler(), if it has >> sent a signal to itself. > > That suggests that the easiest way to solve the problem is to add a call > to exit() after the kill(). You are right with one exception. We expect that the kernel generates a core dump file, if a process was killed by SIGSEGV, SIGBUS, SIGFPE, etc. For these signals, we probably can dereference an invalid pointer instead of calling exit(). > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: bash long prompt, color going past the end of prompt after reaching bottom of terminal
On Fri, Mar 23, 2018 at 12:36:22AM +0200, Ilkka Virta wrote: > I get the same with '4.4.12(1)-release' too, but it doesn't seem related to > Bash or the prompt. I can get it with just a printf, the colored part just > needs to get wrapped by the end of line. > > printf "%100s $(tput setab 1)colored part$(tput sgr0) normal again\n" > > If the screen scrolls, the background color on the last character gets > copied to the next line. Ahh. In that case, it's a bug (or undesired feature) of your terminal emulator, and you should address the bug reports in that direction.
Re: bash long prompt, color going past the end of prompt after reaching bottom of terminal
Virta,
your workaround solves the first issue but creates another one.
Here is the script with your workaround
calculate_prompt1(){
host="my-linux"
git_branch="a very very very very very very very very very very
very very very very long prompt"
prompt="@$host \\w : \[$(tput bold)$(tput setab 1)$(tput setaf
7)\]${git_branch}\[$(tput sgr0)$(tput el)\]\$ "
export PS1="$prompt"}
PROMPT_COMMAND="calculate_prompt1;"
Now keep pressing enter to the bottom of the terminal, and
you will see that the initial problem is solved. next write anything
that flows to the next line (forcing a scroll). Then press "Home"
button to go back to the beginning of what you wrote.
you will see that the entire line after the prompt is deleted.
Any workaround for that?
Thanks,
Musse A.
On Thu, Mar 22, 2018 at 6:36 PM, Ilkka Virta wrote:
> On 22.3. 22:22, Chet Ramey wrote:
>
>> On 3/22/18 1:44 PM, Musse Abdullahi wrote:
>>
>> Bash Version: 4.2
>>> Patch Level: 46
>>> Release Status: release
>>>
>>> Description:
>>> look at Repeat-By section
>>>
>>
>> If the version information above is accurate, you should investigate
>> newer versions of bash. Version 4.2 is two major versions behind and
>> was released around seven years ago.
>>
>
> I get the same with '4.4.12(1)-release' too, but it doesn't seem related
> to Bash or the prompt. I can get it with just a printf, the colored part
> just needs to get wrapped by the end of line.
>
> printf "%100s $(tput setab 1)colored part$(tput sgr0) normal again\n"
>
> If the screen scrolls, the background color on the last character gets
> copied to the next line. At least one way to work around that seems to be
> to clear the end of the line after the colored part ends, by putting
> "$(tput el)" after "$(tput sgr0)". You probably don't have anything to the
> right of the cursor at that point, so it'll only reset the color.
>
> --
> Ilkka Virta / itvi...@iki.fi
>
Re: bash long prompt, color going past the end of prompt after reaching bottom of terminal
> On 2018 Mar 23 , at 8:26 a, Greg Wooledge wrote:
>
> On Fri, Mar 23, 2018 at 12:36:22AM +0200, Ilkka Virta wrote:
>> I get the same with '4.4.12(1)-release' too, but it doesn't seem related to
>> Bash or the prompt. I can get it with just a printf, the colored part just
>> needs to get wrapped by the end of line.
>>
>> printf "%100s $(tput setab 1)colored part$(tput sgr0) normal again\n"
>>
>> If the screen scrolls, the background color on the last character gets
>> copied to the next line.
>
> Ahh. In that case, it's a bug (or undesired feature) of your terminal
> emulator, and you should address the bug reports in that direction.
>
I can reproduce buggy appearance in the following, all running on macOS:
* iTerm2
* Terminal
* The console of a CentOS 7 VM running in Virtual Box
Adapting the original function to work with zsh,
# Changes:
# \w -> %~
# \[...\] -> %{...%}
# \$ -> %#
calculate_prompt1()
{
host="my-linux"
git_branch="a very very very very very very very very very very very very
very very long prompt"
prompt="@$host %~ : %{$(tput bold)$(tput setab 1)$(tput setaf
7)%}${git_branch}%{$(tput sgr0)%}%# "
export PS1="$prompt"
}
I cannot reproduce in any of the three environments listed above.
Clint
