Bugzilla – Bug 973
vmunix: Process "eloqdb" Pid 6095 Uid 200 : brk/sbrk failure as exceeding RLIMIT_DATA - returning ENOMEM
Last modified: 2021-09-11 15:59:26 MDT
Created attachment 556 [details] sudo vs root startup Hi, We are using sudo to startup a client database and on a new client machine, we decided to install 64bits version of sudo, all of our other clients are running the 32bits version on hpux 11iv3. The first day the client went live with the new machine and after users have started to connect on the box, so error message was thrown by the database, here is the message. 2021-04-14 11:40:56 ( 6095) K1: [782] FTS memory allocation failed, res_list_rx: 8388608 (res_grow:437) Talking to our database supplier it confirm that the message was thrown because we reach some RLIMIT_DATA that look to be 2gb. But, looking at the configuration of the system the 64bits parms that should drive the RLIMIT_DATA is set at 32gb (maxdsiz_64bits) and should not been block at 2gb. At all of the other clients, the memory regions for the data space are way higher than 2gb. So, we decided to open a case with HPE for support and after HPE investigation, they could demonstrate with internal utility that restrictions are happening only when sudo is launching the database, if the database get launched by root per example it act properly. is it possible that version 1.9.5 restrict the 64bits RLIMIT_DATA with the 32bits maxdsiz kernel value, this one is really set at 2gb. here are both value at the client to control the data space for 32 and 64 bit maxdsiz 2147483647 (32bit apps) maxdsiz_64bit 34359738368 (64bit apps) Thanks,
other client are running different version of 1.8.X 32bit sudo
It's possible that the code to save and restore the resource limits is using the 32-bit version on HP-UX, though I don't see how offhand. I'll investigate this. Did you download the 64-bit sudo package from the sudo.ws website or somewhere else?
I downloaded using http://hpux.connect.org.uk/
I did some tesing on an HP-UX 11.31 ia64 machine where the datasize limits are the default--1GB for 32-bit processes and 4GB for 64-bit processes. Running a 64-bit program vi auso that simply prints the datasize limits here is what I see: sudo 1.8.20p2 (32-bit): rlim.rlim_cur 4294967296 rlim.rlim_max 4294967296 sudo 1.9.6p1 (32-bit): rlim.rlim_cur 1073741824 rlim.rlim_max 1073741824 sudo 1.9.6p1 (64-bit): rlim.rlim_cur 4294967296 rlim.rlim_max 4294967296 So in my testing, the 64-bit version of sudo 1.9.6p1 worked as expected and it is only the 32-bit version that has a problem. Newer versions of sudo raise the datasize limit while sudo is running and restore it before executing the command. Can you verify that on the problematic machine the sudo binary is actually 64-bit? You should see something like the following from the file command: $ file /usr/local/bin/sudo /usr/local/bin/sudo: setuid ELF 64-bit MSB executable, IA-64, version 1 (HP-UX), dynamically linked, interpreter /usr/lib/hpux64/uld.so:/usr/lib/hpux64/dld.so, with debug_info, not stripped
Fixed in sudo 1.9.7