On Sun, Jan 08, 2017 at 10:47:28AM -0800, Damian Johnson wrote:

Hi Alan, what linux distribution is this with? The only platform I'm aware of having issues with the uptime is OpenBSD. This is because the uptime requires parsing ps output and on that sole platform they show it in 12-hour local time with am/pm indicators, and a format that shifts if over a day (ie. a true parsing pita :P).

Does it use `ps -o etime`? If so it should work in the latest OpenBSD release.

On Thu, Jan 12, 2017 at 10:43:25AM -0800, Damian Johnson wrote:

...

Does it use `ps -o etime`? If so it should work in the latest OpenBSD release.

Yup, I use...

ps -p <pid> -o etime

Glad to hear it should now work on OpenBSD! To confirm would you mind providing me the output of that command for some arbitrary process on your OpenBSD system? I can add that to our unit tests just to be sure things are happy.

Oops, no it won't work in the latest release, it should work in -current (since September) and in the next release (in March, I think). Sorry, I remembered the patch going in earlier than it did.

It looks like this:

$ ps -p 98179 -o etime ELAPSED 01:29:49

Or, if running for more than 24 hours:

$ ps -p 16023 -o etime ELAPSED 6-17:41:19

changelog: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/ps/print.c?f=h#rev1.69

-- Carlin

Yes I have this exact problem aswell

I have a similar problem, arm does not show uptime and the average bandwidth rate is way to high. When I start arm I get a log entry that looks like this: "20:37:54 [ARM_NOTICE] Read the last day of bandwidth history from the state file (21 minutes is missing)" The time varies, sometimes it is even negative. The operation system is Fedora 25, with arm 1.4.5.0

Greetings, Simon Fischer.

On Sun, 2017-01-08 at 10:47 -0800, Damian Johnson wrote:

...

Hi Alan, what linux distribution is this with? The only platform I'm aware of having issues with the uptime is OpenBSD. This is because the uptime requires parsing ps output and on that sole platform they show it in 12-hour local time with am/pm indicators, and a format that shifts if over a day (ie. a true parsing pita :P).

Cheers! -Damian

On 1/8/17, Alan tor-relay@clutterbuck.uk wrote:

...

I have 3 relays running but on Arm only one shows the uptime. Also the Averages it keeps are way off.

Alan.

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays____________...

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Just to confirm - I see the same issue (Debian). So arm is only partially useful (not being really reliable) but I think it's not maintained anymore (?). I was looking into theonionbox for status reporting but that one also needs further development before becoming a reliable tool for monitoring...

Am 09.01.2017 10:27 schrieb Norman Rieß:

Same on plain old Debian.

Norman

Am 08.01.2017 um 21:34 schrieb Alan:

...

Yes I have this exact problem aswell

...

I have a similar problem, arm does not show uptime and the average bandwidth rate is way to high. When I start arm I get a log entry that looks like this: "20:37:54 [ARM_NOTICE] Read the last day of bandwidth history from the state file (21 minutes is missing)" The time varies, sometimes it is even negative. The operation system is Fedora 25, with arm 1.4.5.0

Greetings, Simon Fischer.

On Sun, 2017-01-08 at 10:47 -0800, Damian Johnson wrote:

...

Hi Alan, what linux distribution is this with? The only platform I'm aware of having issues with the uptime is OpenBSD. This is because the uptime requires parsing ps output and on that sole platform they show it in 12-hour local time with am/pm indicators, and a format that shifts if over a day (ie. a true parsing pita :P).

Cheers! -Damian

On 1/8/17, Alan tor-relay@clutterbuck.uk wrote:

...

I have 3 relays running but on Arm only one shows the uptime. Also the Averages it keeps are way off.

Alan.

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays____________...

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Missed the important bit - its the same for ubuntu 16 and 14 - no uptime and other stats out

Cheers Mark B Snaptor.co.uk (non commercial)

On 9 Jan 2017, at 11:15, Sec INT sec.int9@gmail.com wrote:

I just use webmin and cluster all relays - it has uptime monitors and various alerts you can set - the cluster cron job is useful for regular updating and clearing house plus executing one off commands on all servers e.g. Updating myfamily row

Vnstat for stats and graphs although cactus is a good tool also

Easier than Zabbix...

Cheers Mark B Snaptor.co.uk (non commercial)

...

On 9 Jan 2017, at 10:08, mistral.relay@posteo.net wrote:

Just to confirm - I see the same issue (Debian). So arm is only partially useful (not being really reliable) but I think it's not maintained anymore (?). I was looking into theonionbox for status reporting but that one also needs further development before becoming a reliable tool for monitoring...

Am 09.01.2017 10:27 schrieb Norman Rieß:

...

Same on plain old Debian. Norman

...

...

Am 08.01.2017 um 21:34 schrieb Alan: Yes I have this exact problem aswell I have a similar problem, arm does not show uptime and the average bandwidth rate is way to high. When I start arm I get a log entry that looks like this: "20:37:54 [ARM_NOTICE] Read the last day of bandwidth history from the state file (21 minutes is missing)" The time varies, sometimes it is even negative. The operation system is Fedora 25, with arm 1.4.5.0 Greetings, Simon Fischer.

...

On Sun, 2017-01-08 at 10:47 -0800, Damian Johnson wrote: Hi Alan, what linux distribution is this with? The only platform I'm aware of having issues with the uptime is OpenBSD. This is because the uptime requires parsing ps output and on that sole platform they show it in 12-hour local time with am/pm indicators, and a format that shifts if over a day (ie. a true parsing pita :P). Cheers! -Damian > On 1/8/17, Alan tor-relay@clutterbuck.uk wrote: > I have 3 relays running but on Arm only one shows the uptime. Also > the > Averages it keeps are way off. > Alan. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays____________...

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

I just installed theonionbox again yesterday. What I think could be done easier is the actual installtion - just via apt so e.g. updates are applied automatically. Would be also great to have it set-up as daemon via apt or otherwise easily (I didn't managed to do so yet). For a quick check I think some stats about number of connections is missing. Generally, it would be great to have some more history data (I'm rather interested how the relay performed over the past weeks, months, years), however this would require some db-storage I assume (not that easy to implement). Currently, I use vnstat(i) for general (i.e. not directly tor) nw usage stats. I've also noticed that the webpage puts a high load on the browser (probably coming from real-time cpu- and heat-charts). Regarding cpu- and heat: I personally would be again rather interested in trends and historical data than in real-time But definitely a nice thing to have theonionbox; great work and many thanks!

Am 09.01.2017 19:35 schrieb Ralph Wetzel:

Hi! Thank you for your feedback regarding The Onion Box. What do you think might be mandatory - from your point of view - to be implemented for the Box to become 'a reliable tool for monitoring'? Best regards, Ralph

GESENDET: Montag, 09. Januar 2017 um 11:08 Uhr VON: mistral.relay@posteo.net AN: tor-relays@lists.torproject.org BETREFF: Re: [tor-relays] Uptime missing from Arm Just to confirm - I see the same issue (Debian). So arm is only partially useful (not being really reliable) but I think it's not maintained anymore (?). I was looking into theonionbox for status reporting but that one also needs further development before becoming a reliable tool for monitoring...

Am 09.01.2017 10:27 schrieb Norman Rieß:

...

Same on plain old Debian.

Norman

Am 08.01.2017 um 21:34 schrieb Alan:

...

Yes I have this exact problem aswell

...

I have a similar problem, arm does not show uptime and the average bandwidth rate is way to high. When I start arm I get a log entry that looks like this: "20:37:54 [ARM_NOTICE] Read the last day of bandwidth history

from

...

...

...

the state file (21 minutes is missing)" The time varies, sometimes it is even negative. The operation system is Fedora 25, with arm 1.4.5.0

Greetings, Simon Fischer.

On Sun, 2017-01-08 at 10:47 -0800, Damian Johnson wrote:

...

Hi Alan, what linux distribution is this with? The only platform

I'm

...

...

...

...

aware of having issues with the uptime is OpenBSD. This is

because

...

...

...

...

the uptime requires parsing ps output and on that sole platform they show it in 12-hour local time with am/pm indicators, and a format

that

...

...

...

...

shifts if over a day (ie. a true parsing pita :P).

Cheers! -Damian

On 1/8/17, Alan tor-relay@clutterbuck.uk wrote:

...

I have 3 relays running but on Arm only one shows the uptime.

Also

...

...

...

...

...

the Averages it keeps are way off.

Alan.

---

tor-relays mailing list tor-relays@lists.torproject.org

https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays____________... [1]

...

...

...

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[2]

...

...

...

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[2]

...

...

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[2] _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays [2]

Links:

[1] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays____________... [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

but I think it's not maintained anymore (?).

Hi mistral. That is incorrect, I'm the maintainer. arm's last release was a long time ago and it indeed has quite a few issues. I've been rewriting it from the ground up and that's Nyx...

https://gitweb.torproject.org/nyx.git

Nyx is feature complete (that is to say it does everything arm does and more). I just haven't cut a release yet because there's still some troublesome curses issues to sort out.

Cheers! -Damian

Thx Damian for this ! Please you give some useful commands to install and use it ?

I'll be happy to try your tool! Many thx :)

% git clone https://git.torproject.org/stem.git % cd stem % sudo python setup.py install % cd ..

% git clone https://git.torproject.org/nyx.git % cd nyx % sudo python setup.py install

Hi Arisbe, glad it's working for ya! Nyx should have file descriptor counts if you're using more than 60% and there's room for it in the header. For what it's worth here's the relevant bits...

https://gitweb.torproject.org/nyx.git/tree/nyx/panel/header.py#n407 https://gitweb.torproject.org/nyx.git/tree/nyx/panel/header.py#n243

Cheers! -Damian

On Fri, Jan 13, 2017 at 2:06 PM, Arisbe arisbe@cni.net wrote:

Thanks for the effort to improve Arm (now Nyx). I've only tried NYX with the default config file but I don't see the file descriptors enabled. Did we lose this data?

arisbe

On 1/13/2017 11:43 AM, Damian Johnson wrote:

...

...

Thx Damian for this ! Please you give some useful commands to install and use it ?

I'll be happy to try your tool! Many thx :)

% git clone https://git.torproject.org/stem.git % cd stem % sudo python setup.py install % cd ..

% git clone https://git.torproject.org/nyx.git % cd nyx % sudo python setup.py install _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

On 01/16/2017 11:07 AM, Petrusko wrote:

To resume, So it's working by cloning the git repository as you wrote. chown -R debian-tor:debian-tor * inside folders /stem and /nyx

Then (relay with default control socket) cd nyx sudo -u debian-tor ./run_nyx

This (or just "nyx") yields: Unable to connect to tor. Are you sure it's running?

OR (relay with control port, here example 9053) sudo -u debian-tor ./run_nyx -i 9053

This yields: Unable to connect to 127.0.1:9053: [Errno 111] Connection refused.

Errno being a Muppet previously unknown to me.

arm does not show uptime and the average bandwidth rate is way to high.

This is because tor changed the format of its state file since arm's last release, causing the prepopulated values to be inaccurate. The current codebase (nyx) uses a new capability of tor's control port to provide much better graph prepopulation as you already observed.

Damian, Milkyway (which is working) is using Centos 6 Andromeda is using Centos 7 and TheCosmos uses a raspberry pi 2, so Raspbian

Interesting. Maybe that platform has a subtly different format than what I expect. Mind running the following for an arbitrary process and telling me the output?

ps -p <pid> -o etime

Nyx uses /proc to get this information too but that's platform specific, so ps is used as the more universal fallback.

From MilkyWay: [root@clutterbuck ~]# ps -p 23780 -o etime ELAPSED 78-14:14:25

Hope that helps.

Thanks Alan. All of those are indeed what Stem expects. If you run the Nyx codebase instead does the uptime show up? Please note you'll need to fetch both it and stem from the git repos...

git clone https://git.torproject.org/nyx.git git clone https://git.torproject.org/stem.git