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 >>>> >>> >> >
