httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: apr_shm_create succeeds then fails on Mac OS X
Date Mon, 28 Dec 2015 14:09:44 GMT
You could possible add a call to apr_shm_remove(shmfilename, pconf)
(resp. shmfilename_delaypool) in the module's post_config, before the
SHMs are created with apr_shm_create().

Regards,
Yann.

On Mon, Dec 28, 2015 at 2:56 PM, Jim Jagielski <jim@jagunet.com> wrote:
> Looks like the module is not cleaning up and removing the shared memory
> segment during a shutdown and/or restart.
>
>> On Dec 28, 2015, at 8:43 AM, Tapple Gao <tapplek@gmail.com> wrote:
>>
>> I found something that helped: I googled and discovered the ipcs utility:
>>
>> 68 08:24 tapple /Library/Server/Web/Config/apache2/sites $ ipcs -am
>> IPC status from <running system> as of Mon Dec 28 08:24:42 EST 2015
>> T     ID     KEY        MODE       OWNER    GROUP  CREATOR   CGROUP NATTCH  SEGSZ
 CPID  LPID   ATIME    DTIME    CTIME
>> Shared Memory:
>> m  65536 0x0052e2c1 --rw------- postgres postgres postgres postgres      6     56
   484    484 19:25:25  8:24:22 19:25:25
>> m 1572865 0x0101d953 --rw-------     root    wheel     root    wheel      0 2401448
 78687  78687 17:32:23 17:32:58 17:32:23
>> m  65541 0x00000000 --rw------- _devicemgr _devicemgr _devicemgr _devicemgr     
5      1    652    652 19:25:36  8:24:22 19:25:36
>> m 2293766 0x0101d952 --rw-------     root    wheel     root    wheel      0    904
 78687  78687 17:32:23 17:32:58 17:32:23
>>
>> Hey. that size of 2401448 looks familiar. yup. that’s the size listed of the failed
allocation in the logs. Let’s try removing it:
>>
>> 171 08:26 tapple /Library/Server/Web/Config/apache2/sites $ sudo ipcrm -m 1572865
>> Password:
>> 172 08:26 tapple /Library/Server/Web/Config/apache2/sites $ ipcs -am
>> IPC status from <running system> as of Mon Dec 28 08:26:38 EST 2015
>> T     ID     KEY        MODE       OWNER    GROUP  CREATOR   CGROUP NATTCH  SEGSZ
 CPID  LPID   ATIME    DTIME    CTIME
>> Shared Memory:
>> m  65536 0x0052e2c1 --rw------- postgres postgres postgres postgres      6     56
   484    484 19:25:25  8:26:22 19:25:25
>> m  65541 0x00000000 --rw------- _devicemgr _devicemgr _devicemgr _devicemgr     
5      1    652    652 19:25:36  8:26:22 19:25:36
>> m 2293766 0x0101d952 --rw-------     root    wheel     root    wheel      0    904
 78687  78687 17:32:23 17:32:58 17:32:23
>>
>> Now my server starts. Hovever, as soon as I kill and restart the server, the same
problem returns.
>> I’m not familiar with ipc at all. Anybody know why any of this happened? why the
shared memory stuck around after apache quit? Why it couldn’t allocate another block? why
it worked after deleting the leftover one?
>>
>>> On Dec 28, 2015, at 7:49 AM, Tapple Gao <tapplek@gmail.com> wrote:
>>>
>>> /tmp is not a special volume on my system, and has plenty of room for a 2MB file:
>>> sh-3.2# df -h
>>> Filesystem                          Size   Used  Avail Capacity  iused    ifree
%iused  Mounted on
>>> /dev/disk0s2                       184Gi  170Gi   14Gi    93% 44604554  3741719
  92%   /
>>> devfs                              329Ki  329Ki    0Bi   100%     1138      
 0  100%   /dev
>>> map -hosts                           0Bi    0Bi    0Bi   100%        0      
 0  100%   /net
>>> map auto_home                        0Bi    0Bi    0Bi   100%        0      
 0  100%   /home
>>> map -fstab                           0Bi    0Bi    0Bi   100%        0      
 0  100%   /Network/Servers
>>> /dev/disk0s5                       442Gi  353Gi   89Gi    80% 92513182 23266901
  80%   /Volumes/Shared
>>> localhost:/18XTcmWVPTgvjvav7dUs5F  184Gi  184Gi    0Bi   100%        0      
 0  100%   /Volumes/MobileBackups
>>>
>>>
>>>> On Dec 27, 2015, at 4:18 PM, Jim Jagielski <jim@jaguNET.com> wrote:
>>>>
>>>> Are you *sure* that /tmp really has enough space?
>>>>
>>>>> On Dec 27, 2015, at 8:47 AM, Sorin Manolache <sorinm@gmail.com>
wrote:
>>>>>
>>>>> On 2015-12-25 19:36, Tapple Gao wrote:
>>>>>> Hi. I’m trying to get mod_tile working on the builtin apache in
Mac OS X El Capitan. I am running into a problem with apr_shm_create failing to allocate memory
during ap_hook_post_config:
>>>>>> [Fri Dec 25 12:09:17.898197 2015] [tile:error] [pid 22431] Successfully
create shared memory segment size 888 on file /tmp/httpd_shm.22431
>>>>>> [Fri Dec 25 12:09:17.898285 2015] [tile:error] [pid 22431] (12)Cannot
allocate memory: Failed to create shared memory segment size 2401448 on file /tmp/httpd_shm_delay.22431
>>>>>>
>>>>>> Is there something I need to configure to get this shared memory
working, or increase the limit? This module is most often run on Ubuntu linux, where it’s
been running for years to power openstreetmap.org
>>>>>>
>>>>>>
>>>>>>  /*
>>>>>>   * Create a unique filename using our pid. This information is
>>>>>>   * stashed in the global variable so the children inherit it.
>>>>>>   * TODO get the location from the environment $TMPDIR or somesuch.
>>>>>>   */
>>>>>>  shmfilename = apr_psprintf(pconf, "/tmp/httpd_shm.%ld", (long int)getpid());
>>>>>>  shmfilename_delaypool = apr_psprintf(pconf, "/tmp/httpd_shm_delay.%ld",
(long int)getpid());
>>>>>
>>>>>
>>>>> I think that the location of the shmfile must be on a filesystem of a
special type, namely tmpfs, which maps in memory and not on disk. Execute "mount" and check
if you have such filesystems mounted. For example on my Linux machine:
>>>>>
>>>>> $ mount
>>>>> /dev/sda6 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
>>>>> tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=398160k)
>>>>> /dev/sda9 on /tmp type ext4 (rw,relatime,data=ordered)
>>>>>
>>>>> As you see, / and /tmp are of disk partitions while /run/shm has a filesystem
of type tmpfs.
>>>>>
>>>>> I suggest to change the code and use a different location from /tmp/...
On Linux the shared memory is often created in /run/shm/*. I have no experience with Mac OS
X.
>>>>>
>>>>> The cleanest way would be to implement what's written in the commentary
of the code above, namely the possibility to specify the path by an evrionment variable or
from a configuration directive.
>>>>>
>>>>> Sorin
>>>>>
>>>>
>>>
>>
>

Mime
View raw message