Opened 5 years ago

Closed 5 years ago

#6862 closed defect (fixed)

arm does not show uptime

Reported by: drforbin Owned by: atagar
Priority: Medium Milestone:
Component: Core Tor/Nyx Version:
Severity: Keywords: uptime
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I saw other ticket which put this down to not running under tor account. I am running under tor account and have also tried under root. I think the ps command is not being parsed properly.

thanxs

Child Tickets

Attachments (1)

log (52.7 KB) - added by drforbin 5 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 5 years ago by atagar

Status: newneeds_information

Hi drforbin. What OS are you running?

comment:2 Changed 5 years ago by drforbin

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

comment:3 Changed 5 years ago by atagar

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).

Changed 5 years ago by drforbin

Attachment: log added

comment:4 Changed 5 years ago by 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

comment:5 Changed 5 years ago by atagar

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

comment:6 Changed 5 years ago by drforbin

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

comment:7 Changed 5 years ago by atagar

Resolution: fixed
Status: needs_informationclosed

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

Note: See TracTickets for help on using tickets.