arm does not show uptime

added component::archived/nyx owner::atagar priority::medium reporter::drforbin resolution::fixed status::closed type::defect uptime labels

Hi drforbin. What OS are you running?

Trac:
Status: new to needs_information

I'm running archlinux kernel Linux gamma 3.4.9-gentoo #1 SMP PREEMPT Mon Sep 10 20:45:11 EDT 2012 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux

thanxs

Trac:
Username: drforbin

Hmm. OpenBSD has a known issue with the uptime but I'm not aware of one with Archlinux. What does you ps output for the following look like?

ps -p TOR_PID -o cputime,etime,rss,%%mem

Also, please run 'arm --debug' and provide '~/.arm/log' on pastebin (minus anything you consider to be private).

Trac:
Username: drforbin

log

Trac:
Username: drforbin

I assume you mean ps -p TOR_PID -o cputime,etime,rss,%mem not ps -p TOR_PID -o cputime,etime,rss,%%mem

here is return

TIME ELAPSED RSS %MEM 00:01:22 14:38:37 55208 5.7

Trac:
Username: drforbin

Hm, the plot thickens...

I assume you mean ps -p TOR_PID -o cputime,etime,rss,%mem not ...

Oops, you're right. Copied the formatted string and forgot the escape.

attachment log...

Here's the interesting bits...

9/16/2012 19:05:18 [DEBUG] Unable to query process resource usage from proc (stat file had an unexpected format: /proc/1804/stat)
9/16/2012 19:05:19 [INFO] Failed three attempts to get process resource usage from proc, falling back to ps (stat file had an unexpected format: /proc/1804/stat)
9/16/2012 19:05:19 [DEBUG] system call: ps -p 1804 -o cputime,etime,rss,%mem (runtime: 0.02)

So it's indeed using ps rather than the proc contents, and isn't reporting any issues.

here is return TIME ELAPSED RSS %MEM 00:01:22 14:38:37 55208 5.7

That certainly looks like what I get...

atagar@morrigan:~$ ps -p 1563 -o cputime,etime,rss,%mem
    TIME     ELAPSED   RSS %MEM
00:04:33       52:02 165256 16.2

... and the util looks like it should be happy with it...

>>> import util.uiTools
>>> util.uiTools.parseShortTimeLabel("14:38:37")
52717

My theory is that the following is happening...

When the header panel first starts up it fetches static attributes (things that it only needs once). This includes tor's start time.
We see that a proc file exists, so try to use it to get the start time rather than ps. This fails (as mentioned in the log) and we cache the failed 'None' result in the header panel.

To test this theory please make a text file with...

queries.useProc false

... then run arm with 'arm --config /path/to/that/file'. If the uptime now appears then this is indeed the bug.

Thanks for the catch! -Damian

That's got it.....Good call man:) I assume setting that option to false disables proc use right? adds overhead?

Trac:
Username: drforbin

Great! Fix pushed... https://gitweb.torproject.org/arm.git/commitdiff/74567bb166c68584e3d1459f98e1ea08d09927c3

I assume setting that option to false disables proc use right?

Yup. The log entries I mentioned earlier tell us that it's trying to query your proc contents but fails, and after three tries it gives up. This config option tells arm to skip trying to query proc in the first place.

adds overhead?

This config option doesn't add any overhead (it just makes you skip some queries that are doomed to fail anyway). However, our inability to use the proc contents does add a little overhead. Reading proc is around 10x faster and less resource intensive than needing to shell out. That said, making periodic ps queries really isn't heavy at all.

Cheers! -Damian

Trac:
Status: needs_information to closed
Resolution: N/A to fixed

closed

arm does not show uptime

Child items ...

Activity