moonlitSpider
commented
8 years ago Hmm...perhaps not systemd related. After all, Ubuntu 16.04 is systemd-based and things work there.
Closed moonlitSpider closed 8 years ago
moonlitSpider
commented
8 years ago Hmm...perhaps not systemd related. After all, Ubuntu 16.04 is systemd-based and things work there.
sebhildebrandt
commented
8 years ago Hi Paul,
Thank you for reporting this bug. Yes, this is new to me so I need to "dive" into it tomorrow. If I have any further questions, is it ok to ask you for details??
Sebastian
Am 27.10.2016 um 15:52 schrieb moonlitSpider notifications@github.com:
Hmm...perhaps not systemd related. After all, Ubuntu 16.04 is systemd-based and things work there.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
moonlitSpider
commented
8 years ago Hi Sebastian,
Absolutely fine to ask further questions!
I will also later today confirm my findings. I'm pretty sure I did things "right", but will double-check. I don't want to waste your time.
Cordially,
Paul
On Oct 27, 2016, at 12:29 PM, "Sebastian Hildebrandt" notifications@github.com<mailto:notifications@github.com> wrote:
Hi Paul,
Thank you for reporting this bug. Yes, this is new to me so I need to "dive" into it tomorrow. If I have any further questions, is it ok to ask you for details??
Sebastian
Am 27.10.2016 um 15:52 schrieb moonlitSpider notifications@github.com<mailto:notifications@github.com>:
Hmm...perhaps not systemd related. After all, Ubuntu 16.04 is systemd-based and things work there.
You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/sebhildebrandt/systeminformation/issues/13#issuecomment-256697363, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQ8fDhC01npkLR-vYnmRnsE7U5qLvzjbks5q4NFigaJpZM4KiPkM.
CATALOGIC SOFTWARE, ATTENTION::----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Catalogic Software. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Catalogic Software and destroy all copies of this message in your possession, custody or control.
moonlitSpider
commented
8 years ago Hi Sebastian,
I double-checked. Shell output below.
Thank you for your work on this; and thanks again for 'si'!
-Paul
rpm --query centos-release
centos-release-7-2.1511.el7.centos.2.10.x86_64
[root@71 ecomon]# node
> var si = require('systeminformation');
> si.dockerContainers('all', function(d) { console.log(d); })
Promise { <pending> }
> []
> si.dockerContainerStats('e6fd6dc70289', function(d) { console.log(d); })
Promise { <pending> }
> { id: 'e6fd6dc70289',
mem_usage: 0,
mem_limit: 0,
mem_percent: 0,
cpu_percent: 0,
pids: 0,
netIO: { rx: 0, wx: 0 },
blockIO: { r: 0, w: 0 } }
> si.dockerAll( function(d) { console.log(d); })
Promise { <pending> }
> []
Hi Paul,
Thank you for double checking again! Under the hood I do the following: I am calling the official docker API to get the information and I do pretty much the same in si.dockerContainers and si.dockerContainerStats. So this is a little bit strange to me right now.
Can you check the output of the following two commands on the command line in CentOS 7 as well as CentOS6?:
curl --unix-socket /var/run/docker.sock http:/containers/json?all=1
curl --unix-socket /var/run/docker.sock http:/containers/e6fd6dc70289/stats?stream=0The value in the second command after "/containers/" should be the ID of one of your containers.
Can you also provide the following on both systems (also command line)?
node -v
docker versionThank you so much for your support to improve this package! Sebastian
moonlitSpider
commented
8 years ago Hi Sebastian,
Sorry for the delayed reply.
In reviewing my work on this, it's clear that some of what I said was confused. In fact, I am not even running Docker on CentOS 6! Consequently, the comparison is between Ubuntu 16.04 and CentOS 7. That said, the behavior I described above for these 2 systems is accurate.
On both (CentOS 7, Ubuntu 16.04) systems:
[root@localhost ~]# node -v
v6.2.1On the Ubuntu system:
root@pbUbuntu1604:/home/ecxcc/ecomon# docker version
Client:
Version: 1.12.1
API version: 1.24
Go version: go1.6.3
Git commit: 23cf638
Built: Thu Aug 18 05:33:38 2016
OS/Arch: linux/amd64
Server:
Version: 1.12.1
API version: 1.24
Go version: go1.6.3
Git commit: 23cf638
Built: Thu Aug 18 05:33:38 2016
OS/Arch: linux/amd64On the CentOS system:
[root@71 ~]# docker version
Client:
Version: 1.11.2
API version: 1.23
Go version: go1.5.4
Git commit: b9f10c9
Built: Wed Jun 1 21:23:11 2016
OS/Arch: linux/amd64
Server:
Version: 1.11.2
API version: 1.23
Go version: go1.5.4
Git commit: b9f10c9
Built: Wed Jun 1 21:23:11 2016
OS/Arch: linux/amd64As to the curl command, it appears that the --unix-socket argument was introduced in curl 7.40. I am having some difficulty upgrading to this version. More later.
-Paul
moonlitSpider
commented
8 years ago OK, on the Ubuntu system the two curl commands produce meaningful output from Docker. But I am still working on upgrading the CentOS 7 version of curl.
-Paul
sebhildebrandt
commented
8 years ago Hi, thank you for your input! Well, before upgrading curl: it would be super, if I can find a workaround with exact this older version of curl. Maybe you are not the only one who has this installed and it should work also with older versions ;-) My suggestion: I will make a research on what I can modify and if I have a solution, you can test it without having to upgrade curl. What do you think?
Thank you in advance
moonlitSpider
commented
8 years ago Fine by me, Sebastian; happy to help.
While we're at it.....I was wondering about an enhancement to si's docker API. Might it be possible to get a list of the processes that are running inside a container, ideally along with their external (host) PIDs and internal (container) PIDs?
One way I could do this might be via the Node package dockerode's exec interface to Docker, e.g., 'docker exec CTRID ps aux'. )
But if you are amenable to implementing such an API in si, I will open a separate issue for this.
Thanks.
-Paul
sebhildebrandt
commented
8 years ago Fine! I will contact you as soon as I have a possible solution for the "curl" problems.
"Inside Docker" Processes - I will add this to my todo-list! nice idea! No need to open an issue for that ;-)
sebhildebrandt
commented
8 years ago Hi again. It is pretty much clear, that there are workarounds to the curl problem. The only thing is, that I do not want to add dependencies, so I do have to write a little bit more code. Hope that it is OK to have a little delay in solving this problem.
moonlitSpider
commented
8 years ago Hi Sebastian,
Absolutely fine, please take your time.
My chief concern in all of this is getting systeminformation to behave (WRT Docker containers) on CentOS 7 the way it behaves on Ubunutu 16.04.
Thanks again.
-Paul
sebhildebrandt
commented
8 years ago Hi Paul,
I worked on a workaround (not relying on curl), and maybe you can test the following GIST:
https://gist.github.com/sebhildebrandt/19aabd5d0068e438deae69993e00a696
Here you have 2 files. In the file testDocker.js, you need to edit the ID if the container you would like to have statistics for (line 13). Then just fire it with node testDocker
If you get reasonable results on your different machines, this could be the solution. If you see any errors, it would be nice to post the results. Thank you for any feedback.
moonlitSpider
commented
8 years ago Hi Sebastian,
Wow; this looks very promising; thanks very much!
I've tested the gist. I do not presently have an account there, so please forgive this lengthy paste (see below). I've prefixed my comments about the output with a pound sign.
Observations:
Cordially,
Paul
# Via si on CentOS 7
> si.dockerContainerStats('401187a942f6', function(d) { console.log(d); })
Promise { <pending> }
> { id: '401187a942f6',
mem_usage: 0,
mem_limit: 0,
mem_percent: 0,
cpu_percent: 0,
pids: 0,
netIO: { rx: 0, wx: 0 },
blockIO: { r: 0, w: 0 } }
# Via testDocker and dockerSocket.js on CentOS 7
node testDocker.js
STATS -----------------------------------------------------
{
"read": "2016-11-01T19:56:59Z",
"precpu_stats": {
"cpu_usage": {
"total_usage": 793184083252,
"percpu_usage": [
133109152089,
221194004162,
207449233588,
231431693413
],
"usage_in_kernelmode": 354850000000,
"usage_in_usermode": 250000000000
},
"system_cpu_usage": 1060050550000000,
"throttling_data": {
"periods": 0,
"throttled_periods": 0,
"throttled_time": 0
}
},
"cpu_stats": {
"cpu_usage": {
"total_usage": 793190314248,
"percpu_usage": [
133109582265,
221198367784,
207449233588,
231433130611
],
"usage_in_kernelmode": 354860000000,
"usage_in_usermode": 250000000000
},
"system_cpu_usage": 1060054530000000,
"throttling_data": {
"periods": 0,
"throttled_periods": 0,
"throttled_time": 0
}
},
"memory_stats": {
"usage": 84111360,
"max_usage": 85434368,
"stats": {
"active_anon": 39419904,
"active_file": 1081344,
"cache": 44593152,
"hierarchical_memory_limit": 9223372036854776000,
"hierarchical_memsw_limit": 9223372036854776000,
"inactive_anon": 0,
"inactive_file": 43511808,
"mapped_file": 11603968,
"pgfault": 38729892,
"pgmajfault": 31,
"pgpgin": 205626,
"pgpgout": 194306,
"rss": 39448576,
"rss_huge": 37748736,
"swap": 0,
"total_active_anon": 39419904,
"total_active_file": 1081344,
"total_cache": 44593152,
"total_inactive_anon": 0,
"total_inactive_file": 43511808,
"total_mapped_file": 11603968,
"total_pgfault": 38729892,
"total_pgmajfault": 31,
"total_pgpgin": 205626,
"total_pgpgout": 194306,
"total_rss": 39448576,
"total_rss_huge": 37748736,
"total_swap": 0,
"total_unevictable": 0,
"unevictable": 0
},
"failcnt": 0,
"limit": 16596185088
},
"blkio_stats": {
"io_service_bytes_recursive": [
{
"major": 8,
"minor": 0,
"op": "Read",
"value": 16384
},
{
"major": 8,
"minor": 0,
"op": "Write",
"value": 3279721472
},
{
"major": 8,
"minor": 0,
"op": "Sync",
"value": 3279721472
},
{
"major": 8,
"minor": 0,
"op": "Async",
"value": 16384
},
{
"major": 8,
"minor": 0,
"op": "Total",
"value": 3279737856
},
{
"major": 253,
"minor": 0,
"op": "Read",
"value": 16384
},
{
"major": 253,
"minor": 0,
"op": "Write",
"value": 3279721472
},
{
"major": 253,
"minor": 0,
"op": "Sync",
"value": 3279721472
},
{
"major": 253,
"minor": 0,
"op": "Async",
"value": 16384
},
{
"major": 253,
"minor": 0,
"op": "Total",
"value": 3279737856
},
{
"major": 7,
"minor": 0,
"op": "Read",
"value": 24576
},
{
"major": 7,
"minor": 0,
"op": "Write",
"value": 0
},
{
"major": 7,
"minor": 0,
"op": "Sync",
"value": 0
},
{
"major": 7,
"minor": 0,
"op": "Async",
"value": 24576
},
{
"major": 7,
"minor": 0,
"op": "Total",
"value": 24576
},
{
"major": 253,
"minor": 2,
"op": "Read",
"value": 24576
},
{
"major": 253,
"minor": 2,
"op": "Write",
"value": 0
},
{
"major": 253,
"minor": 2,
"op": "Sync",
"value": 0
},
{
"major": 253,
"minor": 2,
"op": "Async",
"value": 24576
},
{
"major": 253,
"minor": 2,
"op": "Total",
"value": 24576
},
{
"major": 253,
"minor": 7,
"op": "Read",
"value": 44849152
},
{
"major": 253,
"minor": 7,
"op": "Write",
"value": 0
},
{
"major": 253,
"minor": 7,
"op": "Sync",
"value": 0
},
{
"major": 253,
"minor": 7,
"op": "Async",
"value": 44849152
},
{
"major": 253,
"minor": 7,
"op": "Total",
"value": 44849152
}
],
"io_serviced_recursive": [
{
"major": 8,
"minor": 0,
"op": "Read",
"value": 4
},
{
"major": 8,
"minor": 0,
"op": "Write",
"value": 500998
},
{
"major": 8,
"minor": 0,
"op": "Sync",
"value": 500998
},
{
"major": 8,
"minor": 0,
"op": "Async",
"value": 4
},
{
"major": 8,
"minor": 0,
"op": "Total",
"value": 501002
},
{
"major": 253,
"minor": 0,
"op": "Read",
"value": 4
},
{
"major": 253,
"minor": 0,
"op": "Write",
"value": 500998
},
{
"major": 253,
"minor": 0,
"op": "Sync",
"value": 500998
},
{
"major": 253,
"minor": 0,
"op": "Async",
"value": 4
},
{
"major": 253,
"minor": 0,
"op": "Total",
"value": 501002
},
{
"major": 7,
"minor": 0,
"op": "Read",
"value": 4
},
{
"major": 7,
"minor": 0,
"op": "Write",
"value": 0
},
{
"major": 7,
"minor": 0,
"op": "Sync",
"value": 0
},
{
"major": 7,
"minor": 0,
"op": "Async",
"value": 4
},
{
"major": 7,
"minor": 0,
"op": "Total",
"value": 4
},
{
"major": 253,
"minor": 2,
"op": "Read",
"value": 4
},
{
"major": 253,
"minor": 2,
"op": "Write",
"value": 0
},
{
"major": 253,
"minor": 2,
"op": "Sync",
"value": 0
},
{
"major": 253,
"minor": 2,
"op": "Async",
"value": 4
},
{
"major": 253,
"minor": 2,
"op": "Total",
"value": 4
},
{
"major": 253,
"minor": 7,
"op": "Read",
"value": 772
},
{
"major": 253,
"minor": 7,
"op": "Write",
"value": 0
},
{
"major": 253,
"minor": 7,
"op": "Sync",
"value": 0
},
{
"major": 253,
"minor": 7,
"op": "Async",
"value": 772
},
{
"major": 253,
"minor": 7,
"op": "Total",
"value": 772
}
],
"io_queue_recursive": [],
"io_service_time_recursive": [],
"io_wait_time_recursive": [],
"io_merged_recursive": [],
"io_time_recursive": [],
"sectors_recursive": []
},
"pids_stats": {},
"networks": {
"eth0": {
"rx_bytes": 3282,
"rx_packets": 41,
"rx_errors": 0,
"rx_dropped": 0,
"tx_bytes": 648,
"tx_packets": 8,
"tx_errors": 0,
"tx_dropped": 0
}
}
}
END -- STATS ----------------------------------------------
# For purposes of comparison: 'docker stats' for the same container as above; CentOS 7
[root@71 ecomon]# nano testDocker.js
[root@71 ecomon]# docker stats 401187a942f6
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.27% 83.97 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.27% 83.97 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.28% 83.97 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.28% 83.97 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.29% 83.97 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.29% 83.97 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.31% 83.97 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.31% 83.97 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.31% 83.98 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.31% 83.98 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.29% 83.98 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.29% 83.98 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.28% 83.98 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.28% 83.98 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.31% 83.98 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.31% 83.98 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
401187a942f6 0.29% 83.98 MB / 16.6 GB 0.51% 3.282 kB / 648 B 44.93 MB / 6.553 GB 0
# Via si on Ubuntu 16.04.1
> si.dockerContainerStats('5d37a0c74341', function(d) {console.log(d)} )
Promise { <pending> }
>
> { id: '5d37a0c74341',
mem_usage: 72798208,
mem_limit: 16826970112,
mem_percent: 0.4326281411059536,
cpu_percent: 0.0038676910794075503,
pids: 19,
netIO: { rx: 1296, tx: 648 },
blockIO: { r: 0, w: 35332096 } }
Hi again, great that we have results on CentOS7 now. The purpose of this GIST is only to check, if I can connect to the socket and get data from the API. When this really works, I will put this INSTEAD of curl. The data processing and the data you get back from systeminformation will NOT change, so YES, you will have the same stats as you had before in systeminformation (hope this answers your question 1).
To make one more comment. The results you see from the GIST is, what the API gives back (the same as I got back with CURL). Only the method how I connect to the API is different. So to your question 2: this is the original data from docker :-)
And concerning 3.: thank you so much! Really appreciate your help here!
moonlitSpider
commented
8 years ago Understood, thanks.
Some of that 'raw' Docker info is quite cool, errr...I mean useful. Might it be possible through si's API to request it, e.g., a flag that says 'include the raw data'?
And concerning 3, please, no thanks are necessary. I am delighted & grateful to have found systeminformation and am only too happy to help.
-Paul
sebhildebrandt
commented
8 years ago Concerning list of processes inside Docker:
... ideally along with their external (host) PIDs and internal (container) PIDs?
I am working on this already but discovered one problem: it seems to be difficult to get the host PID AND the containers PID at the same time. From the API I do get the host PID and when running docker exec I get the containers PID (starting with 1) ... hmmmm (I tried all parameters)
I need to make a decision, which way to go. To be consistent with the other stats, I would like to work with the API (which means only having the host PID).
What do you think?
moonlitSpider
commented
8 years ago Hi Sebastian,
Yeah, I think host PID is sufficient.
As you doubtless know, the origin 1 PIDs within the container belong to its pid_namespace. Realistically, they're probably not of that much use.
Thanks.
-Paul
sebhildebrandt
commented
8 years ago Just updated systeminformation ...
Docker process information will follow in the next few days. Will close this issue for now, OK?
moonlitSpider
commented
8 years ago Beautiful; thanks.
I'll give it a spin over next day or two.
-pb
From: Sebastian Hildebrandt notifications@github.com Sent: Wednesday, November 2, 2016 7:27:12 AM To: sebhildebrandt/systeminformation Cc: Bell, Paul; Author Subject: Re: [sebhildebrandt/systeminformation] CentOS 7 problems (#13)
Just updated systeminformation ...
Docker process information will follow in the next few days. Will close this issue for now, OK?
You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/sebhildebrandt/systeminformation/issues/13#issuecomment-257838908, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQ8fDkQA4b_WO4BWAG5xjUwaDu8tWZVtks5q6HOQgaJpZM4KiPkM.
CATALOGIC SOFTWARE, ATTENTION::----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Catalogic Software. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Catalogic Software and destroy all copies of this message in your possession, custody or control.
sebhildebrandt
commented
8 years ago Me once again ...
I just released version 3.8 with a new function dockerContainerProcesses(id) which gives back all processes with detail information inside a specific container.
And: dockerAll() is also updated. Here you get an array of all containers including their stats and processes.
Hope this helps ... and feedback is welcome ;-)
paul-bell
commented
8 years ago That's terrific, Sebastian; thanks very much!
I will definitely try this out over the weekend and it will most definitely help.
-Paul
paul-bell
commented
8 years ago Hi Sebastian,
Very nice, and very helpful.
If I am interpreting the phenomena correctly, dockerAll has been enhanced to include a processes object (array) that shows metrics about the host processes running in the container. This array is also available by itself via the new dockerContainerProcesses API.
Thanks again!
-Paul
sebhildebrandt
commented
8 years ago dockerAll: yes you are absolutely right. dockerAll is just a convenient way of getting it all in one single step. All containers (including the stopped ones), their stats and processes.
One more thing: If you only need the docker part of systeminformation, I created a new npm module called dockerstats for that ;-)
Hi,
First, thank you very much for this fine piece of work! It's been a great help to me.
I was today experimenting with the several docker APIs offered by your module and it seems that two of them don't work in CentOS 7. I presume that this is perhaps more a systemd issue than anything else.
In response to, for example,
si.dockerContainers('all', function(d) { console.log(d); })I see:I get the same empty promise array in response to .dockerAll(cb). But .dockerContainerStats(ctrID, cb) seems to work fine.
All API calls work properly on CentOS 6 (and on Ubuntu 16.04).
Do these phenomena comport with your experience? If this is a valid new issue, is it something that can be fixed without too much work?
Thank you again.
Cordially,
Paul