| Subject: | Prevent shared libs from being cached in memory on AIX |
Here's the email thread from the par mailing list:
On AIX, when I execute my pp'd binary (pp -C) the shared libs remain loaded in memory. I'd like to prevent that by changing the permissions on the files in the cache. If the execute permissions are removed from 'other', then the library won't be kept in memory on AIX.
Will this patch be sufficient? Any issues with it that I'm not considering? I wonder if it could be further restricted to 0700 or even 0500?
$ svn diff par/PAR-Packer/trunk/ par/trunk/
Index: par/PAR-Packer/trunk/myldr/boot.c
===================================================================
--- par/PAR-Packer/trunk/myldr/boot.c (revision 1533)
+++ par/PAR-Packer/trunk/myldr/boot.c (working copy)
@@ -66,7 +66,7 @@
if (close(fd) == -1)
return EXTRACT_FAIL;
- chmod(*ext_path, 0755);
+ chmod(*ext_path, 0750);
return EXTRACT_OK;
}
Index: par/trunk/lib/PAR/Heavy.pm
===================================================================
--- par/trunk/lib/PAR/Heavy.pm (revision 1533)
+++ par/trunk/lib/PAR/Heavy.pm (working copy)
@@ -158,7 +158,7 @@
binmode($fh);
$member->extractToFileHandle($fh);
close $fh;
- chmod 0755, $filename;
+ chmod 0750, $filename;
}
return $filename;
If that's all sufficient, how should I proceed? Get commit permission? Submit an RT against PAR and PAR-Packer?
Thanks
-Tim
---
What do you mean by "remain loaded in memory" - even after the process created by executing the pp'd binary has exited?
And why would changing the "other" bits on the files have any effect on that?
Cheers, Roderich
---
Yes, you've got it. They remain loaded in memory even after the pp'd binary has exited and been cleaned up (cache removed). The result is that when the pp'd binary is called again (and again, and again), another copy get's loaded (and kept) in memory because it's in a different cache directory. The workaround is to run slibclean, but by changing the "other" bits, AIX doesn't bother trying to keep it in shared memory.
Thanks
-Tim
---
I see, weird.
Your patch looks reasonable, shouldn't break in other environments as cache files should be in a per-user tree anyway.
Just a file bug on RT against PAR-Packer (because that's were I look first), the text of your original post should do.
Cheers, Roderick