<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Thanks, Steve.<br>
<br>
Mark, backporting the workaround isn't possible / simple, fsync()
isn't available in idf-2.1, there's only a stub in newlib.h.<br>
<br>
<br>
For the followup on my issue with the "tail" implementation, I've
pushed my proposal as branch "prop-cmdtask".<br>
<br>
Background: the tail command shall be interruptable / terminatable
as usual by pressing Ctrl-C. The same applies to other possibly long
running commands, i.e. the CANopen scanner. Of course a background
process can be used for execution (like wifi scan does), but
requires returning results by watching logs, doing a push
notification or issuing a "get results" type subcommand.<br>
<br>
So I set up a simple task command wrapper class "OvmsCommandTask"
based on TaskBase and the console's insert callback API.<br>
<br>
A command simply subclasses the wrapper and implements the Service()
method. The Service() loop then polls IsTerminated() and exits as
indicated.<br>
<br>
That makes adding an interruptable command very neat, simple and
straight forward, no more code than with a standard command:<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/prop-cmdtask#diff-c5776c6f55d7048a9906488d9d61c2c0R269">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/prop-cmdtask#diff-c5776c6f55d7048a9906488d9d61c2c0R269</a><br>
<br>
This all works nicely, but maybe I'm crossing some already existing
plans with this approach.<br>
<br>
Possible issues:<br>
<ol>
<li>Is it too short-sighted to implement the termination detection
outside the OvmsShell? Another approach could hook into
OvmsShell::ProcessChar, but would require a registration of
termination callbacks on top of the insert callback. I like the
idea of keeping the shell as simple as possible, but this can of
course be seen as a task for the shell.<br>
<br>
</li>
<li>Is it OK to implement just the simple termination signal using
a bool and polling instead of using FreeRTOS event groups or
task notifications? Using RTOS signals would enable to terminate
a running command from another terminal by some "kill" command
sending the signal to the command task. It would also provide
commands being able to wait for signals instead of poll them. Do
we actually need/want this already?<br>
<br>
</li>
<li>Is it OK to use the key listener just for termination for now,
or should the class provide keyboard input support as well?<br>
<br>
</li>
</ol>
Of course the OvmsCommandTask class implementation can be changed
later on to implement a more sophisticated approach on any or all of
these points, so maybe we can get back to the refinement later.<br>
<br>
This is also in no hurry, there are more important todos. The tail
command seemed to be a simple under-the-week-thing at the beginning
;)<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 10.01.2018 um 17:34 schrieb Stephen
Casner:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.OSX.2.21.1801100833470.63538@auge.attlocal.net">
<pre wrap="">Michael,
I will implement the optional syslog distribution to all consoles.
-- Steve
On Wed, 10 Jan 2018, Michael Balzer wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Mark, Steve,
thanks for the test & workaround.
Yes, the syslog can better be distributed internally by the console system. The "tail" command is also intended for general debugging/monitoring
of files. I thought it would be straight forward to implement, but another issue/idea turned up we should discuss -- I'll follow up on that
after work.
Regards,
Michael
Am 10.01.2018 um 01:07 schrieb Mark Webb-Johnson:
</pre>
<blockquote type="cite">
<pre wrap="">Nope:
Here is /store:
OVMS > log file /store/log.txt
...
I (37670) simcom: State: Enter PoweringOn state
I (37670) simcom: Power Cycle
OVMS > vfs stat /store/log.txt
File /store/log.txt size is 0 and digest d41d8cd98f00b204e9800998ecf8427e
OVMS > log file
Closed log file
OVMS > vfs stat /store/log.txt
File /store/log.txt size is 1176 and digest b15515a15edeb75d04a2767ba66a721d
And here is /sd:
OVMS > log file /sd/log.txt
I (15494) simcom: State timeout, transition to 1
I (15494) simcom: State: Enter CheckPowerOff state
OVMS > vfs stat /sd/log.txt
File /sd/log.txt size is 0 and digest d41d8cd98f00b204e9800998ecf8427e
OVMS > log file
Closed log file
OVMS > vfs stat /sd/log.txt
File /sd/log.txt size is 122 and digest ae18d2d2ed63b5dd2381b5bf11d1779d
Seems to be the FAT filesystem itself.
The vfs layer only seems to support a fsync operation, but no fflush. I'm guessing fflush just flushes the FILE buffers, but doesn't actually
sync that to disk. Adding 'fsync(fileno(ovms_log_file));' after 'fflush(ovms_log_file);' in ConsoleAsync::ConsoleLogger of
main/console_async.cpp seems to resolve this:
OVMS > log file /store/log.txt
OVMS > vfs stat /store/log.txt
File /store/log.txt size is 1176 and digest b15515a15edeb75d04a2767ba66a721d
I (15450) simcom: State timeout, transition to 13
I (15620) simcom: State: Enter PoweredOff state
OVMS > vfs stat /store/log.txt
File /store/log.txt size is 1296 and digest 96221e6daf7258b6e2c0d9eb4a92cad3
There is also a separate issue of multi-line messages not being logged correctly (LF -> "|" translation). I've pushed both fixes to
the remotes/origin/for-v3.0 branch Steve and I are working on for v3.0. Haven't tested in 2.1 master, but it will probably work there if you
want to merge back to master.
All that said, I think Steve is correct. A tail function (although useful) is not the best way of doing this particular thing. Better to have
a 'log monitor yes/no' command that sets a flag on the current console (presumably in OvmsWriter like the m_issecure flag). If set, then log
messages are shown on that console. Perhaps default to 'yes' for async console, and 'no' for the others.
Now SD CARD support is coming, anybody want to step forward and extend components/can to support CAN bus logging to a file (in crtd format, or
perhaps support one or two popular formats)? Implementation would be in class canbus, very similar to m_trace; just need to have a FILE* m_log
and appropriate commands / logging of packet write/read in the same place that trace does it.
Regards, Mark.
</pre>
<blockquote type="cite">
<pre wrap="">On 10 Jan 2018, at 7:28 AM, Stephen Casner <<a class="moz-txt-link-abbreviated" href="mailto:casner@acm.org">casner@acm.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:casner@acm.org"><mailto:casner@acm.org></a>> wrote:
Michael,
I think we can do better than "tail" command. The design for printing
log messages is prepared to print on all registered consoles. We have
restricted the console_logger() function to just output on the async
console out of concernt that sending output to the remote consoles
might be too much of a burden. But if that is what's desired for a
particular user's scenario, then what we should do is to add a command
to direct the output to all consoles.
-- Steve
On Wed, 10 Jan 2018, Michael Balzer wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Mark,
I've built a simple "tail" command to follow the file log on the telnet console.
Unfortunately -- with v2.1 -- the fflush() on the log file doesn't work as expected, the file contents will not be updated until I close the
file.
Is that issue solved with v3.x?
Regards,
Michael
Am 08.01.2018 um 07:28 schrieb Mark Webb-Johnson:
</pre>
<blockquote type="cite">
<pre wrap="">I've restructured the log commands a bit:
* The old "level <severity>" command has moved to "log level <severity>"
* A new "log file <path>" command has been added. For example "log file /sd/log.txt" will mean that anything that gets logged to the
console will also get
appended to /sd/log.txt as well, until reboot. You can use /sd (if SD CARD is working for you), or /store (but take care - that is
system flash).
* You should be able to hook this in at the "sd.mounted" event script, to turn on logging to sd card on boot (again, if SD CARD is working
for you).
Enjoy, Mark
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</blockquote>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>