No way to write to syslog or capture logs about xmr-stak-cpu HOT 13 CLOSED

What's the usecase for that? Most miners run the applications in screen or tmux.

from xmr-stak-cpu.

I run it as a service with systemd and it would be nice to see what's going on, with maybe a continuous report of the hashrate etc... :)

from xmr-stak-cpu.

I'm considering writing an extra verbose level that will dump the hashrate every minute. Personally I hate that, I guess that's what people are used to :).

I also run my miners as an auto-started sytemd service - except it starts a screen instance, which starts a shell script that makes sure that DHCP and Internet are a-ok, and then runs the miner.
If i want to check on the miner, i just ssh to the box and reattach.

from xmr-stak-cpu.

from xmr-stak-cpu.

I run under screen too, it works well.

More generally, I would think that by now we would have had a "standard" monitoring protocol that could be easily integrated into any type of miner. Each miner has their own method of logging and monitor and fail-over/retry (which is a bit annoying).

from xmr-stak-cpu.

Unless you start from a fresh codebase, there is significant inertia. Just look at how many BTC miners still do long polling on HTTP.

from xmr-stak-cpu.

Logging would be good, different modes of verbosity preferable. I'm having an issue where shares are rejected when the miner has been running for longer periods, would be nice to have more to go on.

from xmr-stak-cpu.

(This is not a trick question of some sort, I'm looking at the design usecase here)

When doing the design for logging monitors I reckoned that it will be best to log connection drops as a list (since in that case you want to know when and how long), and pool errors as a tally (since here the first question is - how many?).

What would you look for in the logs?

from xmr-stak-cpu.

from xmr-stak-cpu.

It does. Usual one would be something like "low difficulty share" meaning that there was some computing error and the hash result was wrong.

from xmr-stak-cpu.

this doesn't directly fall in to design usecase, but for remote debugging: -> when the miner is started by crontab, it seems to hog an extra cpu... I tried different number of threads, different schedulers (crontab, rc.local, systemd), different physical systems, and I can't figure out :( :( :( can't even figure out if the hashrate via cron is as the same as when ran via terminal. Any insight or help would be appreciated

from xmr-stak-cpu.

@suahnkim you can use screen to log, have you tried that?

Add this to your ~/.screenrc:

deflog on

from xmr-stak-cpu.

@dimecoin Thank you. Tried your suggestion => hashrate is 10 ~ 15 less for the cron job.

update: when I specify one less thread in the config.txt, the hashrate drops, but cron job still takes 1 more core than specified. :( :( :(

from xmr-stak-cpu.