Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
On Tuesday, 11 April 2017 13:23:36 BST Patrick Wigmore wrote: > On Tuesday, 11 April 2017, at 12:16:44 BST, Terry Coles wrote: > > Thanks. Now I can focus on the overheating. We were trying to > > avoid any holes in the case for ventilation. > > I don't want to jinx it, but you might find you have to drill > some drainage holes anyway. Water is a sly opponent! I'd keep an > eye on that. You may be right, but we'll only be running during the summer months, when the outside air temp is reasonably high. > If it's a totally sealed box, I would be inclined to at least put > some dessicant in there to absorb the moisture that's trapped in > the air inside, otherwise you might get condensation issues from > the outside temperature fluctuations. It is pretty much sealed. > > It looks like I need to put a fan inside to help natural > > convection to shift the air from the Pi to the heatsink. > > Is there a heatsink on the Pi's CPU? If there isn't, that would > be fairly easy to add and would probably go a long way, if it is > a thermal issue. Full complement of heatsinks on all three chips. CPU temp is normal. -- Terry -- Next meeting: Bournemouth, Tuesday, 2017-05-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
On Tuesday, 11 April 2017 13:00:29 BST Ralph Corderoy wrote: > Do you know what's generating the heat? Infra-red thermometer or > camera? Can anything be added that would conduct the heat from those to > the case or the internal heatsink? At this stage, I'm not completely certain that heat is the problem. I'm going in to the WMT in a few minutes, so I'll be interested to learn if the problem has been as bad since we've had this cold wind. Also, I intend to run the system out of the case for a few days, to see if we still have an issue. (That would also eliminate (or rather show up) my other theory; interference from the lighting. However, I'm not sure how interference would manifest itself only after the system has been running for some time.) As for an Infra-red thermometer or camera; no, we don't have one. It's a good idea though. Perhaps I should invest in a Pi NoIR (http://www.raspberrypi-spy.co.uk/2013/10/pi-noir-infrared-camera-module-for-raspberry-pi/) to allow me to do the tests :-) -- Terry -- Next meeting: Bournemouth, Tuesday, 2017-05-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
On Tuesday, 11 April 2017, at 12:16:44 BST, Terry Coles wrote: > Thanks. Now I can focus on the overheating. We were trying to > avoid any holes in the case for ventilation. I don't want to jinx it, but you might find you have to drill some drainage holes anyway. Water is a sly opponent! I'd keep an eye on that. If it's a totally sealed box, I would be inclined to at least put some dessicant in there to absorb the moisture that's trapped in the air inside, otherwise you might get condensation issues from the outside temperature fluctuations. > It looks like I need to put a fan inside to help natural > convection to shift the air from the Pi to the heatsink. Is there a heatsink on the Pi's CPU? If there isn't, that would be fairly easy to add and would probably go a long way, if it is a thermal issue. Patrick. -- Next meeting: Bournemouth, Tuesday, 2017-05-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
Hi Terry, > We were trying to avoid any holes in the case for ventilation, so > cooling depends on internal circulation of the air to move the heat > from the hot-spots to a finned heatsink on the inside of the case. Do you know what's generating the heat? Infra-red thermometer or camera? Can anything be added that would conduct the heat from those to the case or the internal heatsink? Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-05-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
On Tuesday, 11 April 2017 11:40:05 BST Ralph Corderoy wrote: > They take buffers and cache out of the equation. 785612 / 16204 = 48 so > you can withstand growth at that rate for quite a few multiples of your > monitoring period, if it's linear. Thanks. Now I can focus on the overheating. We were trying to avoid any holes in the case for ventilation, so cooling depends on internal circulation of the air to move the heat from the hot-spots to a finned heatsink on the inside of the case. The case BTW is an old 7.62 mm Ammo Box :-) The idea is that the heatsink transfers heat from the air to the metal wall of the case. It looks like it may not be working as planned. It looks like I need to put a fan inside to help natural convection to shift the air from the Pi to the heatsink. If that doesn't work, I'll have to put in some vents, but that will let damp air in -- Terry -- Next meeting: Bournemouth, Tuesday, 2017-05-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
Hi Terry, > My interpretation of that is that free memory has declined (fairly > rapidly), but the values for shared, buffers and cached have increased > too. Presumably, that memory will be released by the OS when needed? Buffers and cache, yes. These are the interesting lines from your two runs. > used free > -/+ buffers/cache: 145912 801816 > -/+ buffers/cache: 162116 785612 16204 -16204 They take buffers and cache out of the equation. 785612 / 16204 = 48 so you can withstand growth at that rate for quite a few multiples of your monitoring period, if it's linear. Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-05-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
On Monday, 3 April 2017 22:37:01 BST Ralph Corderoy wrote: > > Would this be a standard subprocess.call() invocation or is there a > > better way? > > The former seems fine AFAICS. Thanks. > > Would I need to create two global instances of /dev/null if I use it > > twice in the same function? > > No, the file descriptor of the open Python File for /dev/null that you > have it dup(2)'d into the desired position, e.g. 2 if you're specifying > it's for stderr. Thanks again. > > How would the instances of /dev/null show up? > > Clearly. > So I don't expect you have to do anything to close it. It's your choice > if you opening it once per program or once per function. (I'd still go > for the former, but you've delivered the code. :-) Thanks. There doesn't seem to be much in the way of memory leaks either; I set the program running yesterday evening with dstat in another screen. When launched, I had 794 MB free, this morning it is still over 700 MB. Since it goes against the grain to routinely reboot a perfectly good system every day, I think I'll leave it as it is for the moment and tell the staff to keep an eye on it for the next few weeks. If they notice any problems, then all they will have to do is power cycle it. If it does become a problem, I'll look again at adding the reboot routine; maybe not every night, but once a week. (I once had a router that did that.) -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-04-04 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
Hi Terry,
> Would this be a standard subprocess.call() invocation or is there a
> better way?
The former seems fine AFAICS.
> Would I need to create two global instances of /dev/null if I use it
> twice in the same function?
No, the file descriptor of the open Python File for /dev/null that you
have it dup(2)'d into the desired position, e.g. 2 if you're specifying
it's for stderr.
> How would the instances of /dev/null show up?
Clearly.
$ sleep 42 /dev/null 42>/dev/null &
[1] 30839
$ ls -l /proc/30839/fd
total 0
lr-x-- 1 ralph ralph 64 Apr 3 19:16 0 -> /dev/null
l-wx-- 1 ralph ralph 64 Apr 3 19:16 1 -> /dev/null
l-wx-- 1 ralph ralph 64 Apr 3 19:16 2 -> /dev/null
l-wx-- 1 ralph ralph 64 Apr 3 19:16 42 -> /dev/null
$
> I have the same references to /dev/pts/2 plus:
>
> 1. All of the GPIO pins appear to be there.
> 2. /dev/urandom.
> 3. /dev/gpiomem.
> 4. anon_inode:[eventpoll11]
>
> That's it. Does that mean that my instances of /dev/null are killed
> when the function exits?
Yes, I think so. It looks like they're being garbage collected by
Python's reference counter because the stdlib function you're passing
the File to doesn't keep a reference.
$ python2
>>> import os
>>> def f(): null = open('/dev/null')
...
>>> os.system('ls -l /proc/%d/fd' % os.getpid())
total 0
lrwx-- 1 ralph ralph 64 Apr 3 19:13 0 -> /dev/pts/2
lrwx-- 1 ralph ralph 64 Apr 3 19:13 1 -> /dev/pts/2
lrwx-- 1 ralph ralph 64 Apr 3 19:13 2 -> /dev/pts/2
0
>>> f(), f(), f()
(None, None, None)
>>> os.system('ls -l /proc/%d/fd' % os.getpid())
total 0
lrwx-- 1 ralph ralph 64 Apr 3 19:13 0 -> /dev/pts/2
lrwx-- 1 ralph ralph 64 Apr 3 19:13 1 -> /dev/pts/2
lrwx-- 1 ralph ralph 64 Apr 3 19:13 2 -> /dev/pts/2
0
>>>
Those three calls to open() through f() and yet all of them have been
closed. There's nothing still referring to them after f() has returned.
>>> def g(): null = open('/dev/null'); os.system('ls -l /proc/%d/fd' %
os.getpid())
...
>>> g()
total 0
lrwx-- 1 ralph ralph 64 Apr 3 19:13 0 -> /dev/pts/2
lrwx-- 1 ralph ralph 64 Apr 3 19:13 1 -> /dev/pts/2
lrwx-- 1 ralph ralph 64 Apr 3 19:13 2 -> /dev/pts/2
lr-x-- 1 ralph ralph 64 Apr 3 19:13 3 -> /dev/null
>>>
While a reference still exists, the local variable null in g(), the file
remains open.
So I don't expect you have to do anything to close it. It's your choice
if you opening it once per program or once per function. (I'd still go
for the former, but you've delivered the code. :-)
Cheers, Ralph.
--
Next meeting: Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/
New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
On Monday, 3 April 2017 16:39:48 BST Ralph Corderoy wrote:
> > I suppose that I could set up another apscheduler event to do a reboot
> > at midnight.
>
> If they don't need to normally twiddle switches after it powers on to
> have it carry out the typically desired routines, then yes you could.
Would this be a standard subprocess.call() invocation or is there a better
way?
> > Should I be closing it? If so, how?
>
> I don't remember the code precisely, but I did suggest not opening
> /dev/null each time the function was called, but instead having a global
> and only opening it the once. open() gives a File object and they have
> a close() method.
>
> >>> f = open('/dev/null')
> >>> f
>
>
>
> >>> f.close()
> >>> f
>
>
Ahh! That's another suggestion that got forgotten along the way. Would I
need to create two global instances of /dev/null if I use it twice in the same
function?
> Did you set `pid` to the process ID of interest? Or replace `$pid' with
> that number? :-)
No. I totally misunderstood the meaning of $pid.
> $ python2 -c 'import time; f = open("/etc/passwd"); time.sleep(42)' &
> [1] 18933
> $ ls -l /proc/18933/fd
> total 0
> lrwx-- 1 ralph ralph 64 Apr 3 16:36 0 -> /dev/pts/2
> lrwx-- 1 ralph ralph 64 Apr 3 16:36 1 -> /dev/pts/2
> lrwx-- 1 ralph ralph 64 Apr 3 16:36 2 -> /dev/pts/2
> lr-x-- 1 ralph ralph 64 Apr 3 16:36 3 -> /etc/passwd
> $
How would the instances of /dev/null show up? I have the same references to /
dev/pts/2 plus:
1. All of the GPIO pins appear to be there.
2. /dev/urandom.
3. /dev/gpiomem.
4. anon_inode:[eventpoll11]
That's it. Does that mean that my instances of /dev/null are killed when the
function exits? (I reset the clock to ensure that the functions that use that
feature would be run. (They are prevented from running outside Opening
Hours)). Each function has been run, but of course they exit almost
immediately because everything is done with subprocess.Popen().
--
Terry Coles
--
Next meeting: Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/
New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
Hi Terry,
> I suppose that I could set up another apscheduler event to do a reboot
> at midnight.
If they don't need to normally twiddle switches after it powers on to
have it carry out the typically desired routines, then yes you could.
> > I doubt leaks would be sufficient to consume all that spare memory.
> > More likely you'd run out of file descriptors or some other resource
> > first, e.g. opening /dev/null each time you play a tune and never
>
> Should I be closing it? If so, how?
I don't remember the code precisely, but I did suggest not opening
/dev/null each time the function was called, but instead having a global
and only opening it the once. open() gives a File object and they have
a close() method.
>>> f = open('/dev/null')
>>> f
>>> f.close()
>>> f
https://docs.python.org/2/library/functions.html#open
https://docs.python.org/2/library/stdtypes.html#bltin-file-objects
> > `ls -l /proc/$pid/fd' would show what file descriptors
> > process $pid has open at that moment.
>
> I can't make that do anything:
>
> terry@OptiPlex:~$ ls -l /proc/$pid/fd
Did you set `pid` to the process ID of interest? Or replace `$pid' with
that number? :-)
$ python2 -c 'import time; f = open("/etc/passwd"); time.sleep(42)' &
[1] 18933
$ ls -l /proc/18933/fd
total 0
lrwx-- 1 ralph ralph 64 Apr 3 16:36 0 -> /dev/pts/2
lrwx-- 1 ralph ralph 64 Apr 3 16:36 1 -> /dev/pts/2
lrwx-- 1 ralph ralph 64 Apr 3 16:36 2 -> /dev/pts/2
lr-x-- 1 ralph ralph 64 Apr 3 16:36 3 -> /etc/passwd
$
0, 1, 2 are its stdin, stdout, and stderr. The lowest available file
descriptor is returned on a successful open(2) so /etc/passwd became 3.
Cheers, Ralph.
--
Next meeting: Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/
New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
On Monday, 3 April 2017 13:44:17 BST Ralph Corderoy wrote: > I was thinking this Pi was being turned off each night, like the other > one. I expect I've forgotten that it's always on. We could tell them to turn it off; they used to have to do that for the old MP3 Player (a portable stereo CD/MP3 Player that sat around on the floor of the chancel). I'd rather it is left on continuously, but it won't be the end of the world if it has to be rebooted now and then. > If the switches were set into position rather than spring-return to the > centre then one option would be to configure Raspbian to reboot > periodically, with your software picking up the settings from the switch > positions. True. Unfortunately they're not so there isn't anything we can do. I suppose that I could set up another apscheduler event to do a reboot at midnight. > It's headless, with no network, a read-only filesystem, and its outputs > are LEDs and speakers? Unless you're planning to blink or chirp status > reports there's not a lot of options for monitoring. :-) Not easily no.. > Can a cable attached to the Pi's serial port be left accessible so you > can come along with a laptop and USB/serial converter and connect up? > You'd then have access to the serial console that you'd configured it > with. We can connect a monitor and keyboard fairly easily, by opening the lid. > > That's a bit of a non-flyer too, because dstat doesn't appear to be > > available in the Raspbian repositories. > > I don't have Raspbian here, but > http://archive.raspbian.org/raspbian/pool/main/d/dstat/ suggests it is > available. Just realised why I couldn't get it. I borrowed my wife's Pi 3 and forgot to let it through the router. The Pi's WiFi icon, only tells you that you are connected to a strong wireless signal, not that you have a path to the Internet. > Yes, http://archive.raspbian.org/raspbian/pool/main/s/screen/ would do Ditto above. > I doubt leaks would be sufficient to consume all that spare memory. > More likely you'd run out of file descriptors or some other resource > first, e.g. opening /dev/null each time you play a tune and never Should I be closing it? If so, how? > closing it. `ls -l /proc/$pid/fd' would show what file descriptors > process $pid has open at that moment. I can't make that do anything: terry@OptiPlex:~$ ls -l /proc/$pid/fd Whatever, I'm going to run the program again overnight tonight using screen and dstat and see what I get. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-04-04 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
Hi Terry, I was thinking this Pi was being turned off each night, like the other one. I expect I've forgotten that it's always on. If the switches were set into position rather than spring-return to the centre then one option would be to configure Raspbian to reboot periodically, with your software picking up the settings from the switch positions. > > > You could leave your program running in tandem with `dstat -cdngym > > > $((60*30))' that produces a line every half an hour and see if > > > anything obviously degrades over time. > > > > That wouldn't be very convenient to view, since the program is > > running headless and without any network interfaces enabled. It's headless, with no network, a read-only filesystem, and its outputs are LEDs and speakers? Unless you're planning to blink or chirp status reports there's not a lot of options for monitoring. :-) Can a cable attached to the Pi's serial port be left accessible so you can come along with a laptop and USB/serial converter and connect up? You'd then have access to the serial console that you'd configured it with. > That's a bit of a non-flyer too, because dstat doesn't appear to be > available in the Raspbian repositories. I don't have Raspbian here, but http://archive.raspbian.org/raspbian/pool/main/d/dstat/ suggests it is available. You can get by with `vmstat $((60*30))' at a pinch. > Also, the software is running in the shell at boot up, so it would be > difficult to view two things running. (Would screen do it, I've only > ever played around with it?) Yes, http://archive.raspbian.org/raspbian/pool/main/s/screen/ would do it. You'd have it run on your TTY instead of your program, and tell it, probably through .screenrc, that you want two new TTYs created, one for your program, one for dstat. When you return and plug in to see the output you'd be able to switch between screen's two TTYs. > Anyway 'free' works and tells me that I have just under 950MB of > physical RAM to play with and immediately after boot-up about 125MB is > used (well over double that in the desktop). I doubt leaks would be sufficient to consume all that spare memory. More likely you'd run out of file descriptors or some other resource first, e.g. opening /dev/null each time you play a tune and never closing it. `ls -l /proc/$pid/fd' would show what file descriptors process $pid has open at that moment. Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-04-04 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
On Sunday, 2 April 2017 15:49:54 BST Terry Coles wrote: > That's a bit of a non-flyer too, because dstat doesn't appear to be > available in the Raspbian repositories. Also, the software is running in > the shell at boot up, so it would be difficult to view two things running. > (Would screen do it, I've only ever played around with it?) No 'screen on the Pi either ;-( -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-04-04 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
On Sunday, 2 April 2017 14:13:02 BST Terry Coles wrote: > > You could leave your program running in tandem with `dstat -cdngym > > $((60*30))' that produces a line every half an hour and see if anything > > obviously degrades over time. > > That wouldn't be very convenient to view, since the program is running > headless and without any network interfaces enabled. > > I'll try it here at home with a copy of the program, but I probably won't be > able to leave it running for all that long. That's a bit of a non-flyer too, because dstat doesn't appear to be available in the Raspbian repositories. Also, the software is running in the shell at boot up, so it would be difficult to view two things running. (Would screen do it, I've only ever played around with it?) Anyway 'free' works and tells me that I have just under 950MB of physical RAM to play with and immediately after boot-up about 125MB is used (well over double that in the desktop). I'm going to leave the Pi running overnight (with the speakers turned off :-) ) and run free again this time tomorrow. Assuming the memory leaks aren't horrendous, I can probably work out a maintenance schedule for the staff to restart the system once a week or whatever. As it happens the system has been running continuously since Thursday afternoon and no-one has phoned me up yet.. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-04-04 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
On Sunday, 2 April 2017 14:05:42 BST Ralph Corderoy wrote: > AIUI your program is doing this, with a few more bells and whistles. Lots of bells, but no whistles. > All these bits of code may have bugs where they leak memory in > processing that endless stream and over time that leak will add up and > memory will be exhausted. Or, they might not have bugs because this is > a well trodden, debugged, path. Or it might be that it would take a > week to be a problem because the leak is small and slow and your program > never runs more than a day. > > You could leave your program running in tandem with `dstat -cdngym > $((60*30))' that produces a line every half an hour and see if anything > obviously degrades over time. That wouldn't be very convenient to view, since the program is running headless and without any network interfaces enabled. I'll try it here at home with a copy of the program, but I probably won't be able to leave it running for all that long. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-04-04 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
[Dorset] Can my system run out of memory if my program continuously O/Ps messages to the shell?
Hi, The question is in the Subject. My Model Town program is designed to run continuously, but I'm not sure if it will run out of memory eventually if the script continuously sends messages to the shell. I vaguely recall that there is a buffer for the content of STDOUT, but can't find any references to this on the web. (I suppose the fact that no-one seems to have problems with this is a pointer to a non-problem.) -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-04-04 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
