- edited description
A defined state file is not handled correctly sometimes
Hello Tildeslash,
there is a little glitch to handle the "set statefile" and the "set idfile" also.
If a state file is defined, the file is used.
But, if the defined file is removed from the monitrc file the previously defined file is still used.
From my point of view, the default state file should be used if I remove the definition from the monitrc file.
lutz% lsof -p 69708
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
monit 69708 lutz cwd DIR 1,4 782 44898236 /Data/Users/lutz/Projects/monit-5.33.0
monit 69708 lutz txt REG 1,4 2976684 44925623 /Data/Users/lutz/Projects/monit-5.33.0/monit
monit 69708 lutz txt REG 1,2 622896 5928890 /usr/lib/dyld
monit 69708 lutz txt REG 1,2 385327878 5950849 /dyld_shared_cache_x86_64
monit 69708 lutz 0u CHR 16,5 0t21384 891 /dev/ttys005
monit 69708 lutz 1u CHR 16,5 0t21384 891 /dev/ttys005
monit 69708 lutz 2u CHR 16,5 0t21384 891 /dev/ttys005
monit 69708 lutz 3w REG 1,2 114576 50763100 /private/tmp/stack-logs.69708.1034f4000.monit.YRRb42.index
monit 69708 lutz 4w REG 1,4 8807 44898544 /Data/Users/lutz/Projects/monit-5.33.0/monit.log
monit 69708 lutz 5u REG 1,4 408 44925626 /Data/Users/lutz/Projects/monit-5.33.0/monit.state
monit 69708 lutz 6u IPv4 0x2423d71b41f0e25b 0t0 TCP localhost:atmtcp (LISTEN)
monit 69708 lutz 7u unix 0x2423d71b2f54b29b 0t0 ->0x2423d71b2f70280b
monit 69708 lutz 8u IPv6 0x2423d71b411650bb 0t0 TCP localhost:atmtcp (LISTEN)
The defined state file is still in use, but no longer defined in the monitrc file.
The webgui page "Monit runtime status" show the wrong file also.
State file /Users/lutz/Projects/monit-5.33.0/monit.state
I do some more tests and create a pull request to fix this as soon as possible.
With regards,
Lutz
p.s.
The memory used to store the state and id file names will not freed with a monit reload.
All the time I reload the monitrc file with reload, the memory is allocated again and again.
And after removing the definitions from the monitrc file the memory is still used.
Monit was build based on commit 41618c5, in detail
Revision 41618c58cbf740b186888d148e99d155edbbc3bd
Repository https://bitbucket.org/tildeslash/monit.git
The problem does not depend to the last release, I find the same problem in old releases also.
lutz% leaks 69708
Process: monit [69708]
Path: /Data/Users/lutz/Projects/monit-5.33.0/monit
Load Address: 0x103212000
Identifier: monit
Version: 0
Code Type: X86-64
Parent Process: sh [69707]
Date/Time: 2023-08-08 22:07:32.048 +0200
OS Version: Mac OS X 10.10.5 (14F27)
Report Version: 7
Analysis Tool: /Applications/Xcode.app/Contents/Developer/usr/bin/leaks
Analysis Tool Version: Xcode 6.3.1 (6D1002)
----
leaks Report Version: 2.0
Process 69708: 3670 nodes malloced for 321 KB
Process 69708: 4 leaks for 192 total leaked bytes.
Leak: 0x7fa121420500 size=48 zone: DefaultMallocZone_0x1035fa000 length: 42 "/Users/lutz/Projects/monit-5.33.0/monit.id"
Call stack: [thread 0x7fff78b50300]: | start | main monit.c:184 | do_init monit.c:301 | parse | yyparse | yylex l.l:648 | Str_dup Str.c:297 | Mem_alloc Mem.c:52 | malloc | malloc_zone_malloc
Leak: 0x7fa121420530 size=48 zone: DefaultMallocZone_0x1035fa000 length: 45 "/Users/lutz/Projects/monit-5.33.0/monit.state"
Call stack: [thread 0x7fff78b50300]: | start | main monit.c:184 | do_init monit.c:301 | parse | yyparse | yylex l.l:648 | Str_dup Str.c:297 | Mem_alloc Mem.c:52 | malloc | malloc_zone_malloc
Leak: 0x7fa1215000d0 size=48 zone: DefaultMallocZone_0x1035fa000 length: 42 "/Users/lutz/Projects/monit-5.33.0/monit.id"
Call stack: [thread 0x7fff78b50300]: | start | main monit.c:633 | do_reinit monit.c:373 | parse | yyparse | yylex l.l:648 | Str_dup Str.c:297 | Mem_alloc Mem.c:52 | malloc | malloc_zone_malloc
Leak: 0x7fa121500130 size=48 zone: DefaultMallocZone_0x1035fa000 length: 45 "/Users/lutz/Projects/monit-5.33.0/monit.state"
Call stack: [thread 0x7fff78b50300]: | start | main monit.c:633 | do_reinit monit.c:373 | parse | yyparse | yylex l.l:648 | Str_dup Str.c:297 | Mem_alloc Mem.c:52 | malloc | malloc_zone_malloc
I use MacOS to do the tests based on Monit 5.33.0 (commit 41618c5), but I found the same problems in Linux and AIX environment based on Monit 5.29.0 too.
Comments (4)
-
reporter -
repo owner - changed status to new
-
reporter Hello Tildeslash,
I fixed the memory leaks based on the path handling for the log, pid, id and state file. Changes in the monitrc file do not override the options used for the state and id file and a reload does not create memory leaks.lutz% leaks 51754 Process: monit [51754] Path: /usr/local/bin/monit Load Address: 0x10ca0e000 Identifier: monit Version: 0 Code Type: X86-64 Parent Process: bash [51711] Date/Time: 2023-08-14 00:27:21.884 +0200 OS Version: Mac OS X 10.10.5 (14F27) Report Version: 7 Analysis Tool: /Applications/Xcode.app/Contents/Developer/usr/bin/leaks Analysis Tool Version: Xcode 6.3.1 (6D1002) ---- leaks Report Version: 2.0 Process 51754: 3307 nodes malloced for 307 KB Process 51754: 3 leaks for 112 total leaked bytes. Leak: 0x7fd2e0f000a0 size=16 zone: DefaultMallocZone_0x10ceb3000 length: 13 "./monit.state" Call stack: [thread 0x7fff7a7c5300]: | 0xa | start | main | Str_dup | Mem_alloc | malloc | malloc_zone_malloc Leak: 0x7fd2e0f00720 size=48 zone: DefaultMallocZone_0x10ceb3000 length: 43 "/Users/lutz/Projects/monit-5.33.0/monit.log" Call stack: [thread 0x7fff7a7c5300]: | 0xa | start | main | do_init | parse | yyparse | yylex | Str_dup | Mem_alloc | malloc | malloc_zone_malloc Leak: 0x7fd2e0f00780 size=48 zone: DefaultMallocZone_0x10ceb3000 length: 43 "/Users/lutz/Projects/monit-5.33.0/monit.pid" Call stack: [thread 0x7fff7a7c5300]: | 0xa | start | main | do_init | parse | yyparse | yylex | Str_dup | Mem_alloc | malloc | malloc_zone_malloc
Based on the fix, the memory leaks above are fixed.
A reload after a id, state and pid or log file path change does not result in a memory leak, now. But, monit does not switch back to the defaults if the configuration statements are deleted in the monitrc.
The memory leaks are gone,
Lutz -
reporter I create the pull request #129 Fix memory leaks in the id, state and log, id file usage
This will fix some problems in the file handling, I think,
Lutz - Log in to comment