[OSRM-talk] osrm-datastore error code 21

Kieran Caplice kieran.caplice at temetra.com
Fri Feb 2 12:25:33 UTC 2018


Hi Daniel,

Many thanks for the reply again. An update: turns out when I rebooted 
the machine to fix the issue with running osrm-datastore across 
different users, I had forgotten that changes to /etc/sysctl.conf are 
not persisted after rebooting, so all is working fine now after adding 
the kernel.shmall and kernel.shmmax properties again.

Kind regards,
Kieran Caplice

On 29/01/18 18:07, Daniel Patterson wrote:
> Hi Kieran,
>
>   The problem is definitely occurring when trying to allocate the 
> shared memory block.  This line from your strace output shows the 
> error happening:
>
> shmget(0x10001b9, 96772768369, IPC_CREAT|0644) = -1 EINVAL (Invalid 
> argument)
>
>   I suspect the "code 21 (EISDIR)" message we're printing out here is 
> wrong or misleading, maybe.
>
>   Can you try playing with the constants in this test program?
>
>
> -----------BEGIN test.c-----------------------
> #include <sys/shm.h>
> #include <stdio.h>
> #include <errno.h>
> #include <string.h>
> #include <sys/ipc.h>
>
> //#define MEMORY_SIZE 96772768369
> #define MEMORY_SIZE 1024*1024
> #define KEY_PATH "/tmp/osrm.lock"
>
> int main(void) {
>
>   key_t tok = ftok(KEY_PATH, 0);
>
>   // Original that was being called
>   //int result = shmget(0x10001b9, 96772768369, IPC_CREAT|0644);
>
>   int result = shmget(tok, MEMORY_SIZE, IPC_CREAT|0644);
>
>   if (result == -1) {
>     printf("shmget returned -1: errno is %d: %s\n", errno, 
> strerror(errno));
>   } else {
>     printf("shmget worked - cleaning up\n");
>     shmctl(result, IPC_RMID, NULL);
>   }
>
> }
> --------------END test.c-----------------------------
>
>   Try different values of "MEMORY_SIZE", and also try uncommenting the 
> original shmget line that I've included, see if that works standalone, 
> and see what messages you get.
>
>   Compiling the test program should be a simple "gcc test.c"
>
> daniel
>
> On Mon, Jan 29, 2018 at 1:48 AM, Kieran Caplice 
> <kieran.caplice at temetra.com <mailto:kieran.caplice at temetra.com>> wrote:
>
>     Hi Julien/Daniel,
>
>     Thanks for the replies. I had read that github issue prior to
>     emailing the list, and it did solve the initial error I was
>     having, which was due to running osrm-datastore as root and later
>     as user "osrm". Rebooting the machine solved this as it did for
>     you, Julien. But after that I'm faced with this issue.
>
>     @Daniel: /tmp contains the two files:
>     -rw-rw-r-- 1 osrm  osrm     0 Jan 26 16:34 osrm-datastore.lock
>     -rw-rw-r-- 1 osrm  osrm     0 Jan 26 16:34 osrm.lock
>
>     Output of the strace:
>
>     root at htzh /opt/osrm # su - osrm -c "strace osrm-datastore
>     /opt/osrm/data/planet-latest/planet-latest.osrm"
>     ...
>     open("/opt/osrm/data/planet-latest/planet-latest.osrm.tld",
>     O_RDONLY) = 5
>     read(5,
>     "OSRN\5\17\0M\25\17\0\0\0\0\0\0\1\0\3\0\1\1\3\0\1\0\v\0\1\1\v\0"...,
>     8191) = 8191
>     close(5)           = 0
>     stat("/opt/osrm/data/planet-latest/planet-latest.osrm.partition",
>     0x7ffcde3c8d20) = -1 ENOENT (No such file or directory)
>     stat("/opt/osrm/data/planet-latest/planet-latest.osrm.cells",
>     0x7ffcde3c8d20) = -1 ENOENT (No such file or directory)
>     stat("/opt/osrm/data/planet-latest/planet-latest.osrm.cell_metrics",
>     0x7ffcde3c8d20) = -1 ENOENT (No such file or directory)
>     stat("/opt/osrm/data/planet-latest/planet-latest.osrm.mldgr",
>     0x7ffcde3c8d20) = -1 ENOENT (No such file or directory)
>     ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
>     ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
>     write(1, "[info] Allocating shared memory "..., 57[info]
>     Allocating shared memory of 96772768369 bytes
>     ) = 57
>     stat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
>     stat("/tmp/osrm.lock", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
>     stat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
>     stat("/tmp/osrm.lock", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
>     shmget(0x10001b9, 96772768369, IPC_CREAT|0644) = -1 EINVAL
>     (Invalid argument)
>     ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
>     ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
>     write(2, "\33[31m[error] Error while attempt"..., 88[error] Error
>     while attempting to allocate shared memory: Invalid argument, code
>     21) = 88
>     write(2, "\33[0m", 4)                   = 4
>     write(2, "\n", 1
>     )                       = 1
>     write(2, "terminate called after throwing "..., 48terminate called
>     after throwing an instance of ') = 48
>     ...
>
>     Can you provide any further insight into what the problem might be?
>
>     By the way, we're using the latest release version (v5.15.0) built
>     from source on 16.04.
>
>     Kind regards,
>     Kieran Caplice
>
>
>     On 26/01/18 17:48, Julien Coupey wrote:
>
>         Hi,
>
>         Not sure if you're hitting the same problem here, but I recall
>         a related discussion happening a while back at:
>
>         https://github.com/Project-OSRM/osrm-backend/issues/1724
>         <https://github.com/Project-OSRM/osrm-backend/issues/1724>
>
>         At least it provides a few hints on permissions and shared memory.
>
>         Julien
>
>         Le 26/01/2018 à 18:31, Daniel Patterson a écrit :
>
>             Kieran,
>
>                Hmm, we could probably improve the error handling here
>             and make the message a bit more useful.
>
>                The problem is probably one of:
>
>                  1) Permission problems accessing /tmp/osrm.lock
>                  2) Permission problems creating shared memory
>
>                Code 21 is:
>
>             $ errno 21
>             EISDIR 21 Is a directory
>
>                So I'd suspect some bad filesystem permissions
>             somewhere. You can try running the `osrm-datastore`
>             command under `strace` and see if you can spot the syscal
>             that's failing with - that might give a hint as to what's
>             going wrong.
>
>             daniel
>
>             On Fri, Jan 26, 2018 at 8:57 AM, Kieran Caplice
>             <kieran.caplice at temetra.com
>             <mailto:kieran.caplice at temetra.com>
>             <mailto:kieran.caplice at temetra.com
>             <mailto:kieran.caplice at temetra.com>>> wrote:
>
>                 Hello,
>
>                 I'm wondering if anyone can help out with this error
>             I'm getting
>                 when running osrm-datastore under a non-root user:
>
>                 root at htzh /opt/osrm # su - osrm -c "osrm-datastore
>                 /opt/osrm/data/planet-latest/planet-latest.osrm"
>                 [info] Loading data into REGION_1
>                 [info] load names from:
>                 "/opt/osrm/data/planet-latest/planet-latest.osrm.names"
>                 [info] Allocating shared memory of 96772768369 bytes
>                 [error] Error while attempting to allocate shared
>             memory: Invalid
>                 argument, code 21
>                 terminate called after throwing an instance of
>             'osrm::util::exception'
>                    what():  Invalid
>             argumentinclude/storage/shared_memory.hpp:308
>                 root at htzh /opt/osrm # su - osrm -c "ulimit -a | grep max"
>                 max locked memory       (kbytes, -l) 128849018880
>                 max memory size         (kbytes, -m) unlimited
>                 max user processes              (-u) 1031189
>
>                 Available shared memory for the user has been increased in
>                 /etc/security/limits.conf as per the wiki page, as
>             shown above.
>
>                 The server has 256GB of RAM, with at least 200GB
>             available most of
>                 the time. I successfully ran osrm-datastore and
>             osrm-routed as the
>                 root user earlier, but we would ideally run it under a
>             separate user.
>
>                 Thanks in advance.
>
>                 Kind regards,
>                 Kieran Caplice
>
>
>                 _______________________________________________
>                 OSRM-talk mailing list
>             OSRM-talk at openstreetmap.org
>             <mailto:OSRM-talk at openstreetmap.org>
>             <mailto:OSRM-talk at openstreetmap.org
>             <mailto:OSRM-talk at openstreetmap.org>>
>             https://lists.openstreetmap.org/listinfo/osrm-talk
>             <https://lists.openstreetmap.org/listinfo/osrm-talk>
>                 <https://lists.openstreetmap.org/listinfo/osrm-talk
>             <https://lists.openstreetmap.org/listinfo/osrm-talk>>
>
>
>
>
>             _______________________________________________
>             OSRM-talk mailing list
>             OSRM-talk at openstreetmap.org
>             <mailto:OSRM-talk at openstreetmap.org>
>             https://lists.openstreetmap.org/listinfo/osrm-talk
>             <https://lists.openstreetmap.org/listinfo/osrm-talk>
>
>
>         _______________________________________________
>         OSRM-talk mailing list
>         OSRM-talk at openstreetmap.org <mailto:OSRM-talk at openstreetmap.org>
>         https://lists.openstreetmap.org/listinfo/osrm-talk
>         <https://lists.openstreetmap.org/listinfo/osrm-talk>
>
>
>
>     _______________________________________________
>     OSRM-talk mailing list
>     OSRM-talk at openstreetmap.org <mailto:OSRM-talk at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/osrm-talk
>     <https://lists.openstreetmap.org/listinfo/osrm-talk>
>
>
>
>
> _______________________________________________
> OSRM-talk mailing list
> OSRM-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osrm-talk/attachments/20180202/91600052/attachment-0001.html>


More information about the OSRM-talk mailing list