Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Colorize zpool status output #9340

Merged
merged 1 commit into from
Dec 20, 2019
Merged

Colorize zpool status output #9340

merged 1 commit into from
Dec 20, 2019

Conversation

tonyhutter
Copy link
Contributor

@tonyhutter tonyhutter commented Sep 21, 2019

Motivation and Context

Add colored zpool status output so admins can quickly spot a unhealthy vdev/pool.

Description

If the ZFS_COLOR env variable is set, then use ANSI color output in zpool status:

  • Column headers are bold
  • Degraded or offline pools/vdevs are yellow
  • Non-zero error counters and faulted vdevs/pools are red
  • The 'status:' and 'action:' sections are yellow if they're displaying a warning.

Screenshots:

zpool_color3

zpool_color2

How Has This Been Tested?

Manually tested. Added test case to look for bold, yellow and red text.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation (a change to man pages or other documentation)

Checklist:

@tonyhutter
Copy link
Contributor Author

Looks like I'm seeing some test failures:

Test: /usr/share/zfs/zfs-tests/tests/functional/cli_root/zpool/zpool_colors (run as root) [00:04] [FAIL]
20:54:29.63 ASSERTION: Test colorized zpool status output
20:54:29.70 SUCCESS: dd if=/dev/urandom of=//mnt/testdir/testfile bs=10M count=1
20:54:30.56 SUCCESS: zpool export testpool
20:54:31.78 SUCCESS: zpool import testpool
20:54:31.78 'unknown': I need something more specific.
20:54:31.78 NOTE:   
20:54:31.82 SUCCESS: zpool offline -f testpool loop4

This is coming from ncurses:

'unknown': I need something more specific.

Maybe we need ncurses-term installed on Ubuntu?:

https://unix.stackexchange.com/questions/213726/ssh-from-screen-leads-to-unknown-terminal-error

I'm looking into it.

@ahrens ahrens added the Type: Feature Feature request or new feature label Nov 13, 2019
@ahrens
Copy link
Member

ahrens commented Nov 13, 2019

Live demo from the 2018 OZDS hackathon, where this project won first place 🥇 : https://youtu.be/zN_tGxCpTBU?t=430

When do we get 🔥 emoji support? :-)

@ahrens
Copy link
Member

ahrens commented Nov 13, 2019

Would it be possible to auto-detect if the terminal supports color and turn this on by default, like git seems to do?

@tonyhutter
Copy link
Contributor Author

@ahrens one issue is that people screen scrape the zpool status output with awk. Each color escape code counts as a field in awk, so if we turned on color by default it's probably going to mess up the column counting in a bunch of scripts.

I decided to pass on the emojis for now, since I didn't know of a good way to detect if they're supported in the terminal. And they're a little too silly :-)

@lundman
Copy link
Contributor

lundman commented Nov 14, 2019

Generally, things like git use isatty() to have colour, and disable if not, so if you pipe to awk it will be disabled.

@spacelama
Copy link

And --color[=yes|auto|no (default yes if --color supplied without a parameter)], defaulting to
--color=auto if --color not supplied.

@tonyhutter
Copy link
Contributor Author

tonyhutter commented Nov 14, 2019

@lundman thanks for the suggestion about isatty(). Let me look into that. I'd personally like the colors on by default if we know that it's not going to interfere with anything.

@richardelling
Copy link
Contributor

tty colors are a human factors disaster. theee is no way for the dev to know the contrast of the terminal’s colors. so the dev says “I think good things should be green” without realizing that some folks use green as the background, rendering it unreadable. the typical egregious colors are blue/black, but the real problem is you have no idea what the users preferences are. also cut-n-paste often picks up the background and foreground colors... spreading the ugliness. personally, I use different color backgrounds to differentiate being logged into different machines, workflows, or tasks. but the most telling story is recently a colleague did this in a product, when we went onsite with a customer, the customer’s preferences rendered more than 50% of the text unreadable. thus the product had to be changed to allow the customer to choose color combinations (of which there are thousands to choose from) for each and every possible rendering. human factors disaster compounded.

just say no to colors by default

cmd/zpool/zpool_main.c Show resolved Hide resolved
#include <term.h>
/*
* For some reason, term.h #defines 'lines' (in lower case) as a macro.
* Since we also have a variable named 'lines', undefine the macro here.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even though this works, I think we should go ahead and rename the our local lines variable to avoid the conflict entirely. Then drop this block. According to the curses documentation, curs_terminfo(3X).

      ·   If use_env(FALSE) has been called, values for lines and  columns  specified
           in terminfo are used.

Which would be handy if we decide it's desirable to use more of the libraries functionality.

* If it's not supported, then silently don't use it.
*/
if (setupterm(NULL, fileno(stdout), (int *)0) == 0 &&
tigetnum("colors") >= 16) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe && isatty(stdout) for good measure.

color_start(color);

va_start(aptr, format);
vsprintf(buf, format, aptr);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you use vsnprintf() here to avoid any overflow and make sure it's null-terminated.

man/man8/zpool.8 Outdated
Use ANSI color in
.Nm zpool status
output.
.El
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you move this up after ZFS_ABORT to keep the environment variables alphabetically ordered. Moving ZFS_VDEV_DEVID_OPT_OUT` up wouldn't be a bad thing either.

@tonyhutter
Copy link
Contributor Author

It sounds like there's no consensus on colors on/off by default, so we'll keep them off unless you export ZFS_COLOR=1.

@behlendorf I implemented all your changes in my latest push. I'm still getting test failures in buildbot though, so I've added some instrumentation printfs. Please don't pull this in until I can get all the tests passing.

@tonyhutter tonyhutter removed the Status: Work in Progress Not yet ready for general review label Nov 26, 2019
lib/libzfs/libzfs_util.c Outdated Show resolved Hide resolved
cmd/zpool/zpool_main.c Outdated Show resolved Hide resolved
@tonyhutter
Copy link
Contributor Author

@behlendorf my latest push fixes all your comments

@behlendorf behlendorf requested review from a user and lundman December 18, 2019 02:05
@behlendorf
Copy link
Contributor

@lundman @freqlabs would you mind double checking this PR to ensure it does make sense for your respective platforms. We can f course tweak it latter if needed. By default, the colors are disabled so you will need to set the ZFS_COLOR environment variable if you test it locally.

@lundman
Copy link
Contributor

lundman commented Dec 18, 2019

PR to ensure it does make sense for your respective platforms.

Looks to be standard porting, strcmp -> strlcmp for the noise reduction (deprecated) , not sure about exit() in a library, but if you are OK with it, so am I.
Not sure what comment "FG" for forground color refers to, but then... it's 'just a comment' :)

Yeah, should be fine to port over.

cmd/zpool/zpool_main.c Outdated Show resolved Hide resolved
cmd/zpool/zpool_main.c Outdated Show resolved Hide resolved
include/libzutil.h Outdated Show resolved Hide resolved
lib/libzfs/libzfs_util.c Outdated Show resolved Hide resolved
@tonyhutter
Copy link
Contributor Author

@lundman @freqlabs thanks, I'll implement your changes.

@codecov
Copy link

codecov bot commented Dec 19, 2019

Codecov Report

Merging #9340 into master will decrease coverage by <1%.
The diff coverage is 66%.

Impacted file tree graph

@@           Coverage Diff            @@
##           master    #9340    +/-   ##
========================================
- Coverage      80%      79%   -<1%     
========================================
  Files         385      385            
  Lines      121302   121467   +165     
========================================
+ Hits        96526    96561    +35     
- Misses      24776    24906   +130
Flag Coverage Δ
#kernel 80% <ø> (ø) ⬆️
#user 67% <66%> (ø) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a364048...c2e1080. Read the comment docs.

If the ZFS_COLOR env variable is set, then use ANSI color
output in zpool status:

- Column headers are bold
- Degraded or offline pools/vdevs are yellow
- Non-zero error counters and faulted vdevs/pools are red
- The 'status:' and 'action:' sections are yellow if they're
  displaying a warning.

This also includes a new 'faketty' function in libtest.shlib that is
compatible with FreeBSD (code provided by @freqlabs).

Signed-off-by: Tony Hutter <hutter2@llnl.gov>
@behlendorf behlendorf added Status: Accepted Ready to integrate (reviewed, tested) and removed Status: Code Review Needed Ready for review and testing labels Dec 19, 2019
@behlendorf behlendorf merged commit 9fb2771 into openzfs:master Dec 20, 2019
@tonyhutter
Copy link
Contributor Author

@behlendorf as a side note - we can probably remove ncurses-dev from buildbot since we ended up not using it.

@behlendorf
Copy link
Contributor

Good call, will do.

@ethan-coe-renner ethan-coe-renner mentioned this pull request Dec 13, 2022
13 tasks
@ethan-coe-renner ethan-coe-renner mentioned this pull request Jan 4, 2023
13 tasks
@ethan-coe-renner ethan-coe-renner mentioned this pull request Feb 3, 2023
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Accepted Ready to integrate (reviewed, tested) Type: Feature Feature request or new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants