| Age | Commit message (Collapse) | Author |
|---|
|
Another row clipping check off by one, it'd be nice to make this
draw text into partial rows... but this as-is may just scribble.
|
|
More clarification of delay/timeout units in naming
|
|
When using vmon to monitor a system PID1 will kill it @
shutdown/reboot, and we should save one last snapshot of what's
been captured before we exit in that case.
SIGTERM is sent first before the SIGKILL killing spree, so let's
handle the SIGTERM by writing the snapshot, then exiting the main
loop.
The service manager can then do something with the produced
snapshots after we've exited, if they're considered interesting.
|
|
--wip-name sets a constant name to use for the pre-rename temp
name of snapshots.
Otherwise a dynamic dot-filename augmented from the destination
name is used.
The impetus for this is to simplify garbage collection of
produced PNGs. We'll ignore dot-files to never step on the WIP
file during GC, but would like vmon to truncate and reuse the
same WIP name so it's not potentially accumulating the dot-files
in weird failure modes where the snapshots repeatedly fail to
complete and get renamed.
So in such a scenario we'll pass a dot-file for --wip-name and
vmon will keep reusing that name, never leaking more than the
single WIP file in even a persistent a failure mode.
|
|
|
|
|
|
This switches to constructing the WIP png in a temporary dot-file
derived from the final name, then an atomic rename from the
dot-file to the final name. The temporary name is placed in the
same directory as the final one.
|
|
Part of the reason for adding headless support in vmon is to
facilitate embedded use cases. These are often incompatible with
anti-tivoization aspects of gplv3.
I am the copyright holder of all this stuff so it's entirely fine
to switch to gplv2. Phil Freeman contributed one trivial patch
(4183fbd), regardless I checked if he had any objections to the
gplv2 switch and he had none.
So here we go, gplv2 all the things.
|
|
This causes snapshot filenames to always get the current time
instead of the start time of the vmon session
|
|
Takes a number of seconds interval argument, arranges for an
interval timer to trigger the sigusr1 handler which causes a
snapshot to be generated.
e.g. `./vmon --snapshots 1` will produce a .png per second
|
|
|
|
This isn't currently very discoverable, and without mention of it
one is likely to just try sending SIGCHLD to vmon for snapshots.
|
|
When this code changed to use a local, potentially heap-allocated
name variable, it started producing "(null)" when no -n/--name
was supplied, that wasn't intended.
Just use a "" name when NULL, enabling bare date-derived snapshot
filenames. This seems preferable since even if you supplied an
empty -n/--name you'd get a hyphen at the start of the name. I
can see scenarios where you have unnamed files labeled by the
output dir instead.
|
|
I don't think I intended this to be permanent, though it might be
nice to have /something/ printed to signify the transition to
breaking the main loop. Something more appropriate can come back
if necessary.
|
|
vmon already handles SIGUSR1 for producing png snapshots on
demand, adding a fmt specifier for substituting the vmon PID
makes for convenient scripting of triggering such snapshots.
i.e:
$ vmon -- /bin/bash -c 'for((i = 0; i < 10; i++)); do kill -USR1 %P; sleep 1s; done'
Would produce ten png snapshots of the charts on 1-second
intervals.
|
|
This adds runtime expansion of the executed command's argv, to
support things like passing the vmon X window id to the executed
command, session name, and output dir.
Format specifiers currently supported by this commit:
%W X window id for vmon in hexadecimal
%n verbatim name supplied via --name
%N filename-safe variant of name supplied via --name
%O output directory supplied via --output-dir (or ".")
%% literal %
There's not curerrently any escaping syntax implemented, relying
entirely on %-stuffing to escape interpolation. i.e. use %%N to
express %N post-interpolation.
This commit also adds SIGINT and SIGQUIT handlers when executing
a command. The first such signal received is simply propagated
to the child command's process, which upon exiting will trigger
the existing SIGCHLD behavior (snapshot if requested, exit).
If a subsequent repeated SIGINT or SIGQUIT is received, an abrupt
exit is performed without waiting for SIGCHLD or otherwise
synchronizing with the child process.
The impetus for this is to enable running recordMyDesktop
alongside the executed command to record the vmon window while
running things like benchmarks or other high-level profiling/CPU
usage over time observations.
The recordMyDesktop utility already responds to SIGINT for ending
a recording, so SIGINT propagation should be sufficient for
recording vmon sessions - provided the recordMyDesktop process is
positioned to receive signals in the executed command. i.e. is
the foreground process or session leader if executed via
something like a `/bin/bash -c` construction.
Some effort has been made to ensure the vmon window is mapped
before running the executed command (XMapWindow() && XSync()).
But with SubstructureRedirect in play, as when a window manager
is active, this alone isn't sufficient to ensure the window is
actually mapped and viewable.
This poses a problem with for the current `recordMyDesktop
--windowid` implementation, which hard fails when the specified
window isn't already mapped and visible. Depending on who wins
the race, the window may not yet actually be mapped by the window
manager by the time recordMyDesktop queries its attributes. But
this is something to fix in recordMyDesktop, even if vmon waited
for a MapNotify event before executing the command, the window
could become unmapped by the window manager - or maybe it
wouldn't even become mapped in a timely fashion if it's placed on
a hidden virtual desktop at the time. The recording tool needs
to just be more robust in this regard, and should really follow
the window around anyways, as well as do things like maybe pause
the recording when unmapped, etc. Out of scope for vmon.
The aforementioned `recordMyDesktop --windowid` race has been
filed as an issue @
https://github.com/recordmydesktop/recordmydesktop/issues/7
|
|
Lack of any statement angers some compilers, just drop it.
|
|
This adds an externally triggered means of snapshotting, which
is always available, not only with --snapshot.
|
|
Apparently I never actually made this conditional on the flag...
|
|
also sort flags alphabetically in help output
|
|
|
|
|
|
|
|
16+NUL was clearly too short for descriptive names, pushed it
all up to get closer to the common 256 fs limit.
|
|
Currently only vmon wires this up to --name, but vwm could get
the window title of the window being overlayed and pass that in
if set...
|
|
Shows in the window title and the start of snapshot filenames
|
|
This implements saving the chart contents to a PNG file created
in the output dir upon receiving SIGCHLD.
|
|
Preparatory commit; saved PNGs need a place to go, and the user
needs a way to control that. Defaults to CWD (".")
|
|
Preparatory commit; PNG snapshots will be named using the start time
|
|
This makes vmon exit more cooperatively when window managers kindly
ask it to with a message rather than requiring XKillClient().
|
|
|
|
|
|
|
|
|
|
vmon introduces a non-overlay usage, monitors is correct but ambiguous,
graphs is also amiguous, charts is short and distinctive.
renaming of the files comes in a separate, future commit.
|
|
In the course of applying the new style over the rest of the code I
decided it's obnoxiouos and prefer the old way of indenting the cases
one level from the switch. I know it wastes horizontal space and can
see the value of flattening the cases with the switch, but once you
start having variables at the start of the switch body, and blocked
cases, it just starts becoming quite unattractive without the indentation.
|
|
I think I've developed a force of habit typing `static inline` after
the ray tracer in rototiller.
|
|
vmon exposes the monitoring overlays of vwm through a standalone
commandline utility by creating dedicated window for presenting the
overlay.
At this time a single preexisting PID may be specified, forming the root of
a recursively monitored heirarchy. Alternatively, a command may specified
which vmon will then fork and execute on your behalf, automatically
monitoring the child and its descendants for you, in a style similar to
strace.
Examples:
Monitor a linux kernel build in fullscreen mode, note the --:
`vmon --fullscreen -- make -C /usr/src/linux -j8`
Monitor the entire system:
`vmon --fullscreen --pid 1`
For convenience, omitting --pid and a command to run assumes PID 1:
`vmon --fullscreen` is analogous to `vmon --fullscreen --pid 1`
Monitor a linux kernel build fullscreen at 50Hz:
`vmon --fullscreen --hertz 50 -- make -C /usr/src/linux -j8`
Do the same thing but don't exit when the make completes:
`vmon --linger --fullscreen --hertz 50 -- make -C /usr/src/linux -j8`
Help is provided via `vmon --help`, where you'll find all flags described
with their short and long forms.
Some important TODO items include:
- Support for specifying multiple top-level processes
- Support for mixing --pid and running a command
(useful for watching specific system processes while you're running
something specific)
- Support for scrolling within the window. The overlays in general need
to evolve a bit to better support the vmon use case. In vwm there
wasn't any intention of accomodating the entire space if it exceeded
what was naturally available in the existing window's dimensions.
That makes sense for vwm, but vmon not so much.
You can achieve the same thing more or less by resizing the window to be
larger than the screen (easy to do in vwm using a combination of
Mod1-Right-Click to resize, then Mod1-Left-Click to drag the window,
repeatedly. Then just Mod1-Left-Click to grab the window and "scroll"
it by moving the desired part on-screen, repeatedly. Cumbersome, but
works fine in a pinch. Not all window managers can do this though...
Of course it would be less costly to only render what's visible, like a
scrollable window would achieve. This is probably the top priority
TODO.
- Support for monitoring of memory use, files, per-process IO activity.
libvmon supports substantially more than is being visualized currently.
- Support for changing the font.
|
