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 <j...@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 <tapp...@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 <tapp...@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 <j...@jagunet.com> wrote: >>>> >>>> Are you *sure* that /tmp really has enough space? >>>> >>>>> On Dec 27, 2015, at 8:47 AM, Sorin Manolache <sor...@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 >>>>> >>>> >>> >> >
