Skip to content

cgtop enhancements for easier machine-readable output#3

Merged
poettering merged 4 commits intosystemd:masterfrom
threatgrid:more_cgtop_enhancements
Jun 10, 2015
Merged

cgtop enhancements for easier machine-readable output#3
poettering merged 4 commits intosystemd:masterfrom
threatgrid:more_cgtop_enhancements

Conversation

@charles-dyfis-net
Copy link
Contributor

Tracking patchset previously submitted to mailing list; see thread starting at http://lists.freedesktop.org/archives/systemd-devel/2015-May/032358.html


In addition to the previously-submitted patch adding support for "raw" (numeric byte-count, as opposed to human-readable) values, this series adds several new enhancements:

  • Allow the user to specify a strftime-compatible string to use as header.
  • Retain default behavior of using only one iteration when output is not to a TTY, but allow endless looping (with an explicit value of 0) or a set iteration count to be selected.
  • Improve output format in the non-TTY case for easy parsing (separating batches with an empty line, rather than the de facto "\r \r" string intended to clear artifacts from user input, and ensuring that flushing stdout happens before the sleep between runs).

The strftime support, by its nature, requires use of an externally-provided format string; consequently, an appropriate pragma is used to suppress warnings from gcc. Feedback appreciated.

@zonque zonque added RFE 🎁 Request for Enhancement, i.e. a feature request cgroups labels Jun 2, 2015
msekletar referenced this pull request in msekletar/systemd Jun 2, 2015
=================================================================
==64281==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x7f623c961c4a in malloc (/usr/lib64/libasan.so.2+0x96c4a)
    #1 0x5651f79ad34e in malloc_multiply (/home/crrodriguez/scm/systemd/systemd-modules-load+0x2134e)
    #2 0x5651f79b02d6 in strjoin (/home/crrodriguez/scm/systemd/systemd-modules-load+0x242d6)
    #3 0x5651f79be1f5 in files_add (/home/crrodriguez/scm/systemd/systemd-modules-load+0x321f5)
    #4 0x5651f79be6a3 in conf_files_list_strv_internal (/home/crrodriguez/scm/systemd/systemd-modules-load+0x326a3)
    #5 0x5651f79bea24 in conf_files_list_nulstr (/home/crrodriguez/scm/systemd/systemd-modules-load+0x32a24)
    #6 0x5651f79ad01a in main (/home/crrodriguez/scm/systemd/systemd-modules-load+0x2101a)
    #7 0x7f623c11586f in __libc_start_main (/lib64/libc.so.6+0x2086f)

SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s).

This happens due to the wrong cleanup attribute is used (free vs strv_free)
msekletar referenced this pull request in msekletar/systemd Jun 2, 2015
If systemd is built with GCC address sanitizer or leak sanitizer
the following memory leak ocurs:

May 12 02:02:46 linux.site systemd[326]: =================================================================
May 12 02:02:46 linux.site systemd[326]: ==326==ERROR: LeakSanitizer: detected memory leaks
May 12 02:02:46 linux.site systemd[326]: Direct leak of 101 byte(s) in 3 object(s) allocated from:
May 12 02:02:46 linux.site systemd[326]: #0 0x7fd1f504993f in strdup (/usr/lib64/libasan.so.2+0x6293f)
May 12 02:02:46 linux.site systemd[326]: #1 0x55d6ffac5336 in strv_new_ap src/shared/strv.c:163
May 12 02:02:46 linux.site systemd[326]: #2 0x55d6ffac56a9 in strv_new src/shared/strv.c:185
May 12 02:02:46 linux.site systemd[326]: #3 0x55d6ffa80272 in generator_paths src/shared/path-lookup.c:223
May 12 02:02:46 linux.site systemd[326]: #4 0x55d6ff9bdb0f in manager_run_generators src/core/manager.c:2828
May 12 02:02:46 linux.site systemd[326]: #5 0x55d6ff9b1a10 in manager_startup src/core/manager.c:1121
May 12 02:02:46 linux.site systemd[326]: #6 0x55d6ff9a78e3 in main src/core/main.c:1667
May 12 02:02:46 linux.site systemd[326]: #7 0x7fd1f394e8c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
May 12 02:02:46 linux.site systemd[326]: Direct leak of 29 byte(s) in 1 object(s) allocated from:
May 12 02:02:46 linux.site systemd[326]: #0 0x7fd1f504993f in strdup (/usr/lib64/libasan.so.2+0x6293f)
May 12 02:02:46 linux.site systemd[326]: #1 0x55d6ffac5288 in strv_new_ap src/shared/strv.c:152
May 12 02:02:46 linux.site systemd[326]: #2 0x55d6ffac56a9 in strv_new src/shared/strv.c:185
May 12 02:02:46 linux.site systemd[326]: #3 0x55d6ffa80272 in generator_paths src/shared/path-lookup.c:223
May 12 02:02:46 linux.site systemd[326]: #4 0x55d6ff9bdb0f in manager_run_generators src/core/manager.c:2828
May 12 02:02:46 linux.site systemd[326]: #5 0x55d6ff9b1a10 in manager_startup src/core/manager.c:1121
May 12 02:02:46 linux.site systemd[326]: #6 0x55d6ff9a78e3 in main src/core/main.c:1667
May 12 02:02:46 linux.site systemd[326]: #7 0x7fd1f394e8c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
May 12 02:02:46 linux.site systemd[326]: SUMMARY: AddressSanitizer: 130 byte(s) leaked in 4 allocation(s).

There is a leak due to the the use of cleanup_free instead _cleanup_strv_free_
msekletar referenced this pull request in msekletar/systemd Jun 2, 2015
$ /usr/lib/systemd/systemd-timedated (wait until auto-exit)

=================================================================
==396==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 928 byte(s) in 1 object(s) allocated from:
    #0 0x7f782f788db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1)
    #1 0x562a83ae60cf in bus_message_from_header src/libsystemd/sd-bus/bus-message.c:480
    #2 0x562a83ae6f5a in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:576
    #3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
    #4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
    #5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
    #6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
    #7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
    #8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
    #9 0x562a83aae1af in main src/timedate/timedated.c:730
    #10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)

Indirect leak of 77 byte(s) in 1 object(s) allocated from:
    #0 0x7f782f788f6a in realloc (/usr/lib64/libasan.so.2+0x96f6a)
    #1 0x562a83ad418a in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:963
    #2 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
    #3 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
    #4 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
    #5 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
    #6 0x562a83aae1af in main src/timedate/timedated.c:730
    #7 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)

Indirect leak of 2 byte(s) in 1 object(s) allocated from:
    #0 0x7f782f75493f in strdup (/usr/lib64/libasan.so.2+0x6293f)
    #1 0x562a83b0229b in bus_message_parse_fields src/libsystemd/sd-bus/bus-message.c:5382
    #2 0x562a83ae7290 in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:601
    #3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
    #4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
    #5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
    #6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
    #7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
    #8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
    #9 0x562a83aae1af in main src/timedate/timedated.c:730
    #10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)

SUMMARY: AddressSanitizer: 1007 byte(s) leaked in 3 allocation(s).

This is due to missing  _cleanup_bus_message_unref_ in context_read_ntp()
mischief referenced this pull request in coreos/systemd Jun 2, 2015
allow domain names > HOST_NAME_MAX but < DOMAIN_NAME_MAX in dhcp client
@charles-dyfis-net charles-dyfis-net force-pushed the more_cgtop_enhancements branch from 16b8b12 to 19b9c6a Compare June 10, 2015 00:30
- Explicitly flush stdout before sleep between iterations
- Only clear user keystrokes when output is to TTY
- Add a newline between output batches when output is not to TTY
@charles-dyfis-net
Copy link
Contributor Author

Updated per review feedback, and rebased onto current master.

@charles-dyfis-net charles-dyfis-net force-pushed the more_cgtop_enhancements branch from 19b9c6a to bced7ec Compare June 10, 2015 00:45
@poettering poettering added the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Jun 10, 2015
@charles-dyfis-net charles-dyfis-net force-pushed the more_cgtop_enhancements branch 4 times, most recently from 7ffeb93 to 1e015e7 Compare June 10, 2015 21:59
@charles-dyfis-net
Copy link
Contributor Author

Updated per feedback: Removed the --time flag, reworked up the io_valid patch.

@charles-dyfis-net charles-dyfis-net force-pushed the more_cgtop_enhancements branch from 1e015e7 to 426ba71 Compare June 10, 2015 22:07
@charles-dyfis-net
Copy link
Contributor Author

(and one more little change, removing a stray newline in the docbook XML and correcting accuracy of a comment in the code).

@charles-dyfis-net
Copy link
Contributor Author

BTW, I can't say I much like having human-formatted dates in output intended for machine use. When those dates could be formatted as UNIX times, it was trivial to distinguish those lines -- if a line contained only numbers, it was a date; less so now. I might be tempted to withdraw the patch adding times altogether, if that's considered reasonable.

@charles-dyfis-net charles-dyfis-net force-pushed the more_cgtop_enhancements branch from 426ba71 to a100bf0 Compare June 10, 2015 22:18
@charles-dyfis-net
Copy link
Contributor Author

This has been done -- that portion of the patch is rebased out and should be considered withdrawn.

@poettering
Copy link
Member

For journalctl we currently support a mode that shows the monotonic clock instead of the wallclock. (-o short-monotonic) Wouldn't that be what you actually want for the --time stuff?

…ged since last tick

Emit "0" rather than "-" if no change in IO values are seen for a process since
last tick, so long as accounting has registered content at all.
@charles-dyfis-net charles-dyfis-net force-pushed the more_cgtop_enhancements branch from a100bf0 to 1d84ae0 Compare June 10, 2015 23:06
@csy97 csy97 mentioned this pull request Aug 18, 2021
@pawanbadganchi pawanbadganchi mentioned this pull request Jun 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cgroups reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks RFE 🎁 Request for Enhancement, i.e. a feature request

Development

Successfully merging this pull request may close these issues.

3 participants