yadutaf / ctop Goto Github PK

View Code? Open in Web Editor NEW

423.0 423.0 34.0 238 KB

A command line / text based Linux Containers monitoring tool that works just like you expect.

Home Page: https://pypi.python.org/pypi/ctop

License: MIT License

Python 100.00%

ctop's People

Contributors

Stargazers

Watchers

ctop's Issues

Permanent error "Cannot allocate memory"

Hello!

This problem looks little strange.
On one hw node, start without interval and -

./ctop --follow=/1212
Traceback (most recent call last):
  File "./ctop", line 903, in <module>
    main()
  File "./ctop", line 877, in main
    collect(measures)
  File "./ctop", line 349, in collect
    cur[cgroup.name]['blkio.throttle.io_service_bytes'] = cgroup['blkio.throttle.io_service_bytes']
  File "./ctop", line 246, in __getitem__
    content = f.read().strip()
IOError: [Errno 12] Cannot allocate memory

./ctop --follow=/1212
Traceback (most recent call last):
  File "./ctop", line 903, in <module>
    main()
  File "./ctop", line 877, in main
    collect(measures)
  File "./ctop", line 349, in collect
    cur[cgroup.name]['blkio.throttle.io_service_bytes'] = cgroup['blkio.throttle.io_service_bytes']
  File "./ctop", line 246, in __getitem__
    content = f.read().strip()
IOError: [Errno 12] Cannot allocate memory

And again without pause next two start ctop work good with this key and without it.
On hw node was availble ~10G free memroy and 100+G cached memory, when I run ctop.

Minor Issue: Can't see Container names

Great tool you wrote. Quick note: When installing via pip, using pip install ctop, the program cannot resolve container names and will only show the numeric id. When installing via your wget command example, ctop can. Is there a slight difference in what is released on pypi and on github?

Thanks!

Filter by type

Hi, it would be useful to apply a filter by container type. Real use case: show only docker containers and hide all systemd.

KeyError: 'tasks' when running

Hi, I love ctop, and it usually works well for me, but today I installed ctop from apt, and when I ran it, I got the following stacktrace and error:

root@hostname:~# ctop
Traceback (most recent call last):
  File "/usr/bin/ctop", line 4, in <module>
    cgroup_top.main()
  File "/usr/lib/python3/dist-packages/cgroup_top.py", line 795, in main
    results = built_statistics(measures, CONFIGURATION)
  File "/usr/lib/python3/dist-packages/cgroup_top.py", line 359, in built_statistics
    'tasks': len(data['tasks']),
KeyError: 'tasks'

Not sure if the ctop version is old and this is an irrelevant bug, nonetheless there it is. I'm using ctop/xenial,now 0.4.1-1 all [installed].

Memory usage is misleading

There was a long-standing bug in Docker stats util (moby/moby#10824), which included caches into the memory usage reporting. While it was fixed recently in Docker 17.06 (docker/cli#80), ctop is still affected by the issue.

I think it is worth porting the new way of memory usage reporting from the docker/cli#80.

exit shell / console

When using ctop to access a containers console or shell, exit from that shell returns back to the console login. Ctrl c, q etc do nothing at this point and the shell session has to be terminated

Need an exit method that returns back to ctop screen

OpenVZ support

Hello!

Are you planned to add OpenVZ support to ctop?

Now with openvz not work memory usage output -

Unfortunatly memory limited without cgroup mountpoints memory on OpenVZ.
Info about containers memory usage can be parse from /proc/user_beancounters

     1210:  kmemsize                 15746882             18927616  9223372036854775807  9223372036854775807                    0
            lockedpages                  3964                 4008               614400               614400                    0
            privvmpages                 64129               106034              2457600              2457600                    0
            shmpages                     2897                 6435  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numproc                        38                   81                  512                  512                    0
            physpages                   93052               107404                    0               614400                    0
            vmguarpages                     0                    0               614400  9223372036854775807                    0
            oomguarpages                 7500                 8646               614400  9223372036854775807                    0
            numtcpsock                     14                   35                64000                64000                    0
            numflock                        4                    8                 2048                 2048                    0
            numpty                          0                   10  9223372036854775807  9223372036854775807                    0
            numsiginfo                      0                   36  9223372036854775807  9223372036854775807                    0
            tcpsndbuf                  244160              3242288  9223372036854775807  9223372036854775807                    0
            tcprcvbuf                  229376              2468192  9223372036854775807  9223372036854775807                    0
            othersockbuf                90168               234176  9223372036854775807  9223372036854775807                    0
            dgramrcvbuf                     0                 6936  9223372036854775807  9223372036854775807                    0
            numothersock                   74                   87  9223372036854775807  9223372036854775807                    0
            dcachesize                6946034              7279958  9223372036854775807  9223372036854775807                    0
            numfile                       719                 1055                64000                64000                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numiptent                      27                   27                  256                  256                    0

or from vzlist output

vzlist -H -o physpages 1212 
    122044
vzlist -o physpages 1212 -j
[
  {
    "physpages": {
      "held": 122043,
      "maxheld": 999576,
      "barrier": 0,
      "limit": 614400,
      "failcnt": 30
    }
  }
]

as exapmle.

Refresh ctop after kill a container

Hi,

Run ctop
Start a container
ctop detect new container
Stop or kill container
ctop doesn't remove container
restart ctop
ctop does not display removed container

We have to restart ctop to not see removed container. Is-it the desired behaviour ?

/bin/bash is not always available in Docker images

Hello and thanks for this useful tool!

Maybe you can make it a bit more flexible by letting the user choose the shell he want use to enter in a container.
Today, you impose /bin/bash as shell:

ctop/cgroup_top.py

Line 835 in 0a241d8

    
           run(-2, ['docker', 'exec', '-it', selected_name, '/bin/bash'], interactive=True)

But it is not installed in every Docker images (by example, in very common Alpine ones)

Have a great day,
Antoine

Initial runtime error

I installed via pip, tried to run ctop and got the following error:

Traceback (most recent call last):
  File "/home/rando/python/venv/2.7.3/bin/ctop", line 4, in <module>
    cgroup_top.main()
  File "/home/rando/python/venv/2.7.3/local/lib/python2.7/site-packages/cgroup_top.py", line 746, in main
    display(stdscr, results, CONFIGURATION)
  File "/home/rando/python/venv/2.7.3/local/lib/python2.7/site-packages/cgroup_top.py", line 432, in display
    CONFIGURATION['selected_line_name'] = CONFIGURATION['cgroups'][CONFIGURATION['selected_line_num']]
IndexError: list index out of range

Is there something i'm supposed to do first?
Is this a limitation of my system? I'm on ubuntu 12.04.
I usually run docker via boot2docker b/c I know my kernel is old... does ctop require something I don't have?

IndexError when specifying type and no container of that type exists

When starting ctop with a type and no container of that type exists, ctop doesn't start and prints a trace.

When there are containers of that type ctop starts normally.
However when, at some time, all containers of that type are removed ctop will halt with the same trace.

$ ctop --type=docker
Traceback (most recent call last):
  File "/usr/local/bin/ctop", line 4, in <module>
    cgroup_top.main()
  File "/usr/local/lib/python2.7/dist-packages/cgroup_top.py", line 1019, in main
    display(stdscr, results, CONFIGURATION)
  File "/usr/local/lib/python2.7/dist-packages/cgroup_top.py", line 619, in display
    CONFIGURATION['selected_line_name'] = CONFIGURATION['cgroups'][CONFIGURATION['selected_line_num']]
IndexError: list index out of range

Python: 2.7.6
Docker: 1.13.1
Ubuntu: 14.04.5 LTS

exits with KeyError: 'cpuacct.stat'

Hi, Thanks for creating this nice tool.
For me it runs ok, screen refreshing, but sometimes after a few seconds exits without intervention, with:

$ python /opt/ctop
Traceback (most recent call last):
  File "/opt/ctop", line 1043, in <module>
    main()
  File "/opt/ctop", line 1017, in main
    collect(measures)
  File "/opt/ctop", line 405, in collect
    cur[cgroup.name]['cpuacct.stat.diff'][key] = value - prev[cgroup.name]['cpuacct.stat'][key]
KeyError: 'cpuacct.stat'

I'm using:

Python 2.7.12
Docker version 1.12.2, build bb80604
Ubuntu 16.04.1 LTS \n \l
Linux monolith 4.4.0-47-generic #68-Ubuntu SMP

Thx
Phil

[edit - also happens with python 3.5.2 ]

column for exposed ports

CTOP is the awesome tool.
It would be very useful to have an optional column for port binds.

IOError: [Errno 2] No such file or directory: '/sys/fs/cgroup/blkio/blkio.throttle.io_service_bytes'

docker is running, yet ctop fails to start

Traceback (most recent call last):
  File "/usr/lib/python-exec/python2.7/ctop", line 4, in <module>
    cgroup_top.main()
  File "/usr/lib64/python2.7/site-packages/cgroup_top.py", line 887, in main
    collect(measures)
  File "/usr/lib64/python2.7/site-packages/cgroup_top.py", line 349, in collect
    cur[cgroup.name]['blkio.throttle.io_service_bytes'] = cgroup['blkio.throttle.io_service_bytes']
  File "/usr/lib64/python2.7/site-packages/cgroup_top.py", line 245, in __getitem__
    with open(path) as f:
IOError: [Errno 2] No such file or directory: '/sys/fs/cgroup/blkio/blkio.throttle.io_service_bytes'

Limit for max count containers on hw node

Hello.

Are ctop have limit for max cout containers on node?
About 60 containers on node?

If I run ctop on node with 55 containers - it work good.

If I run ctop on node with 60 containers or more - it failed with error

./ctop 
Traceback (most recent call last):
  File "./ctop", line 836, in <module>
    main()
  File "./ctop", line 811, in main
    results = built_statistics(measures, CONFIGURATION)
  File "./ctop", line 360, in built_statistics
    'tasks': len(data['tasks']),
KeyError: 'tasks'

I run it on OpenVZ nodes, if this is important.
PS And terminal size 211x56 symbols.
My height in 56 is limit for me now?

Path to which

Hello!
Not all distributive have alias /bin/which .
As example in Centos 6 -

 LANG=C LC_ALL=C ls -l /bin/which /usr/bin/which
ls: cannot access /bin/which: No such file or directory
-rwxr-xr-x 1 root root 20768 Sep 23  2011 /usr/bin/which

As result ctop start failed with

./ctop_orig 
Traceback (most recent call last):
  File "./ctop_orig", line 46, in <module>
    HAS_LXC = cmd_exists('lxc-start')
  File "./ctop_orig", line 44, in cmd_exists
    return subprocess.call(["/bin/which",  cmd], stdout=subprocess.PIPE, stderr=subprocess.PIPE) == 0
  File "/usr/lib64/python2.6/subprocess.py", line 478, in call
    p = Popen(*popenargs, **kwargs)
  File "/usr/lib64/python2.6/subprocess.py", line 642, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.6/subprocess.py", line 1234, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

until the path to which will not be changed manually

Trying to run

I just tried to run ctop for the first time and upon execute i got this:
Traceback (most recent call last):
File "/usr/bin/ctop", line 4, in
cgroup_top.main()
File "/usr/lib/python2.7/site-packages/cgroup_top.py", line 782, in main
curses.curs_set(0) # hide cursor
_curses.error: curs_set() returned ERR

----> cat /proc/cgroups

subsys_name hierarchy num_cgroups enabled

cpuset 6 36 1
cpu 2 161 1
cpuacct 2 161 1
memory 4 161 1
devices 7 36 1
freezer 5 36 1
net_cls 8 36 1
blkio 9 161 1
perf_event 3 3 1
hugetlb 10 36 1

----> mount | grep group
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)

Not sure where to go from here

No visible docker container on Jessie

Not sure if it's a bug but here is the behavior I get

Boot the host on Debian Jessie (using systemd).
Run ctop. No cgroup visible, just /.
Launch a docker container.
Check ctop. Two main groups appeared, all related to systemd (system.slice and user.slice) but nothing about the docker container.

yadutaf / ctop Goto Github PK

ctop's People

Contributors

Stargazers

Watchers

Forkers

ctop's Issues

subsys_name hierarchy num_cgroups enabled

Recommend Projects

Recommend Topics

Recommend Org