On 02/08/2023 05:41, 23k.304 wrote:
> On 7/31/23 5:32 AM, The Natural Philosopher wrote:
>> On 31/07/2023 02:54, 23k.302 wrote:
>>> On 7/29/23 2:42 PM, David W. Hodgins wrote:
>>>> On 7/30/23 10:45, The Natural Philosopher wrote:
>>>>> On 30/07/2023 10:24, Theo wrote:
>>>>>> So all you really need to do is reproduce the directory structure:
>>>>>>
>>>>>> find/var/log -type d -exec mkdir -p "/tmp/{}" \;
>>>>>>
>>>>>> which reproduces/var/log/foo/bar/  to/tmp/var/log/foo/bar/
>>>>>>
>>>>>> Theo
>>>>> Now that is interesting, and if I leave the old /var/log there, and
>>>>> mount a ramdisk over it, provided that the ramdisk is*immediately*
>>>>> populated and directories created, then all should work?
>>>> Any process that has a log file open before you mount the ramdisk won't
>>>> automatically start using it.  The process will still have the open
>>>> file
>>>> handle to the original, disk-based file instead.  So you'll either need
>>>> to be sure to mount the ramdisk sufficiently early in the boot sequence
>>>> to ensure that no daemons have opened their logfiles yet, or you'll
>>>> need
>>>> to signal those daemons reopen their logs.  Most do that in response to
>>>> SIGHUP.  Logrotate often uses that mechanism after rotating logs, so
>>>> its
>>>> configuration can help you figure out what needs to be done after
>>>> mounting the ramdisk if programs are still logging to disk.
>>>
>>>
>>>    Hmm ... MIGHT be able to make that work with minimal
>>>    pain using systemd. It has 'depends on','run after' and
>>>    such params. He could init the ramdisk REALLY early in a
>>>    quasi-structured/quasi-safe environment.
>>>
>>>    Not everyone likes systemd - but it DOES have its uses.
>>>
>>>    Another trick is to just make the ramdisk whenever and
>>>    then make /var/log into a symlink/mountpoint. Yes, there'd
>>>    be some early stuff still in the real /var/log, but maybe
>>>    that's not important for him.
>>>
>>>    However I'd rec ramdisks for where they're more useful.
>>>    I have an app that does a lot of image manipulation
>>>    before the results are shown via PHP/Apache on a Pi.
>>>    I don't want any of that to be reading/writing to the
>>>    SD card - too slow AND burns it out - but I did want
>>>    access to be "normal", like with any 'real' drive. A
>>>    small ramdisk was by far the best/easiest solution.
>>
>> I use them in this and my other pi-zero  context as fundamentally
>> simple interprocess communicators. So in my Hifi Project, a daemon
>> reads the icecast info off radio streams and writes it to a file in a
>> temporary file system.
>>
>> The web server then has access to that to let me know what misc is
>> being played, via ajax calls from the web servers radio interface.
>>
>> As long as only one process is writing them, this is a very simple and
>> effective way to transfer data from one daemon to another.
>
>   Agreed. If you CAN keep it simple, DO keep it simple.
>   Remember YOU might have to debug/enhance it a few
>   years LATER  :-)
>
Oh, I learnt my code writing contract assembler for people who wanted it
well commented enough that the stupidest permie could fix it years later.
Or myself. Sometimes I look at stuff I wrote and marvel at ait.

I am not a computer scientist. Elegance isn't in my nature. I am a
software and other sorts of engineer, and making it work, and keep on
working at the lowets possible prices is burned into my soul

"An engineer is someone who can do for five bob what any damned fool can
do for a quid"

>   Things like Pi's are special cases - not blazing fast,
>   not a lot of RAM, run off SD cards/eMMC that have to be
>   protected from re-write fatigue. If the need for space
>   isn't excessive, and simplicity is worthwhile (almost
>   always) then a RAMdisk is often your best solution.
>
Ha! compared with a Z80 with 48k of usable RAM or a 6809, they ARE
blazingly fast. I cut my teeth writing C and assembler for those, stuff
that was burned into ROM.
There is so much on this zero ROM - 16GB! And I have ram coming out of
my ears.

>   Because of the filesystem overhead, RAMdisks just MIGHT
>   not be fast enough ... then you have to go to "less simple"
>   approaches alas. To each app, its own.
>
My access requrements are measured in seconds, not micro seconds.

>> In the current project which involves driving 4 mains relays using a
>> daemon that collects various bits of information in order to decide
>> when to switch them on, it is used to store the relay state, so again
>> ajax calls from the web server can determine not what *should be on,
>> but what is *actually* on.
>
>   Cool stuff
>
>> I am sure the semaphores messages and pipes might have done the job,
>> but simply recreating  a file ion a ramdisk every few seconds works fine.
>
>   "Pipes" are a kind of cheat - really just "invisible" R/W files.
>   I used them kinda extensively on some forking servers I wrote a
>   couple of years ago in Python and 'C' to make data gathered by
>   new forks accessible to the mother process. They WORK just fine
>   and are commonly used and I *think* a tad faster than a RAMdisk,
>   but still ...
>
Oh there surely are faster, but who is in a hurry? a central heating
controller changes states every few HOURS. and if the users browser view
of that is a second behind, frankly who gives a damn?

Like wise room temperatures and tank oil levels are not things that
change much in an hour...

>   I'm fond of such 'servers' - even cobbled together a good
>   "pre-forked" one - supposedly the highest-capacity/speed -
>   for both TCP and UDP - but never had a good high-volume
>   reason to use them. The best was almost like a 'chat' app,
>   non-sync bi-directional where the queen server process could
>   initiate, even push, tasks and messages to the clients. Fun !
>
>   Hmm ... now apparently some possible servants of Xi here
>   are calling me a "troll" because I repeated a few things
>   (said by HS/NSA/CIA) they didn't WANT to hear about
>   CCP sabotage-ware infiltrating almost everything in
>   our important infrastructure/military systems and
>   'devices' (which are almost entirely Linux/Unix-based).
>   One day soon they ARE gonna get a big wake-up call ... but
>   meanwhile denial means they won't DO anything about it  :-)
>
The problem is that no one knows what is really happening, and although
the political narratives that are spun for consumption by hoi polloi,
are obviously not the real truth, no one knows what is. Not even the
spinners.

I myself know for example, that there couldn't have been any weapons of
mass destruction *directly threatening British interests* in Iraq, and
that our prime minister lied about that. I spent a couple of years
designing missile parts and know in principle where the bleeding edge
is, and it sure ain't in Iraq.

I know that Covid injections do not put goverment control chips in your
brain, They don't need to. They have the mass mediafor that :-)

I know the moon landings were real, because there wasn't the technology
then to fake it.

I know that 911 was a simple case of structural failure in a fire,
because everything about it is consistent with my knowledge of
structural engneering.

I dont know who apart from lee harvey oswald, might have shot JFK , or
why. |Jury still out.

I know that 'renewable' energy is a greater disaster than any climate
change, and I know that climate change is largely natural with very
little man made components. Because I did the years of research. And the
problem is within my pay garde as an engineer with a good STEM background

I don't know who runs the world banks, but I an fairly sure its not
Jews, or Lizards.
I am however sure that they haven't a clue what they are doing.

>   ANYway, /var/log CAN be moved to a RAMdisk if you want.
>   Not 100% sure WHY you'd want to, but it CAN. If a few
>   very early logs get 'lost' as you re-direct /var/log
>   then that MIGHT not be all so important. If you want
>   it all on RAMdisk then you don't CARE if it all
>   vanishes on reboot. I very rarely look in /var/log
>   anyhow so ....

As I said, whoever you are, the less writing to an SD drive there is,
the less chance there is of file system corruption when the power goes out.

Its simply a natural habit to ensure than whatever an embedded system
does is the minimum necessary to get the job done with the maximum
reliability.

The SD card looks like it might be the weakest link. So I am trying to
reduce stress on it.

--
"Women actually are capable of being far more than the feminists will
let them."