Sorry Martin. This shouldn't have been attributed to you; it was Pancho that wrote it. Selecting some message text in Thunderbird seems to confuse it; however I should remember to check attributions before sending.
-- Chris Elvidge England
If you had read the thread, you would have seen that I was testing potential buffering, i.e. awk's timely response to input from the journalctl -f.
It doesn't confuse it as such, but it only quotes the selected text, however it still adds an attribution for the author of the message you're replying to.
That depends: if the occurrence of events to be observed cause messages to be logged rather than being dealt with by the program that observes them, then watching a log for the occurrence might well be the best way to do it since this separates the observation from the consequent action, offering the possibility of more than one observing process being able to trigger the action. Where that action is irreversable, as it is in this case, that sounds like a good idea.
Of course, if the observer doesn't log anything, there's no reason to use a general purpose logfile - just write the observations to a file or pipeline that's accessable to the process that will execute the action: as this is Linux, you can use shared memory or a semaphore (if the programming language supports it) to signal that an actionable event has occurred. Shared memory, event queues and asynchronous i/o are all available in the C and Java standard function/class libraries but may not be in other languages.
OTOH if the required action is specific to the observer, i.e. doesn't affect anything outside the process(es) handling the data stream being observed, then simply deal with the observation inside the observing process.
-- -- Martin | martin at Gregorie | gregorie dot org
I think that was just simple proof-of-concept test code to check that awk was reading the journalctl output stream. Quite reasonable if you've never user awk before.
I don't recall needing the '--' in the "awk -- 'short awk prog'" command before, but there seems to have been a bit of rationalisation going on. I notice that now (Fedora 32) /usr/bin/awk is now a symlink pointing to / usr/bin/gawk but don't know when that happened or which other distros do the same.
-- -- Martin | martin at Gregorie | gregorie dot org
Yes, but that situation is entirely unlike what the OP was talking about, and is indeed inapplicable.
If it's going to limit the current, it must not saturate, in which case it'd store the energy that you claim is unnecessary. You'd also have to remove the energy from the inductor every time the switch switched off, otherwise the switch would break down. Basically you'd have created a conventional step-down converter.
Or, if the inductor saturated but still limited the current, it would have to be a high enough resistance to be quite lossy.
David
25%?
John
Go back and re read your electronics 101
-- "The great thing about Glasgow is that if there's a nuclear attack it'll look exactly the same afterwards." Billy Connolly
Yeah, I'm not sure what you mean, the journal/logfile is the "subject", the "observer" logging isn't relevant.
FWIW I got this basic pattern to work.
--
journalctl -f | awk -W interactive -- '/Specific Event/ { system(
"/home/pi/SpecificEventHandler.sh") }'
Since you're using a pipe to pass messages from the log reader to the awk program, awk makes a read request which will wait for input until either a line of text is written to the pipe, in which case it gets read by awk (awk reads lines, so the message MUST be terminated by a newline) OR the pipe is closed, in which case awk gets an EOF and stops. If the awk script contains a END action, this is executed before is quits.
The only apparent buffering you should see is due to awk waiting for the newline that terminates the line being read. About -W : according to the manpage for the awk version I'm using, 5.0.1,
-W has nothing to do with waiting for anything. All it does is to change the option marker from - to --
-- -- Martin | martin at Gregorie | gregorie dot org
Perhaps that explains our different experience. mawk buffering doesn't appear to be line buffering by default, i.e it buffers blocks somewhere between 2 to 3kB (whatever the correct name for that is).
What OS are you using?
Most amusing, given my decades-long career in electronic engineering.
In what way do think that my statement is incorrect?
David
Fedora 32 for these tests, which uses awk 5.0.1 - The Buster awk is very old, so raising a bug requesting an upgrade to the latest awk may be a good idea.
Running "man 7 pipe" tells you almost everything you'd want to know about pipes and that the implementation changed at Linux 2.6.11 - Fedora 32 is using the Linux 5.9.16 kernel.
Turns out I was wrong about buffering: before 2.6.11 the max buffer size was 4Kb and now its 64 Kb, which rather points at the Raspbian process scheduler as the cause of your buffering problem: if the scheduler is slow to pass control to awk after stuff has been written to the pipe buffer, that would explain the delays you're seeing. If this is the case, you'll need to recognise the problem within the program that detects it and, if its fatal to the system as a whole, make your program issue a "sudo stop" command - in a script something like this should work:
sudo stop
Yes... with special care to observe that safe cutoff voltage so that when power returns the constant current, constant voltage charger doesn't charge the battery any faster than it can accept safely. But wait... the constant current needs to be all that is needed to run the Pi PLUS the additional safe amount to recharge the battery, but... how do you assure the Pi and the battery share the current appropriately so that the Pi runs and the battery recharges safely? Maybe a bit more control is needed to assure a battery voltage above a certain value before the Pi is rebooted.
Likely so, but I've always wondered at comparing the COST of the Pi to the cost of supporting equipment vs comparing the CAPABILITIES of the Pi (vs desktops/laptops/etc) to the cost of support. One can't really expect support costs to scale down proportionally to the lower cost of the Pi.
-- Jim H
The way to do it is to use a purpose-made lithium battery charger IC, for a pound or two. A diode, an inductor, a capacitor, a resistor and a transistor are all that is additionally needed, and some ICs incorporate the transistor. You then need a power source that will provide current for both charging and a reasonable amount to run the device itself. The resistor sets the main charging current, typically
0.3-0.5 of the battery capacity, independently of the device consumption. The diode, inductor, capacitor and transistor do the same jobs as in any switch-mode power supply.-- Joe
Yeah that is kind of the point, I'm a mediocre old programmer, I don't want to know everything about everything. What I want is an easy life. I want a basic technique to work, reliably, environment agnostically as possible.
I think this clarifies in my mind why I wouldn't ever use this technique to observe events in practice. It is too fragile.
So raise a bug to get it fixed: this will help everybody and is, after all, why most Linux distros have decent bug reporting facilities. Plus its quite a good way of thanking the developers for their work.
-- -- Martin | martin at Gregorie | gregorie dot org
There is not a bug, just different implementations, different behaviour. Different buffering, different arguments.
FWIW: I use gawk to follow logfiles, and the fflush() function to flush the output buffers.
Snippet of Bash script : tail -f -n $TLINES $LOGFILE \ | gawk -f $SCRIPT.awk \ | sqlite3 $DATABASE
pseudocode of $SCRIPT.awk : process every input line console output to "/dev/stderr" -> realtime filtered, reformatted view SQL statements to stdout -> statistics After processing every input line: fflush()
-- Regards, Kees Nuyt
Disagree: the delay you're seeing is definitely a bug, though possibly its a task scheduler issue. If you run less than a buffer-full of data through a pipe there should not be a noticeable delay under a UNIX/Linux OS because the buffer is in memory and the task scheduler is a multitasking scheduler and so can interleave both the writing and reading tasks without any delay except those caused by task switching and being preempted by higher priority tasks.
You're reporting multi-second delays you can see which task(s) are involved: run the delayed pipe again, but this time with 'top' running in another console window to see what programs are active during the delay.
OTOH Windows 95 pipes always had delays because those worked by:
- the first program created a new temporary file
- wrote the whole dataset to a file
- closed it
- the second program opened the file
- read the whole dataset
- closed the file
- deleted the file
It had to do that because those versions of Windows did not multi-task, being just a GUI handler sitting on top of MS-DOS 7 and a pipe connecting more than two programs could be very slow.
-- -- Martin | martin at Gregorie | gregorie dot org
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.