service/daemon for tool

[palica]

with the ability to send reports after certain system events like start, poweroff, ego sync, emerge ...

with showing the reason of the submission

funtoo-report: reason : "system started" funtoo-report: reason : "ego sync run" ...

[tejr]

As discussed on IRC I am personally a little wary of the boot/shutdown/uptime part, because I'm concerned it exposes a little too much potentially identifying information about the computer without much actual benefit. I will help if everyone else agrees it's good, but I wonder if that is actually useful information?

I see no problems with counting the number of ego sync runs though, but I don't think that necessitates making the script into a daemon. My understanding is that there's a feature request in Funtoo itself to start keeping a file counter of ego statistics? If this is the case, all we should have to do is check such statistics on each run.

I think this is one of the cases where the other three developers will have a much better idea of what's desirable than I will, not being a dedicated Funtoo user.

[haxmeister]

I think @ShadowM00n was opposed to the idea. These are some of the reasons I considered such a thing in the first place.

Currently a person must set it as a cron job or launch it manually. This means that most submissions will reflect no change at all and will just be a waste of bandwidth and server capacity. A daemon would have the ability to only report when there have been changes to the stat in some way.. ie.. the user updates funtoo, or adds/changes a pci device.

It also would allow the user to set it off with a single command and forget about it. Not all funtoo installs have a cron daemon (it is not even mentioned in the install instructions. nor is it in the stage3 tarball), but all do have an init system. A daemon would allow someone to automate the tool without writing a script or installing a cron.

Daemonizing the tool is not a change to current methods for operating the tool, rather it is an additional way to operate the tool. .. perhaps funtoo-report --Daemon

This would also allow us to measure stats that drobbins has an interest in, without actually waiting on him to implement it in the funtoo code. A daemon could in fact track syncs per day and the reporting tool is really the tool that should be doing that kind of stat checking.

I'm saying all this because there seems to be some misunderstanding of my thinking. However I'm not dead set on the idea, it was after all just an idea to "run by the guys". The level of opposition tells me it's not a good idea and I'm inclined to listen to my peers on such things.

[tejr]

Such a daemon would have to be written with reliable hooks to watch every system event and fire a new report each time something it deems significant changes. That sounds like it would be hugely complicated, and quite a lot of work.

This means that most submissions will reflect no change at all and will just be a waste of bandwidth and server capacity.

Do we know how well the ElasticSearch server will scale? The submissions are small in the grand scheme of things, but if there are thousands of them, and they each take a second to process...

We can of course spread the load out with some simple logic so that we don't have 1,000 reports on the dot every six hours. Let's Encrypt's certbot cron job uses a simple sleep trick to randomly stagger renewals, for example, for exactly this reason:

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

[palica]

I deleted the indices so now have only part of the data that we had before

yellow open funtoo-2018.11 _gqgw7dsRYWqejCz65Q5rw 5 1 126 0 7.3mb 7.3mb

as far as ES I can launch another instance and ES will scale on it self and manage the cluster on its own.

[palica]

I liked the idea of a daemon, but if it is not a good one we can skip it. Going to add instructions how to add cronjob to ebuild elog

[tejr]

Making it run as a daemon is not in itself a bad idea at all. What I'm not sure about is how exactly we'd make it work.

I reckon a lot of software like this must eventually run into the "scheduled task or persistent process?" debate!

[haxmeister]

I'm going to close this issue ... should it seem like a good idea at another date, we can revisit this.