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
> > > > > <mar...@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@merkaba:~> echo $SHELL
> > /usr/bin/zsh
> > martin@merkaba:~> systemctl status
> > 
> > ^[[0;1;31m●^[[0m merkaba
> > 
> >     State: ^[[0;1;31mdegraded^[[0m
> >     
> >      Jobs: 0 queued
> >    
> >    Failed: 2 units
> > 
> > But:
> > 
> > 
> > martin@merkaba:~> bash
> > martin@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,
-- 
Martin

Reply via email to