Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied

[Michael Biebl]

Control: reassign -1 zsh 5.2-5

Am 26.09.2016 um 23:11 schrieb Martin Steigerwald:
> Am Montag, 26. September 2016, 13:53:21 CEST schrieb Josh Triplett:
>> On Mon, Sep 26, 2016 at 10:27:40PM +0200, Martin Steigerwald wrote:
>>> Am Montag, 26. September 2016, 13:08:07 CEST schrieb Josh Triplett:
>>>> On Mon, Sep 26, 2016 at 12:10:34PM +0200, Martin Steigerwald wrote:
>>>>> Am Sonntag, 4. September 2016, 14:47:50 CEST schrieb Josh Triplett:
>>>>>> On Sun, 04 Sep 2016 10:59:07 +0200 Martin Steigerwald
>>>>>> <Martin at Lichtvoll.de>
>>>>>
>>>>> wrote:
>>>>>>> Package: systemd
>>>>>>> Version: 231-5
>>>>>>> Severity: minor
>>>>>>>
>>>>>>> Dear Martin, dear Michael, dear Systemd maintainers,
>>>>>>>
>>>>>>> systemctl status for a long time just printed the status directly
>>>>>>> onto
>>>>>>> the
>>>>>>> terminal (Konsole in my case). But since also quite a while it
>>>>>>> uses
>>>>>>> less
>>>>>>> on
>>>>>>> my system, even tough the output is not larger than one page.
>>>>>>>
>>>>>>> Also the color escape sequences are not executed by less, leavinge
>>>>>>> me
>>>>>>> with
>>>>>>> something like:
>>>>>>>
>>>>>>> ^[[0;1;32m●^[[0m atopacct.service - Atop process accounting
>>>>>>> daemon
>>>>>>>
>>>>>>>    Loaded: loaded (/lib/systemd/system/atopacct.service; enabled;
>>>>>>>    vendor
>>>>>>>    preset: enabled) Active: ^[[0;1;32mactive (running)^[[0m since
>>>>>>>    So
>>>>>>>    2016-09-04 10:48:07 CEST; 1s ago>
>>>>>>>    
>>>>>>>      Docs: man:atopacctd(8)
>>>>>>>   
>>>>>>>   Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited,
>>>>>>>   status=0/SUCCESS)
>>>>>>>  
>>>>>>>  Main PID: 5034 (atopacctd)
>>>>>>>  
>>>>>>>     Tasks: 1 (limit: 4915)
>>>>>>>    
>>>>>>>    CGroup: /system.slice/atopacct.service
>>>>>>>    
>>>>>>>            └─5034 /usr/sbin/atopacctd
>>>>>>>
>>>>>>> Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process
>>>>>>> accounting
>>>>>>> daemon... Sep 04 10:48:07 merkaba systemd[1]: atopacct.service:
>>>>>>> PID
>>>>>>> file
>>>>>>> /run/atopacctd.pid not readable (yet?) after start: No such file
>>>>>>> or
>>>>>>> directory Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3
>>>>>>> -
>>>>>>> 2015/06/25 11:07:21 […] Sep 04 10:48:07 merkaba systemd[1]:
>>>>>>> Started
>>>>>>> Atop process accounting daemon. Sep 04 10:48:07 merkaba
>>>>>>> atopacctd[5034]:
>>>>>>> ^[[0;1;39mreactivate process accounting^[[0m
>>>>>>
>>>>>> Works fine here with systemd 231-5: "systemctl status" uses less,
>>>>>> but it
>>>>>> interprets color escape sequences, and exits if the output fits
>>>>>> entirely
>>>>>> on the screen.  Can you provide your environment (output of "env"),
>>>>>> and
>>>>>> in particular the values of $LESS and $PAGER?  And can you check if
>>>>>> this
>>>>>> occurs in another terminal, such as xterm?
>>>>>
>>>>> Thanks for your answer Josh. I missed it first seems it was sortet
>>>>> more
>>>>> downwards due to old date:
>>>>>
>>>>>
>>>>> merkaba:~> systemctl status
>>>>> merkaba:~> echo $LESS
>>>>>
>>>>>  -w
>>>>>
>>>>> merkaba:~> echo $PAGER
>>>>>
>>>>> I do not know who has put that "-w" into LESS variable.
>>>>>
>>>>> But removing it doesn´t help:
>>>>>
>>>>> merkaba:~> unset LESS
>>>>> merkaba:~> systemctl status
>>>>> ^[[0;1;31m●^[[0m merkaba
>>>>>
>>>>>     State: ^[[0;1;31mdegraded^[[0m
>>>>>     
>>>>>      Jobs: 0 queued
>>>>>    
>>>>>    Failed: 2 units
>>>>>    
>>>>>     Since: So 2016-09-25 00:35:01 CEST; 1 day 11h ago
>>>>>    
>>>>>    CGroup: /
>>>>>
>>>>> Same in xterm.
>>>>>
>>>>> merkaba:~> apt-show-versions | egrep "^less|^systemd:" | grep amd64
>>>>> less:amd64/sid 481-2.1 uptodate
>>>>> systemd:amd64/sid 231-7 uptodate
>>>>
>>>> What happens if you explicitly export LESS=R ?  Does that help?
>>>
>>> No.
>>>
>>>> Try running the following in your terminal:
>>>>
>>>> /usr/bin/printf '\e[0;1;31mRED\e[0m'
>>>>
>>>> Does the word "RED" show up in red?
>>>
>>> Yes.
>>>
>>>> Also try this:
>>>>
>>>> /usr/bin/printf '\e[2J'
>>>>
>>>> Does that clear your screen?
>>>
>>> Yes.
>>>
>>> Okay, I think I found something:
>>>
>>> martin at merkaba:~> echo $SHELL
>>> /usr/bin/zsh
>>> martin at merkaba:~> systemctl status
>>>
>>> ^[[0;1;31m●^[[0m merkaba
>>>
>>>     State: ^[[0;1;31mdegraded^[[0m
>>>     
>>>      Jobs: 0 queued
>>>    
>>>    Failed: 2 units
>>>
>>> But:
>>>
>>>
>>> martin at merkaba:~> bash
>>> martin at merkaba:~ -> systemctl status
>>>
>>> ● merkaba
>>>
>>>     State: degraded
>>>     
>>>      Jobs: 0 queued
>>>    
>>>    Failed: 2 units
>>>
>>> The red dot and degraded are in red.
>>>
>>>
>>> So seems some interaction with Z-Shell, that leads to broken escape
>>> sequences.
>>>
>>> I use zsh 5.2-5.
>>
>> Ah, interesting.  Perhaps zsh puts the terminal into an unexpected mode
>> somehow?
>>
>> Can you run zsh with whatever options cause it to ignore all your shell
>> configuration and startup files?  Does that fix the problem?
>>
>> If the *default* configuration of zsh causes this bug, I'd suggest
>> reassigning this bug to zsh.
> 
> Hmmm, no idea how to do that from a quick glance at man page.
> 
> Anyway, I did truncate -s0 .zshrc and still the same result.
> 
> I also checked /etc/zsh as well and I didn´t change anything in there except 
> an
> 
> export TZ="Europe/Berlin"
> 
> in /etc/zsh/zshenv to silence repeated calls of Plasma/KDE software to stat 
> /etc/localtime.
> 
> Thanks,
> 

Since this problem seems to be specific to zsh, I think Josh's
suggestion to reassign it to zsh makes sense.
Its maintainers should be in a better position to debug this further.

Please reassign back if it turns out to be genuine bug in systemd.

Regards

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20161022/29758cf2/attachment-0001.sig>