- For an AMD FX(tm)-6350 Six-Core Processor the file '/sys/.../present'
reports "0,3-7". I assume that chip is really an 8-core die with two
cores disabled... Presumably you could also get "0,3-4,6", and other
combos too...
Per manpage of mount(1) in newer util-linux:
The programs mount and umount traditionally maintained a list of
currently mounted filesystems in the file /etc/mtab. This real mtab
file is still supported, but on current Linux systems it is better
to make it a symlink to /proc/mounts instead, because a regular mtab
file maintained in userspace cannot reliably work with namespaces,
containers and other advanced Linux features.
In most new Linux (e.g. Debian) /etc/mtab is already symlinked to
/proc/mounts.
See
e778642a9e
for the gory details.
I ran cppcheck on a whim while trying to debug #103 and it found these possible
memory corruptions. They all seem to be buffers that were made one byte too
small (leaving out the byte for the C-string null terminator).
When we parse /proc/<pid>/* in order to populate the process struct, it isn't
necessary to try to remove any instance of "kdeinit: " anymore (IMO). Here is
why:
* If the user chooses to display full command lines (top_name_verbose = true),
then we should show full command lines without stripping useful info.
* The new basename entry already has a stripped down command. For example, if
the command line is "kdeinit4: kded4 [kdeinit]", then basename is "kded4".
* The code does not account for "kdeinit{4,5}: ", resulting in undesired
behavior, e.g. "kdeinit4: kded4 [kdeinit]" becomes "kdeinit4:".
* The code does not account for NUL separated arguments.
* The code opens /proc/<pid>/cmdline a second time, so this commit is a minor
optimization.
I think it is best to remove this code altogether. If anyone disagrees, please
comment or send me some hate mail with reasons why we should keep it. The commit
is easy enough to revert. :)
Since we now store a full command line for each process, a few problems are
apparent. For example, the names displayed by ${top ...} are verbose. This has
been partially addressed by the top_name_verbose option, but it is broken
whenever an executable name contains spaces. Another example is ${if_running},
which only matches the input if it exactly matches the entire command line.
This commit adds a basename (i.e. executable filename) entry to the process
struct. The intention is to store the executable filename from /proc/<pid>/stat,
which was the old 1.9.x behavior. This way, we have the best of both worlds.
Those who like the full command line can have it, and those who prefer the old
way can be satisfied too.
According to proc(5), /proc/<pid>/cmdline is supposed to have a NUL between each
argument, plus an additional NUL at the end. Instead of replacing each NUL with
a space, just replace the ones between arguments and ignore the rest.
Partial fix for #121.
If BUILD_IPV6=ON (default), but the user has disabled ipv6 support
in the kernel using the parameter ipv6.disable=1, then conky fails
to open /proc/net/if_inet6. This leads to a segfault when conky
calls fclose(file) regardless. This fix simply moves the fclose call
into the preceding if statement.
It now reports only reclaimable memory, by excluding shared memory,
and including the reclaimable part of the SLAB cache.
So '$mem' with 'no_buffers yes' is now the "really used" (unreclaimable) memory.
And when reaching OOM conditions, conky will always report high memory usage.
Related post:
http://calimeroteknik.free.fr/blag/?article20/really-used-memory-on-gnu-linux
In particular:
- Don't call get_battery_perct() recursively.
- Use define for length of string holding battery name.
- We can use strcpy() since bat is zero-terminated.
Before, in the case of an unknown battery status (which often happens on my Sony VAIO laptop after waking from sleep), the buffer would be unterminated.
(Although, this memmove trick is a bit odd. It would probably be better to remove the memmove's and put a single buffer[1] = '\0'; at the end of the function).
Conky takes process names from /proc/<pid>/stat and it's limited to 16
chars in kernel. That obviously makes top_name_width option to work only
for decreasing name length. To obtain longer names we parse
/proc/<pid>/cmdline.
Not every process has cmdline, so we take both process names and choose
one we want to use. Like this:
- Get process name from /proc/<pid>/stat
- Get process cmdline from /proc/<pid>/cmdline
- Transform cmdline to a bit simpler form(i.e. "/usr/bin/python
/usr/bin/terminator" to "python /usr/bin/terminator"), keeping
the arguments(might be changed easily)
- Choose the one that is longer and use it
Sometimes wlan related TEXT causes segment fault, and backtrace shows it's strtok in
iw_get_stats.
I read the code of wireless_tools, which says 'strtok not thread safe, not used in WE-12 and
later' for iw_get_stats. But it need to first check if has_range and then we_version_compiled.
In conky/src/linux.cc, iw_get_stats is called before iw_get_range_info, hence has_range is always
0 in iw_get_stats and strtok is used. I simply move iw_get_range_info before iw_get_stats and no
segfault up to now.
patch by ruikai
* process* management left to top.cc
* compile with -Wall -Werror (lots of wasted time for stupid errors)
* unify find_process() and new_process(), as used always together
Signed-off-by: Pavel Labath <pavelo@centrum.sk>
this sort of fixes sf.net #3306538. The person there correctly tested for the existance of the
file with $if_existing, but the problem is we run the callbacks regardless of the conditional
tests.
