if you want to confuse yourself with the full history of this, read #40 #93 #94 .
specifically #94 (comment)

@r00t- yeah I've skimmed over this before I posted. I don't think a foreground option makes sense - daemon: should be enough to control this. I think it's well understood behavior in the FOSS and Linux world.

@dmesser: i'm only trying to point out that the issue arises because vzlogger gives a different meaning to "daemon" - which may very well be a bug.

imho, it would make more sense to have a single ticket to fix the whole thing to conform to usual conventions, instead of single tickets demanding new features.

this would probably mean:

• remove "deamon" setting (default to true, warning/error if set to false?)
• add single-shot mode switch vzlogger should have a --one-time CLI switch #389
• add foreground mode switch Please add --foreground option #378

(i wonder if anybody actually ever uses daemon:false mode.)

Darf ich mich in deutsch dazugesellen? Ich fürchte mich sonst falsch auszudrücken.

Soweit ich mich erinnere ist der Umstand das vzlogger bei daemon:false nur einen Durchgang macht eigentlich ein Bug. Nebeneffekt ist dabei auch das keine Daten an die Middleware geschickt werden weil der Prozess zu früh abgebrochen wird.
Wurde aber zum Feature erklärt weil es für Diagnosezwecke nicht ganz unpraktisch ist. Und weil sich bislang noch keiner gefunden hat das eigentliche Problem zu beseitigen.

Gut möglich das ich was durcheinander bringe oder nicht ganz verstehe, also bitte nicht all zu viel Gewicht auf meine Schlussfolgerungen legen.

@r00t- I'd use daemon:false on any container platform where I would like the container orchestration platform to grab the logs from stdout and also tie the lifecycle of the vzlogger process to that of the container / pod.

Wofür brauchen wir egtl. foreground? Singleshot würde ja reichen um zu beweisen dass die Config funktioniert. Bliebe nur Singleshot („once“) als Option übrig.

Oder wir lassen das Daemon Verhalten einfach komplett weg- mache ich bei mbmd auch ohne dass es bisher jemand vermisst hätte...

Ich würde so eine "one-time"-Option gern nutzen, weil ich den Stromverbrauch nur 1x am Tag auslesen und loggen möchte.
daemon:false führte (in der Version 2019-01) wie oben beschrieben dazu, daß keine Daten an die Middleware geschickt werden und ist deshalb für meine Zwecke nicht zu gebrauchen.
In der aktuellen git-Version werden die Daten an die Middleware geschickt, aber vzlogger beendet sich nicht mehr.

Hast du mal mit entsprechend großer aggtime oder interval versucht?

Hast du mal mit entsprechend großer aggtime oder interval versucht?

Anstatt das per cron zu machen?
Mein "Problem" ist, daß der vzlogger permanent 2% CPU benötigt, wenn er läuft. Das würde er weiterhin tun, wenn ich die aggtime auf einen Tag setze.
Cron wäre ideal, um hier CPU-Leistung und damit Strom zu sparen :)

Ich hab das vzlogger-beendet-sich-nicht-Problem gelöst, indem ich ihn einfach bitte zu sterben:

In /etc/cron.daily/run-vzlogger-cron:

#!/bin/sh
# run vzlogger in cron mode (collect one data point) and end it
# unfortunately, cron mode is broken in vzlogger and we have to kill it afterwards
# https://github.com/volkszaehler/vzlogger/issues/389

/usr/local/bin/vzlogger -c /etc/vzlogger-cron.conf > /dev/null 2>&1 &
sleep 5
pkill -15 --exact vzlogger

Find ich jetzt nicht schlimm, aber ich frag mich wofür die 2% anfallen. Um was für einen Zähler geht es eigentlich? Sml? Den sollte man ja auch per interval auslesen können und dann egtl. agr keine Rechenleistung brauchen?

Ja, ist ein SML-Zähler.

Würde einen One-Shot mode auch begrüßen
Ich kann meinen Zähler nur etwa pro Stunde abrufen, da ich das ganze über einen ESP8266 mit Batterie über Ser2Net betreiben muss, da ich keine Steckdose im Zählerschrank habe.
Intervall wird wohl nicht funktionieren, da man das ziemlich exakt mit dem DeepSleep synchronisieren müsste.

Außerdem peilt vzlogger es nicht wenn der ESP offline ist und somit die Telnet Verbindung wegbricht.
Es wird im daemon mode dann keine neue aufgebaut.

Meine Idee war daher das der ESP selber den read Vorgang per MQTT triggert.

The readme file still tells me that there are two modes available: „can run as a daemon or via cron“. Obviously it’s not working at the moment.
Are there plans to make the cron mode running again or do I have to make a workaround? For me a single shot mode would also be perfect.

@juergen4mueller:
the documentation bug is also known already.
#94 (comment)

as you can see if you read the discussion, this issue is kind of deadlocked, with no developer picking it up for years.
i guess you have to live with what's there, or patch the code locally to behave as you require.
you are ofcourse also invited to send a merge-request with a possible fix, that might help to get this topic moving again.

(the trivial part of ditching "daemon" and adding foreground mode is now in #450 .)

single-shot mode is actually quite a bit more complex.

as pointed out in #389 (comment) , if we exit the reading thread(s),
we still somehow need to ensure that the logging thread uploads the data (and then exits).

also,
basically, only periodic meters (where vzlogger itself can choose the poll intervall) can be supported.
(s0/sml is 'periodic' only when sending a pullseq.)
for others we may get away with simply waiting for the first reading, but the time until that is received is undefined.
some meters would need very special handling.
for example, the s0 meter is not periodic, and it will, with the first reading, only output one impulse, which would be completely useless.
we would have to wait for the second reading, in which it at least calculates power.

for anybody feeling extremely adventurous, #450 has an implementation of single-shot mode now,
i tested this ONLY with protocol=random and api=null so far.
if you try anything else and it crashes or doesn't work, don't bother posting.

[~/vzlogger]$ ./src/vzlogger -c ./etc/vzlogger.conf.randomnull -f -1 -v 15
[Feb 22 03:56:25][main] vzlogger v0.8.0 based on heads/cleanup_runmodes-0-gfb0205f4a7 from Mon, 22 Feb 2021 03:48:28 +0100 started.
[Feb 22 03:56:25]       Start parsing configuration from ./etc/vzlogger.conf.randomnull
[Feb 22 03:56:25]       New meter initialized (protocol=random)
[Feb 22 03:56:25]       Identifier is not set. Set it to default value 'NilIdentifier'.
[Feb 22 03:56:25][chn0] New channel initialized (uuid=...1e5a66 api=null id=NilIdentifier)
[Feb 22 03:56:25][main] log level is 15
[Feb 22 03:56:25][main] local=0
[Feb 22 03:56:25]       Process not daemonized...
[Feb 22 03:56:25]       Opened logfile /tmp/vzloggerxxx.log
[Feb 22 03:56:25][push] No pushDataServer defined.
[Feb 22 03:56:25][]     ===> Start meters
[Feb 22 03:56:25][mtr0] Meter connection established
[Feb 22 03:56:25][mtr0] Meter thread started
[Feb 22 03:56:25][mtr0] Meter is opened. Starting channels.
[Feb 22 03:56:25][chn0] Logging thread started
[Feb 22 03:56:25][]     Startup done.
[Feb 22 03:56:25][chn0] Start logging thread for null-api.
[Feb 22 03:56:25][chn0] Using null api- meter data available via local httpd if enabled.
[Feb 22 03:56:25][mtr0] Number of readers: 1
[Feb 22 03:56:25][mtr0] Config.local: 0
[Feb 22 03:56:25][mtr0] Got 1 new readings from meter:
[Feb 22 03:56:25][mtr0] Reading: id=NilIdentifier/NilIdentifier value=20.43 ts=1613962585505
[Feb 22 03:56:25][chn0] Adding reading to queue (value=20.43 ts=1613962585505)
[Feb 22 03:56:25][chn0] Stopped logging.
[Feb 22 03:56:25][mtr0] Stopped reading. 
[Feb 22 03:56:26][]     Server stopped.
[Feb 22 03:56:26][]     Trying to delete curlSessionProvider...
[Feb 22 03:56:26][]     deleted curlSessionProvider

{
    "meters": [
        {   
            "enabled": true,
            "protocol": "random",
            "interval": 2,
            "max": 40.0,
            "min": -5.0,
            "channel": {
                "api": "null",
                "uuid": "bac2e840-f72c-11e0-bedf-3f850c1e5a66"
            }
        }
    ]
}