[Nut-upsuser] 2.0.1 upsmon memory leak

[Arnaud Quette]

Hi Paul,

2006/8/8, Paul <wes902 at gmail.com>:
>
> Hi;
>
>   I have ran into an issue with the upsmon tool leaking memory over a
> two month period. It seems to be due to one of my UPS hosts offline.
> System is a debian stable with the default nut package. Here's the
> data so far:
>
> companyfs1:/var/log# ps aux | grep [n]ut
> nut       2439  0.0  3.6 380800 18800 ?      S    Jun05   6:41
> /sbin/upsmon
>
> >From my logfiles its failing on one of my UPS servers
> Aug  8 11:24:15 companyfs1 upsmon[2439]: UPS [sm700_0 at 192.168.1.21]:
> connect failed: Connection failure: Connection refused
> Aug  8 11:24:20 companyfs1 upsmon[2439]: UPS [sm700_0 at 192.168.1.21]:
> connect failed: Connection failure: Connection refused
> Aug  8 11:24:25 companyfs1 upsmon[2439]: UPS [sm700_0 at 192.168.1.21]:
> connect failed: Connection failure: Connection refused
>
> Using the configuration file of:
> MONITOR sm700_0 at 192.168.1.21 1 monitoruser password slave
> MONITOR rm3000_0 at 192.168.1.22 0 monitoruser password slave
> MINSUPPLIES 1
> SHUTDOWNCMD "/sbin/shutdown -h +0"
> # NOTIFYCMD /usr/local/ups/bin/notifyme
> POLLFREQ 5
> POLLFREQALERT 5
> HOSTSYNC 15
> DEADTIME 15
> POWERDOWNFLAG /etc/killpower
> RBWARNTIME 43200
> NOCOMMWARNTIME 300
> FINALDELAY 5
>
> Upsmon is:
> companyfs1:/var/log# /sbin/upsmon -V
> Network UPS Tools upsmon 2.0.1
>
> Rehupping the process
>
> companyfs1:/tmp# ps aux | grep [n]ut
> nut      30369  0.0  0.1  1720  756 ?        S    11:31   0:00
> /sbin/upsmon
>
> (of course the process is erroring again)
> Aug  8 11:38:03 companyfs1 upsmon[30369]: UPS [sm700_0 at 192.168.1.21]:
> connect failed: Connection failure: Connection refused
>
> and memory consumption is going back up
>
> companyfs1:/var/log# uptime; ps aux | grep [n]ut
> 12:03:03 up 63 days, 21:48,  1 user,  load average: 4.94, 4.64, 4.47
> nut      30369  0.0  0.1  1840  808 ?        S    11:31   0:00
> /sbin/upsmon
>
>
> Valgrind:
> valgrind --tool=memcheck --leak-check=full /sbin/upsmon
> ==30798== LEAK SUMMARY:
> ==30798==    definitely lost: 72 bytes in 2 blocks.
> ==30798==    indirectly lost: 264 bytes in 22 blocks.
> ==30800== LEAK SUMMARY:
> ==30800==    definitely lost: 72 bytes in 2 blocks.
> ==30800==    indirectly lost: 264 bytes in 22 blocks.
> ==30802== LEAK SUMMARY:
> ==30802==    definitely lost: 392 bytes in 3 blocks.
> ==30802==    indirectly lost: 280 bytes in 23 blocks.
>
> wait for the upsmon attempt to touch the server again...
> ==30861== LEAK SUMMARY:
> ==30861==    definitely lost: 41328 bytes in 268 blocks.
>
> and again...
> ==30879== LEAK SUMMARY:
> ==30879==    definitely lost: 39112 bytes in 124 blocks.
>
>
> I searched upsuser and upsdev lists but didn't find any mention of the
> issue, I'll give 2.0.4 a whirl and see if it generates the same memory
> loss.
>

there has been no change in upsmon for awhile, so I don't think 2.0.4 or
trunk will fix this.

If you get more info, or a patch, please update us.

thanks for your report.

Arnaud
-- 
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20060809/7fd90cd6/attachment.html