Re: [lm-sensors] Fancontrol memory consumption

Re: [lm-sensors] Fancontrol memory consumption

[Jean Delvare]

On Wed, 5 Nov 2014 10:57:48 +0100, Jean Delvare wrote:
> On Tue, 04 Nov 2014 10:20:42 +0100, Taz wrote:
> > Am I wrong ? Do someone have any clue or suggestion ?
> 
> Most likely the leak is in bash itself and fancontrol is only exposing
> it.
> 
> Which version of bash are you using? Try with different versions and
> see if they all behave the same.

As I can reproduce the issue, I tried it myself, and my results are as
follows:
bash 3.0.16: Memory consumption (RSS) is steady
bash 3.1.14: Memory consumption (RSS) increases
bash 4.2.53: Memory consumption (RSS) increases
bash 4.3.30: Memory consumption (RSS) increases

So apparently this is a regression introduced in bash 3.1 and not fixed
yet.

-- 
Jean Delvare
SUSE L3 Support

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Fancontrol memory consumption

[Jean Delvare]

On Wed, 5 Nov 2014 17:57:29 +0100, Jean Delvare wrote:
> As I can reproduce the issue, I tried it myself, and my results are as
> follows:
> bash 3.0.16: Memory consumption (RSS) is steady
> bash 3.1.14: Memory consumption (RSS) increases
> bash 4.2.53: Memory consumption (RSS) increases
> bash 4.3.30: Memory consumption (RSS) increases
> 
> So apparently this is a regression introduced in bash 3.1 and not fixed
> yet.

I have created a ticket to track this issue:

http://www.lm-sensors.org/ticket/2391

After discussing the issue with upstream bash maintainer Chet Ramey,
this is not a memory leak and works as intended, even though this
behavior is undesirable in the case of the fancontrol script.

Taz, feel free to try the following experimental patch for the time
being, I believe it should solve the increasing memory consumption
issue:

---
 prog/pwm/fancontrol |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- lm-sensors.orig/prog/pwm/fancontrol	2014-11-05 22:59:21.823226428 +0100
+++ lm-sensors/prog/pwm/fancontrol	2014-11-07 09:52:14.178257104 +0100
@@ -546,7 +546,7 @@ function UpdateFanSpeeds
 		  	echo $minsa > $pwmo
 			# Sleep while still handling signals
 			sleep 1 &
-			wait $!
+			wait
 		  fi
 		fi
 		echo $pwmval > $pwmo # write new value to pwm output
@@ -585,5 +585,5 @@ do
 	UpdateFanSpeeds
 	# Sleep while still handling signals
 	sleep $INTERVAL &
-	wait $!
+	wait
 done


-- 
Jean Delvare
SUSE L3 Support

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Fancontrol memory consumption

[Taz]

(sorry I just saw my reply still was in my drafts, don't know why...)

Indeed : my current bash version is 4.3.11
Although I don't have line 585 in my fancontrol script
I can apply the the patch (lines 497 & 536 for fancontrol v0.7)

I also gave it a try without the wait lines and not sending to 
background the previous
sleep command the wait was waiting for anyway (useless ?)

=> Mem consumption seems to be the same in all cases, we'll see in the 
long run...

Thanks !

     Cédric L.M.

Le 07/11/2014 10:15, Jean Delvare a écrit :
> On Wed, 5 Nov 2014 17:57:29 +0100, Jean Delvare wrote:
>> As I can reproduce the issue, I tried it myself, and my results are as
>> follows:
>> bash 3.0.16: Memory consumption (RSS) is steady
>> bash 3.1.14: Memory consumption (RSS) increases
>> bash 4.2.53: Memory consumption (RSS) increases
>> bash 4.3.30: Memory consumption (RSS) increases
>>
>> So apparently this is a regression introduced in bash 3.1 and not fixed
>> yet.
> I have created a ticket to track this issue:
>
> http://www.lm-sensors.org/ticket/2391
>
> After discussing the issue with upstream bash maintainer Chet Ramey,
> this is not a memory leak and works as intended, even though this
> behavior is undesirable in the case of the fancontrol script.
>
> Taz, feel free to try the following experimental patch for the time
> being, I believe it should solve the increasing memory consumption
> issue:
>
> ---
>   prog/pwm/fancontrol |    4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- lm-sensors.orig/prog/pwm/fancontrol	2014-11-05 22:59:21.823226428 +0100
> +++ lm-sensors/prog/pwm/fancontrol	2014-11-07 09:52:14.178257104 +0100
> @@ -546,7 +546,7 @@ function UpdateFanSpeeds
>   		  	echo $minsa > $pwmo
>   			# Sleep while still handling signals
>   			sleep 1 &
> -			wait $!
> +			wait
>   		  fi
>   		fi
>   		echo $pwmval > $pwmo # write new value to pwm output
> @@ -585,5 +585,5 @@ do
>   	UpdateFanSpeeds
>   	# Sleep while still handling signals
>   	sleep $INTERVAL &
> -	wait $!
> +	wait
>   done
>
>


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Fancontrol memory consumption

[Jean Delvare]

Hi Taz,

On Thu, 13 Nov 2014 15:36:32 +0100, Taz wrote:
> (sorry I just saw my reply still was in my drafts, don't know why...)
> 
> Indeed : my current bash version is 4.3.11
> Although I don't have line 585 in my fancontrol script
> I can apply the the patch (lines 497 & 536 for fancontrol v0.7)

The "patch" command can apply patch files with offsets just fine.

> I also gave it a try without the wait lines and not sending to 
> background the previous
> sleep command the wait was waiting for anyway (useless ?)

Not sending sleep in the background reportedly caused delays or
undesirable behavior on system suspend or shutdown on some systems. See:
http://www.lm-sensors.org/changeset/4443/lm-sensors/branches/lm-sensors-3.0.0/prog/pwm/fancontrol

> => Mem consumption seems to be the same in all cases, we'll see in the 
> long run...

I discussed the issue with the upstream bash maintainer, but he claims
that the implementation is correct and required for Posix compliance.
My own tests were confusing (sometimes I could reproduce the issue,
sometimes not) so I couldn't reach a definitive conclusion, and
ultimately I forgot about it / gave up on it.

Meanwhile someone contributed a trick to the healthd script which may
work just fine here too. It avoids both the call to an external command
and the use of wait. Can you please revert the previous patch and give
a try to this one instead?

---
 prog/pwm/fancontrol |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

--- lm-sensors.orig/prog/pwm/fancontrol	2014-11-17 09:16:14.657054963 +0100
+++ lm-sensors/prog/pwm/fancontrol	2015-02-28 11:03:32.958562604 +0100
@@ -545,8 +545,7 @@ function UpdateFanSpeeds
 		  then # if fan was stopped start it using a safe value
 		  	echo $minsa > $pwmo
 			# Sleep while still handling signals
-			sleep 1 &
-			wait $!
+			read -t 1 -N 0
 		  fi
 		fi
 		echo $pwmval > $pwmo # write new value to pwm output
@@ -584,6 +583,5 @@ while true
 do
 	UpdateFanSpeeds
 	# Sleep while still handling signals
-	sleep $INTERVAL &
-	wait $!
+	read -t $INTERVAL -N 0
 done

Thanks,
-- 
Jean Delvare
SUSE L3 Support

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Fancontrol memory consumption

[Taz]

Hi Jean,

Besides it looked strange, it didn't bother me enough so I stopped 
monitoring and kind of gave it up too...
But I'll certainly give the new patch a try (and restart monitoring), 
and give you feedback of course.

Thanks a lot !

     Taz (Cédric L.M.)


Le 28/02/2015 11:14, Jean Delvare a écrit :
> Hi Taz,
>
> On Thu, 13 Nov 2014 15:36:32 +0100, Taz wrote:
>> (sorry I just saw my reply still was in my drafts, don't know why...)
>>
>> Indeed : my current bash version is 4.3.11
>> Although I don't have line 585 in my fancontrol script
>> I can apply the the patch (lines 497 & 536 for fancontrol v0.7)
> The "patch" command can apply patch files with offsets just fine.
>
>> I also gave it a try without the wait lines and not sending to
>> background the previous
>> sleep command the wait was waiting for anyway (useless ?)
> Not sending sleep in the background reportedly caused delays or
> undesirable behavior on system suspend or shutdown on some systems. See:
> http://www.lm-sensors.org/changeset/4443/lm-sensors/branches/lm-sensors-3.0.0/prog/pwm/fancontrol
>
>> => Mem consumption seems to be the same in all cases, we'll see in the
>> long run...
> I discussed the issue with the upstream bash maintainer, but he claims
> that the implementation is correct and required for Posix compliance.
> My own tests were confusing (sometimes I could reproduce the issue,
> sometimes not) so I couldn't reach a definitive conclusion, and
> ultimately I forgot about it / gave up on it.
>
> Meanwhile someone contributed a trick to the healthd script which may
> work just fine here too. It avoids both the call to an external command
> and the use of wait. Can you please revert the previous patch and give
> a try to this one instead?
>
> ---
>   prog/pwm/fancontrol |    6 ++----
>   1 file changed, 2 insertions(+), 4 deletions(-)
>
> --- lm-sensors.orig/prog/pwm/fancontrol	2014-11-17 09:16:14.657054963 +0100
> +++ lm-sensors/prog/pwm/fancontrol	2015-02-28 11:03:32.958562604 +0100
> @@ -545,8 +545,7 @@ function UpdateFanSpeeds
>   		  then # if fan was stopped start it using a safe value
>   		  	echo $minsa > $pwmo
>   			# Sleep while still handling signals
> -			sleep 1 &
> -			wait $!
> +			read -t 1 -N 0
>   		  fi
>   		fi
>   		echo $pwmval > $pwmo # write new value to pwm output
> @@ -584,6 +583,5 @@ while true
>   do
>   	UpdateFanSpeeds
>   	# Sleep while still handling signals
> -	sleep $INTERVAL &
> -	wait $!
> +	read -t $INTERVAL -N 0
>   done
>
> Thanks,


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Fancontrol memory consumption

[Taz]

I had to revert to first patch set : new patch consumes 30%  CPU
on my system (or 6% global CPU on Atom D510@1.66GHz).

I let it ran a few minutes from 13h56 to 14h00, then when seeing 
abnormal CPU consumption, I reverted it.





Taz (Cédric L.M.)

Le 28/02/2015 13:39, Taz a écrit :
> Hi Jean,
>
> Besides it looked strange, it didn't bother me enough so I stopped 
> monitoring and kind of gave it up too...
> But I'll certainly give the new patch a try (and restart monitoring), 
> and give you feedback of course.
>
> Thanks a lot !
>
>     Taz (Cédric L.M.)
>
>
> Le 28/02/2015 11:14, Jean Delvare a écrit :
>> Hi Taz,
>>
>> On Thu, 13 Nov 2014 15:36:32 +0100, Taz wrote:
>>> (sorry I just saw my reply still was in my drafts, don't know why...)
>>>
>>> Indeed : my current bash version is 4.3.11
>>> Although I don't have line 585 in my fancontrol script
>>> I can apply the the patch (lines 497 & 536 for fancontrol v0.7)
>> The "patch" command can apply patch files with offsets just fine.
>>
>>> I also gave it a try without the wait lines and not sending to
>>> background the previous
>>> sleep command the wait was waiting for anyway (useless ?)
>> Not sending sleep in the background reportedly caused delays or
>> undesirable behavior on system suspend or shutdown on some systems. See:
>> http://www.lm-sensors.org/changeset/4443/lm-sensors/branches/lm-sensors-3.0.0/prog/pwm/fancontrol 
>>
>>
>>> => Mem consumption seems to be the same in all cases, we'll see in the
>>> long run...
>> I discussed the issue with the upstream bash maintainer, but he claims
>> that the implementation is correct and required for Posix compliance.
>> My own tests were confusing (sometimes I could reproduce the issue,
>> sometimes not) so I couldn't reach a definitive conclusion, and
>> ultimately I forgot about it / gave up on it.
>>
>> Meanwhile someone contributed a trick to the healthd script which may
>> work just fine here too. It avoids both the call to an external command
>> and the use of wait. Can you please revert the previous patch and give
>> a try to this one instead?
>>
>> ---
>>   prog/pwm/fancontrol |    6 ++----
>>   1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> --- lm-sensors.orig/prog/pwm/fancontrol    2014-11-17 
>> 09:16:14.657054963 +0100
>> +++ lm-sensors/prog/pwm/fancontrol    2015-02-28 11:03:32.958562604 
>> +0100
>> @@ -545,8 +545,7 @@ function UpdateFanSpeeds
>>             then # if fan was stopped start it using a safe value
>>                 echo $minsa > $pwmo
>>               # Sleep while still handling signals
>> -            sleep 1 &
>> -            wait $!
>> +            read -t 1 -N 0
>>             fi
>>           fi
>>           echo $pwmval > $pwmo # write new value to pwm output
>> @@ -584,6 +583,5 @@ while true
>>   do
>>       UpdateFanSpeeds
>>       # Sleep while still handling signals
>> -    sleep $INTERVAL &
>> -    wait $!
>> +    read -t $INTERVAL -N 0
>>   done
>>
>> Thanks,
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Fancontrol memory consumption

[Jean Delvare]

Hi Taz,

On Sat, 28 Feb 2015 14:13:07 +0100, Taz wrote:
> 
> I had to revert to first patch set : new patch consumes 30%  CPU
> on my system (or 6% global CPU on Atom D510@1.66GHz).
> 
> I let it ran a few minutes from 13h56 to 14h00, then when seeing 
> abnormal CPU consumption, I reverted it.

Yes, I see the same here :( What happens is that there is no stdin to
read from when the script is run by systemd, so the read command
returns immediately with an error instead of actually waiting.

I'll revert to the previous solution for now, finish the investigation
and see if I can come up with something better, report to upstream
again if needed, and commit the result.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Fancontrol memory consumption

[Jean Delvare]

On Thu, 13 Nov 2014 15:36:32 +0100, Taz wrote:
> (sorry I just saw my reply still was in my drafts, don't know why...)
> 
> Indeed : my current bash version is 4.3.11
> Although I don't have line 585 in my fancontrol script
> I can apply the the patch (lines 497 & 536 for fancontrol v0.7)
> 
> I also gave it a try without the wait lines and not sending to 
> background the previous
> sleep command the wait was waiting for anyway (useless ?)
> 
> => Mem consumption seems to be the same in all cases, we'll see in the 
> long run...

BTW, can you please tell me
* Which architecture this is (x86 or x86-64)?
* The value of "ulimit -u" on this system.
* The total amount of memory on the system.

As Chet Ramey explained to me, the memory consumption is bound and the
default limit depends on these factors. Assuming an x86-64 system,
eating 22 MB of memory as you reported would take about 734000 records
of 32 bytes each, and "ulimit -u" would be set to that value by default
for a system with about 187 GB of memory. Which I would not expect in a
NAS, so something is wrong.

-- 
Jean Delvare
SUSE L3 Support

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Fancontrol memory consumption

[Taz]

Le 02/03/2015 11:30, Jean Delvare a écrit :
> On Thu, 13 Nov 2014 15:36:32 +0100, Taz wrote:
>> (sorry I just saw my reply still was in my drafts, don't know why...)
>>
>> Indeed : my current bash version is 4.3.11
>> Although I don't have line 585 in my fancontrol script
>> I can apply the the patch (lines 497 & 536 for fancontrol v0.7)
>>
>> I also gave it a try without the wait lines and not sending to
>> background the previous
>> sleep command the wait was waiting for anyway (useless ?)
>>
>> => Mem consumption seems to be the same in all cases, we'll see in the
>> long run...
> BTW, can you please tell me
> * Which architecture this is (x86 or x86-64)?
> * The value of "ulimit -u" on this system.
> * The total amount of memory on the system.
>
> As Chet Ramey explained to me, the memory consumption is bound and the
> default limit depends on these factors. Assuming an x86-64 system,
> eating 22 MB of memory as you reported would take about 734000 records
> of 32 bytes each, and "ulimit -u" would be set to that value by default
> for a system with about 187 GB of memory. Which I would not expect in a
> NAS, so something is wrong.
>

The hardware is actually a ReadyNAS ultra 6000 with 2GB RAM.
I'm running a x86_64 ubuntu server 14.04 with 3.16 SMP kernel
and fancontrol from standard repos (pkg vers is 1:3.3.4-2ubuntu1).

=======

\x12(root@ReadyNAS:pts/0)\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12# 
ulimit -u
     7892

(root@ReadyNAS:pts/0)\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12\x12#free
                  total       used       free     shared buffers     cached
     Mem:       2039828    1829656     210172        708 4796    1091516
     -/+ buffers/cache:     733344    1306484
     Swap:      5242876          0    5242876


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Fancontrol memory consumption

[Jean Delvare]

T24gTW9uLCAwMiBNYXIgMjAxNSAxMjowNTowOSArMDEwMCwgVGF6IHdyb3RlOgo+IExlIDAyLzAz
LzIwMTUgMTE6MzAsIEplYW4gRGVsdmFyZSBhIMOpY3JpdCA6Cj4gPiBPbiBUaHUsIDEzIE5vdiAy
MDE0IDE1OjM2OjMyICswMTAwLCBUYXogd3JvdGU6Cj4gPj4gKHNvcnJ5IEkganVzdCBzYXcgbXkg
cmVwbHkgc3RpbGwgd2FzIGluIG15IGRyYWZ0cywgZG9uJ3Qga25vdyB3aHkuLi4pCj4gPj4KPiA+
PiBJbmRlZWQgOiBteSBjdXJyZW50IGJhc2ggdmVyc2lvbiBpcyA0LjMuMTEKPiA+PiBBbHRob3Vn
aCBJIGRvbid0IGhhdmUgbGluZSA1ODUgaW4gbXkgZmFuY29udHJvbCBzY3JpcHQKPiA+PiBJIGNh
biBhcHBseSB0aGUgdGhlIHBhdGNoIChsaW5lcyA0OTcgJiA1MzYgZm9yIGZhbmNvbnRyb2wgdjAu
NykKPiA+Pgo+ID4+IEkgYWxzbyBnYXZlIGl0IGEgdHJ5IHdpdGhvdXQgdGhlIHdhaXQgbGluZXMg
YW5kIG5vdCBzZW5kaW5nIHRvCj4gPj4gYmFja2dyb3VuZCB0aGUgcHJldmlvdXMKPiA+PiBzbGVl
cCBjb21tYW5kIHRoZSB3YWl0IHdhcyB3YWl0aW5nIGZvciBhbnl3YXkgKHVzZWxlc3MgPykKPiA+
Pgo+ID4+ID0+IE1lbSBjb25zdW1wdGlvbiBzZWVtcyB0byBiZSB0aGUgc2FtZSBpbiBhbGwgY2Fz
ZXMsIHdlJ2xsIHNlZSBpbiB0aGUKPiA+PiBsb25nIHJ1bi4uLgoKSSBkb24ndCB0aGluayB5b3Ug
ZXZlciByZXBvcnRlZCB0aGUgcmVzdWx0cyBvZiB0aGF0IHRlc3Q/IFdpdGggdGhlCmZpcnN0IHBh
dGNoIGFwcGxpZWQsIGRvZXMgZmFuY29udHJvbCBzdGlsbCByZWFjaCAyNSBNQiBvZiBtZW1vcnkg
b3Zlcgp0aW1lLCBvciBub3Q/Cgo+ID4gQlRXLCBjYW4geW91IHBsZWFzZSB0ZWxsIG1lCj4gPiAq
IFdoaWNoIGFyY2hpdGVjdHVyZSB0aGlzIGlzICh4ODYgb3IgeDg2LTY0KT8KPiA+ICogVGhlIHZh
bHVlIG9mICJ1bGltaXQgLXUiIG9uIHRoaXMgc3lzdGVtLgo+ID4gKiBUaGUgdG90YWwgYW1vdW50
IG9mIG1lbW9yeSBvbiB0aGUgc3lzdGVtLgo+ID4KPiA+IEFzIENoZXQgUmFtZXkgZXhwbGFpbmVk
IHRvIG1lLCB0aGUgbWVtb3J5IGNvbnN1bXB0aW9uIGlzIGJvdW5kIGFuZCB0aGUKPiA+IGRlZmF1
bHQgbGltaXQgZGVwZW5kcyBvbiB0aGVzZSBmYWN0b3JzLiBBc3N1bWluZyBhbiB4ODYtNjQgc3lz
dGVtLAo+ID4gZWF0aW5nIDIyIE1CIG9mIG1lbW9yeSBhcyB5b3UgcmVwb3J0ZWQgd291bGQgdGFr
ZSBhYm91dCA3MzQwMDAgcmVjb3Jkcwo+ID4gb2YgMzIgYnl0ZXMgZWFjaCwgYW5kICJ1bGltaXQg
LXUiIHdvdWxkIGJlIHNldCB0byB0aGF0IHZhbHVlIGJ5IGRlZmF1bHQKPiA+IGZvciBhIHN5c3Rl
bSB3aXRoIGFib3V0IDE4NyBHQiBvZiBtZW1vcnkuIFdoaWNoIEkgd291bGQgbm90IGV4cGVjdCBp
biBhCj4gPiBOQVMsIHNvIHNvbWV0aGluZyBpcyB3cm9uZy4KPiA+Cj4gCj4gVGhlIGhhcmR3YXJl
IGlzIGFjdHVhbGx5IGEgUmVhZHlOQVMgdWx0cmEgNjAwMCB3aXRoIDJHQiBSQU0uCj4gSSdtIHJ1
bm5pbmcgYSB4ODZfNjQgdWJ1bnR1IHNlcnZlciAxNC4wNCB3aXRoIDMuMTYgU01QIGtlcm5lbAo+
IGFuZCBmYW5jb250cm9sIGZyb20gc3RhbmRhcmQgcmVwb3MgKHBrZyB2ZXJzIGlzIDE6My4zLjQt
MnVidW50dTEpLgo+IAo+ID09PT09PT0KPiAKPiAocm9vdEBSZWFkeU5BUzpwdHMvMCkgIyB1bGlt
aXQgLXUKPiAgICAgIDc4OTIKPiAKPiAocm9vdEBSZWFkeU5BUzpwdHMvMCkgI2ZyZWUKPiAgICAg
ICAgICAgICAgICAgICB0b3RhbCAgICAgICB1c2VkICAgICAgIGZyZWUgICAgIHNoYXJlZCBidWZm
ZXJzICAgICBjYWNoZWQKPiAgICAgIE1lbTogICAgICAgMjAzOTgyOCAgICAxODI5NjU2ICAgICAy
MTAxNzIgICAgICAgIDcwOCA0Nzk2ICAgIDEwOTE1MTYKPiAgICAgIC0vKyBidWZmZXJzL2NhY2hl
OiAgICAgNzMzMzQ0ICAgIDEzMDY0ODQKPiAgICAgIFN3YXA6ICAgICAgNTI0Mjg3NiAgICAgICAg
ICAwICAgIDUyNDI4NzYKClRoaXMgc2VlbXMgdG90YWxseSByZWFzb25hYmxlLiBXaXRoIHRoZXNl
cyBzZXR0aW5ncywgYmFzaCBzaG91bGQgbm90CmNvbnN1bWUgbW9yZSB0aGFuIDI0NyBrQiBvZiBt
ZW1vcnkgdG8gcmVtZW1iZXIgdGhlIHByb2Nlc3Mgc3RhdHVzZXMuClRoaXMgY2FuJ3QgZXhwbGFp
biB0aGUgMjUgTUIgeW91IHJlcG9ydGVkIGluaXRpYWxseS4KClNvIEkgc3RhcnQgc3VzcGVjdGlu
ZyB0aGF0IHlvdXIgcHJvYmxlbSBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgIndhaXQgJCEiCmlzc3Vl
IEkgaGF2ZSBiZWVuIGludmVzdGlnYXRpbmcgc28gZmFyLiBJIGNvdWxkIHJlcHJvZHVjZSB0aGUg
bWVtb3J5CmluY3JlYXNlIGNhdXNlZCBieSAid2FpdCAkISIsIGJ1dCBJIGNvdWxkIG5ldmVyIGdl
dCBiYXNoIHRvIHJlYWNoIDI1IE1CCmFzIHlvdSByZXBvcnRlZC4KClNvIG1heWJlIGl0J3MgYSBk
aWZmZXJlbnQgYnVnLiBiYXNoIDQuMy4xMSBpcyBnZXR0aW5nIG9sZCwgdGhlcmUgaGF2ZQpiZWVu
IDIyIHVwc3RyZWFtIGZpeGVzIG1lYW53aGlsZSAobGF0ZXN0IHN0YWJsZSB2ZXJzaW9uIGlzIDQu
My4zMy4pCk1heWJlIGEgbW9yZSByZWNlbnQgdmVyc2lvbiBpcyBhdmFpbGFibGUgZm9yIHlvdXIg
c3lzdGVtIG5vdz8gVGhpcwpjb3VsZCBhbHNvIGJlIGEgYnVnIHNwZWNpZmljIHRvIHRoZSBVYnVu
dHUgYmFzaCBwYWNrYWdlIHlvdSdyZSBydW5uaW5nLAp3aG8ga25vd3MuCgotLSAKSmVhbiBEZWx2
YXJlClNVU0UgTDMgU3VwcG9ydAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5zb3Jz
Lm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1zZW5z
b3Jz

Re: [lm-sensors] Fancontrol memory consumption

[Taz]

CkxlIDAyLzAzLzIwMTUgMTM6MjYsIEplYW4gRGVsdmFyZSBhIMOpY3JpdCA6Cj4gT24gTW9uLCAw
MiBNYXIgMjAxNSAxMjowNTowOSArMDEwMCwgVGF6IHdyb3RlOgo+PiBMZSAwMi8wMy8yMDE1IDEx
OjMwLCBKZWFuIERlbHZhcmUgYSDDqWNyaXQgOgo+Pj4gT24gVGh1LCAxMyBOb3YgMjAxNCAxNToz
NjozMiArMDEwMCwgVGF6IHdyb3RlOgo+Pj4+IChzb3JyeSBJIGp1c3Qgc2F3IG15IHJlcGx5IHN0
aWxsIHdhcyBpbiBteSBkcmFmdHMsIGRvbid0IGtub3cgd2h5Li4uKQo+Pj4+Cj4+Pj4gSW5kZWVk
IDogbXkgY3VycmVudCBiYXNoIHZlcnNpb24gaXMgNC4zLjExCj4+Pj4gQWx0aG91Z2ggSSBkb24n
dCBoYXZlIGxpbmUgNTg1IGluIG15IGZhbmNvbnRyb2wgc2NyaXB0Cj4+Pj4gSSBjYW4gYXBwbHkg
dGhlIHRoZSBwYXRjaCAobGluZXMgNDk3ICYgNTM2IGZvciBmYW5jb250cm9sIHYwLjcpCj4+Pj4K
Pj4+PiBJIGFsc28gZ2F2ZSBpdCBhIHRyeSB3aXRob3V0IHRoZSB3YWl0IGxpbmVzIGFuZCBub3Qg
c2VuZGluZyB0bwo+Pj4+IGJhY2tncm91bmQgdGhlIHByZXZpb3VzCj4+Pj4gc2xlZXAgY29tbWFu
ZCB0aGUgd2FpdCB3YXMgd2FpdGluZyBmb3IgYW55d2F5ICh1c2VsZXNzID8pCj4+Pj4KPj4+PiA9
PiBNZW0gY29uc3VtcHRpb24gc2VlbXMgdG8gYmUgdGhlIHNhbWUgaW4gYWxsIGNhc2VzLCB3ZSds
bCBzZWUgaW4gdGhlCj4+Pj4gbG9uZyBydW4uLi4KPiBJIGRvbid0IHRoaW5rIHlvdSBldmVyIHJl
cG9ydGVkIHRoZSByZXN1bHRzIG9mIHRoYXQgdGVzdD8gV2l0aCB0aGUKPiBmaXJzdCBwYXRjaCBh
cHBsaWVkLCBkb2VzIGZhbmNvbnRyb2wgc3RpbGwgcmVhY2ggMjUgTUIgb2YgbWVtb3J5IG92ZXIK
PiB0aW1lLCBvciBub3Q/Cj4KPj4+IEJUVywgY2FuIHlvdSBwbGVhc2UgdGVsbCBtZQo+Pj4gKiBX
aGljaCBhcmNoaXRlY3R1cmUgdGhpcyBpcyAoeDg2IG9yIHg4Ni02NCk/Cj4+PiAqIFRoZSB2YWx1
ZSBvZiAidWxpbWl0IC11IiBvbiB0aGlzIHN5c3RlbS4KPj4+ICogVGhlIHRvdGFsIGFtb3VudCBv
ZiBtZW1vcnkgb24gdGhlIHN5c3RlbS4KPj4+Cj4+PiBBcyBDaGV0IFJhbWV5IGV4cGxhaW5lZCB0
byBtZSwgdGhlIG1lbW9yeSBjb25zdW1wdGlvbiBpcyBib3VuZCBhbmQgdGhlCj4+PiBkZWZhdWx0
IGxpbWl0IGRlcGVuZHMgb24gdGhlc2UgZmFjdG9ycy4gQXNzdW1pbmcgYW4geDg2LTY0IHN5c3Rl
bSwKPj4+IGVhdGluZyAyMiBNQiBvZiBtZW1vcnkgYXMgeW91IHJlcG9ydGVkIHdvdWxkIHRha2Ug
YWJvdXQgNzM0MDAwIHJlY29yZHMKPj4+IG9mIDMyIGJ5dGVzIGVhY2gsIGFuZCAidWxpbWl0IC11
IiB3b3VsZCBiZSBzZXQgdG8gdGhhdCB2YWx1ZSBieSBkZWZhdWx0Cj4+PiBmb3IgYSBzeXN0ZW0g
d2l0aCBhYm91dCAxODcgR0Igb2YgbWVtb3J5LiBXaGljaCBJIHdvdWxkIG5vdCBleHBlY3QgaW4g
YQo+Pj4gTkFTLCBzbyBzb21ldGhpbmcgaXMgd3JvbmcuCj4+Pgo+PiBUaGUgaGFyZHdhcmUgaXMg
YWN0dWFsbHkgYSBSZWFkeU5BUyB1bHRyYSA2MDAwIHdpdGggMkdCIFJBTS4KPj4gSSdtIHJ1bm5p
bmcgYSB4ODZfNjQgdWJ1bnR1IHNlcnZlciAxNC4wNCB3aXRoIDMuMTYgU01QIGtlcm5lbAo+PiBh
bmQgZmFuY29udHJvbCBmcm9tIHN0YW5kYXJkIHJlcG9zIChwa2cgdmVycyBpcyAxOjMuMy40LTJ1
YnVudHUxKS4KPj4KPj4gPT09PT09PQo+Pgo+PiAocm9vdEBSZWFkeU5BUzpwdHMvMCkgIyB1bGlt
aXQgLXUKPj4gICAgICAgNzg5Mgo+Pgo+PiAocm9vdEBSZWFkeU5BUzpwdHMvMCkgI2ZyZWUKPj4g
ICAgICAgICAgICAgICAgICAgIHRvdGFsICAgICAgIHVzZWQgICAgICAgZnJlZSAgICAgc2hhcmVk
IGJ1ZmZlcnMgICAgIGNhY2hlZAo+PiAgICAgICBNZW06ICAgICAgIDIwMzk4MjggICAgMTgyOTY1
NiAgICAgMjEwMTcyICAgICAgICA3MDggNDc5NiAgICAxMDkxNTE2Cj4+ICAgICAgIC0vKyBidWZm
ZXJzL2NhY2hlOiAgICAgNzMzMzQ0ICAgIDEzMDY0ODQKPj4gICAgICAgU3dhcDogICAgICA1MjQy
ODc2ICAgICAgICAgIDAgICAgNTI0Mjg3Ngo+IFRoaXMgc2VlbXMgdG90YWxseSByZWFzb25hYmxl
LiBXaXRoIHRoZXNlcyBzZXR0aW5ncywgYmFzaCBzaG91bGQgbm90Cj4gY29uc3VtZSBtb3JlIHRo
YW4gMjQ3IGtCIG9mIG1lbW9yeSB0byByZW1lbWJlciB0aGUgcHJvY2VzcyBzdGF0dXNlcy4KPiBU
aGlzIGNhbid0IGV4cGxhaW4gdGhlIDI1IE1CIHlvdSByZXBvcnRlZCBpbml0aWFsbHkuCj4KPiBT
byBJIHN0YXJ0IHN1c3BlY3RpbmcgdGhhdCB5b3VyIHByb2JsZW0gaXMgZGlmZmVyZW50IGZyb20g
dGhlICJ3YWl0ICQhIgo+IGlzc3VlIEkgaGF2ZSBiZWVuIGludmVzdGlnYXRpbmcgc28gZmFyLiBJ
IGNvdWxkIHJlcHJvZHVjZSB0aGUgbWVtb3J5Cj4gaW5jcmVhc2UgY2F1c2VkIGJ5ICJ3YWl0ICQh
IiwgYnV0IEkgY291bGQgbmV2ZXIgZ2V0IGJhc2ggdG8gcmVhY2ggMjUgTUIKPiBhcyB5b3UgcmVw
b3J0ZWQuCj4KPiBTbyBtYXliZSBpdCdzIGEgZGlmZmVyZW50IGJ1Zy4gYmFzaCA0LjMuMTEgaXMg
Z2V0dGluZyBvbGQsIHRoZXJlIGhhdmUKPiBiZWVuIDIyIHVwc3RyZWFtIGZpeGVzIG1lYW53aGls
ZSAobGF0ZXN0IHN0YWJsZSB2ZXJzaW9uIGlzIDQuMy4zMy4pCj4gTWF5YmUgYSBtb3JlIHJlY2Vu
dCB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBmb3IgeW91ciBzeXN0ZW0gbm93PyBUaGlzCj4gY291bGQg
YWxzbyBiZSBhIGJ1ZyBzcGVjaWZpYyB0byB0aGUgVWJ1bnR1IGJhc2ggcGFja2FnZSB5b3UncmUg
cnVubmluZywKPiB3aG8ga25vd3MuCj4KSmVhbiwKCkZvciB0aGUgcmVzdWx0cyA6IHllcyBpdCBy
ZWFjaGVkIGFyb3VuZCB0aGUgc2FtZSBtZW0gY29uc3VtcHRpb24gOiAKYWx3YXlzIGxlc3MgdGhh
biAzME1CLApzdGFydGluZyBhdCA0TUIgYW5kIGl0IGxvb2tzIHRvIGJlIHRoZSBzYW1lIHN0YXJ0
LXVwIGNvbnN1bXB0aW9uIGFzIHdlbGwgCndpdGggcmVhZCBpbnN0ZWFkIG9mIHNsZWVwLgoKT24g
dGhlIGJhc2ggdmVyc2lvbiA6IEkgZG9uJ3QgcmVhbGx5IHBhaWQgYXR0ZW50aW9uLCBJIGp1c3Qg
a2VwdCBteSAKc3lzdGVtIHVwLXRvIGRhdGUKYW5kIGl0J3Mgc3RpbGwgdGhlIHNhbWUgdmVzcmlv
biwgc28gSSBndWVzcyB0aGVyZSB3ZXJlIG5vIG5ldyByZWxlYXNlIAphdmFpbGFibGUgc2luY2Ug
dGhlbi4uLgoKPT4gSSdsbCB0cnkgdG8gaW5zdGFsbCBhbiB1cGRhdGVkIHZlcnNpb24gb2YgYmFz
aCBpZiBJIGNhbiBhbmQgdGVsbCB5b3UgCmFib3V0IGl0LgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vu
c29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9s
aXN0aW5mby9sbS1zZW5zb3Jz

Re: [lm-sensors] Fancontrol memory consumption

[Jean Delvare]

On Mon, 02 Mar 2015 19:10:02 +0100, Taz wrote:
> For the results : yes it reached around the same mem consumption : 
> always less than 30MB,
> starting at 4MB and it looks to be the same start-up consumption as well 
> with read instead of sleep.

Looks like I managed to reproduce your problem:

00d50000-04748000 rw-p 00000000 00:00 0                                  [heap]
Size:              59360 kB
Rss:               41072 kB
Pss:               41072 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:     41072 kB
Referenced:        23936 kB
Anonymous:         41072 kB
AnonHugePages:         0 kB
Swap:              18288 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Locked:                0 kB
VmFlags: rd wr mr mw me ac

I didn't do anything special, no idea why I couldn't see that before.
And no idea how to investigate it further :(

-- 
Jean Delvare
SUSE L3 Support

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Fancontrol memory consumption

[Jean Delvare]

On Mon, 1 Jun 2015 15:32:41 +0200, Jean Delvare wrote:
> On Mon, 02 Mar 2015 19:10:02 +0100, Taz wrote:
> > For the results : yes it reached around the same mem consumption : 
> > always less than 30MB,
> > starting at 4MB and it looks to be the same start-up consumption as well 
> > with read instead of sleep.
> 
> Looks like I managed to reproduce your problem:
> 
> 00d50000-04748000 rw-p 00000000 00:00 0                                  [heap]
> Size:              59360 kB
> Rss:               41072 kB
> Pss:               41072 kB
> Shared_Clean:          0 kB
> Shared_Dirty:          0 kB
> Private_Clean:         0 kB
> Private_Dirty:     41072 kB
> Referenced:        23936 kB
> Anonymous:         41072 kB
> AnonHugePages:         0 kB
> Swap:              18288 kB
> KernelPageSize:        4 kB
> MMUPageSize:           4 kB
> Locked:                0 kB
> VmFlags: rd wr mr mw me ac
> 
> I didn't do anything special, no idea why I couldn't see that before.

Bah, I remember now. What I did is running the script with bash version
4.3.11, which is the one you're seeing the bug on. Probably I did that
long ago and then forgot to check the result. I'll check how
reproducible this is.

> And no idea how to investigate it further :(

-- 
Jean Delvare
SUSE L3 Support

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Fancontrol memory consumption

[Taz]

Le 01/06/2015 16:47, Jean Delvare a écrit :
> On Mon, 1 Jun 2015 15:32:41 +0200, Jean Delvare wrote:
>> On Mon, 02 Mar 2015 19:10:02 +0100, Taz wrote:
>>> For the results : yes it reached around the same mem consumption :
>>> always less than 30MB,
>>> starting at 4MB and it looks to be the same start-up consumption as well
>>> with read instead of sleep.
>> Looks like I managed to reproduce your problem:
>>
>> 00d50000-04748000 rw-p 00000000 00:00 0                                  [heap]
>> Size:              59360 kB
>> Rss:               41072 kB
>> Pss:               41072 kB
>> Shared_Clean:          0 kB
>> Shared_Dirty:          0 kB
>> Private_Clean:         0 kB
>> Private_Dirty:     41072 kB
>> Referenced:        23936 kB
>> Anonymous:         41072 kB
>> AnonHugePages:         0 kB
>> Swap:              18288 kB
>> KernelPageSize:        4 kB
>> MMUPageSize:           4 kB
>> Locked:                0 kB
>> VmFlags: rd wr mr mw me ac
>>
>> I didn't do anything special, no idea why I couldn't see that before.
> Bah, I remember now. What I did is running the script with bash version
> 4.3.11, which is the one you're seeing the bug on. Probably I did that
> long ago and then forgot to check the result. I'll check how
> reproducible this is.
>
>> And no idea how to investigate it further :(
Sorry for late answer but I was quite busy lastly (I moved).

Still using the bash version you're refering to, I'm at 80 Mb usage 
after 20 days uptime:

=================
Name:   fancontrol
State:  S (sleeping)
Tgid:   1292
Ngid:   0
Pid:    1292
PPid:   1
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 256
Groups: 0
VmPeak:    96472 kB
VmSize:    96472 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:     81064 kB
VmRSS:     81064 kB
VmData:    78652 kB
VmStk:       136 kB
VmExe:       956 kB
VmLib:      2288 kB
VmPTE:       208 kB
VmSwap:        0 kB
Threads:        1
SigQ:   0/7887
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000016007
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
Seccomp:        0
Cpus_allowed:   f
Cpus_allowed_list:      0-3
Mems_allowed:   00000000,00000001
Mems_allowed_list:      0
===================

Won't paste the output as well here but /proc/..../smaps shows many 
segments, whithin which one is using 75 Mb.
(don't know if it's helpful...).

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors