Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: apr_shm_create succeeds then fails on Mac OS X
From: Jim Jagielski <jim@jaguNET.com>
In-Reply-To: 
 <CAKQ1sVOqpw49SwFb7aPmX7cPJjmmqVivE0QLrN_HKap0pNu6zw@mail.gmail.com>
Date: Mon, 28 Dec 2015 10:00:00 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A7343CD-81D8-40D9-9D13-9FE775B2A153@jaguNET.com>
References: <DD189592-FCB4-4A99-B95C-F04C2FCB02EE@gmail.com>
 <567FEBDF.2020903@gmail.com>
 <5BA8A9B2-FA42-40F7-B101-71E0387DF0C2@jaguNET.com>
 <9895C63F-993B-4A05-8663-6C02BACF0AD7@gmail.com>
 <B656438B-D6F7-4756-8FEE-664ED85AADB2@gmail.com>
 <F8B2CB33-DBD2-41CF-AB0E-E846B0DDD08C@jaguNET.com>
 <CAKQ1sVOqpw49SwFb7aPmX7cPJjmmqVivE0QLrN_HKap0pNu6zw@mail.gmail.com>
To: modules-dev@httpd.apache.org

Registering it as a cleanup is likely better
> On Dec 28, 2015, at 9:09 AM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>=20
> 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().
>=20
> Regards,
> Yann.
>=20
> 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.
>>=20
>>> On Dec 28, 2015, at 8:43 AM, Tapple Gao <tapplek@gmail.com> wrote:
>>>=20
>>> I found something that helped: I googled and discovered the ipcs =
utility:
>>>=20
>>> 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
>>>=20
>>> Hey. that size of 2401448 looks familiar. yup. that=E2=80=99s the =
size listed of the failed allocation in the logs. Let=E2=80=99s try =
removing it:
>>>=20
>>> 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
>>>=20
>>> Now my server starts. Hovever, as soon as I kill and restart the =
server, the same problem returns.
>>> I=E2=80=99m 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=E2=80=99t allocate another block? why it worked after deleting =
the leftover one?
>>>=20
>>>> On Dec 28, 2015, at 7:49 AM, Tapple Gao <tapplek@gmail.com> wrote:
>>>>=20
>>>> /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
>>>>=20
>>>>=20
>>>>> On Dec 27, 2015, at 4:18 PM, Jim Jagielski <jim@jaguNET.com> =
wrote:
>>>>>=20
>>>>> Are you *sure* that /tmp really has enough space?
>>>>>=20
>>>>>> On Dec 27, 2015, at 8:47 AM, Sorin Manolache <sorinm@gmail.com> =
wrote:
>>>>>>=20
>>>>>> On 2015-12-25 19:36, Tapple Gao wrote:
>>>>>>> Hi. I=E2=80=99m 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
>>>>>>>=20
>>>>>>> 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=E2=80=99s been running for years to power =
openstreetmap.org
>>>>>>>=20
>>>>>>>=20
>>>>>>> /*
>>>>>>>  * 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 =3D apr_psprintf(pconf, "/tmp/httpd_shm.%ld", (long =
int)getpid());
>>>>>>> shmfilename_delaypool =3D apr_psprintf(pconf, =
"/tmp/httpd_shm_delay.%ld", (long int)getpid());
>>>>>>=20
>>>>>>=20
>>>>>> 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:
>>>>>>=20
>>>>>> $ mount
>>>>>> /dev/sda6 on / type ext4 =
(rw,relatime,errors=3Dremount-ro,data=3Dordered)
>>>>>> tmpfs on /run/shm type tmpfs =
(rw,nosuid,nodev,noexec,relatime,size=3D398160k)
>>>>>> /dev/sda9 on /tmp type ext4 (rw,relatime,data=3Dordered)
>>>>>>=20
>>>>>> As you see, / and /tmp are of disk partitions while /run/shm has =
a filesystem of type tmpfs.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Sorin
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20