Weird/annoying issue when running “service xyz status”

[giuliomagnifico]

Hi
That’s an annoying bug that appeared since some releases (but I don’t know when exactly), I’ll try to explain how to reproduce it:

Run a
$ service xyz status (insert the name of a random service that you enabled after the installation)

Then it will list the status, but, at the end/bottom of the console window, instead of the shell prompt since sometimes started to appear

END

Not an issue, it’s like in nano or other apps that you have to press ctrl - C to exit.

And it works, you will return to the prompt, but then, if you try to press the arrow up or write anything, the prompt will disappear and the text will create a mess, you will have to press “enter” or “ctrl - C” again to see the shell prompt again!

I don’t know why this started to happen but is annoying because I have to press “ctrl - c” to exit the “service status view”, than “ctrl c” again 2 times!

Thanks

[Joulinar]

I’m not able to replicate this. Following 2 commands are working without issue

systemctl status xyz
service xyz status

Not sure of someone else has a similar behavior. At least you are the first one reporting it.

[giuliomagnifico]

Hmm curious , I made a video/gif from the iPhone, it’s better than from a computer because you can see the letters that I’m writing: Watch unnamed | Streamable

[Jappe]

This is normal behaviour, when the output is too long to fit into the window.

[giuliomagnifico]

It’s the same for every service, it’s not the shell output, I understand what are saying and this is correct, but as I was saying, since some weeks, it started to have the same behavior with every service or every window/shel size.

Here’s a video with a long window shell with the same weird behavior: Watch Untitled | Streamable

If I press ctrl-c it blinks, if I press “enter” it makes those bracket on every line, and when I try to write something, I can’t see the prompt.

Edit: here’s a screenshot with a “short service output”, as you can see there is still the END instead of the prompt, and I have to ctrl-c to “exit”, but I still haven’t the prompt after ctrl-c, I have to press again it or press enter to make the prompt “works”. It’s hard to explain, the video explains better!

[Jappe]

When END is highlighted you can press q to quit.

[giuliomagnifico]

Oh, it works perfect! And the prompt doesn’t “disappear” after. But what is changed? Is possibile to go straight to the prompt if the service isn’t too long?

Also when the output is longer than the shell window, I remember that pressing the “space bar” automatically was redirecting to the prompt after the output was fully “scrolled”. So something is surely changed somewhere.

[Jappe]

I don*t know if there is a hotkey to jump straight to the end, but you can scroll faster with PageUp/PageDown.

[giuliomagnifico]

I mean that few weeks ago it (the shell/DietPI) was automatically exiting and get back to the prompt.

I want back the old behavior if possible

[Joulinar]

we don’t change anything from our side. Next, these are standard Debian function, not maintained by us.

[Jappe]

I can also not reproduce this beahaviour with systemctl or service, but normally it happens when you use less or more, like:

sudo systemctl status rsyslog.service | less

[giuliomagnifico]

Yes it wasn’t there since about one month!

But, since I don’t remember when it started, I don’t know what I changed!

Do you have any suggestions on how I can revert back this weird behavior?

[Jappe]

You can pipe the output to something else, like cat:

service rsyslog status | cat

[MichaIng]

Strange, I also cannot replicate it here, even when I make the SSH window very small so that the logs do not fit inside.

I know this happens with dpkg -l and some other commands since more recent Debian versions, but I do not remember seeing this for systemctl status prints. However, it does have the --no-pager option. This is used in two places in DietPi scripts as well, but I never know why. Now we know, though still unsure which condition triggers it.

Probably it depends on the terminal emulator/SSH client/TERM variable. Can you try it from another client system, another terminal emulator, and when you have another SSH client? And check whether echo $TERM shows something different in cases where the pager is used and where it is not used.