Ok. This way I can recover registry. I did not find yet when and why registry crashes. If I found the scenario I'll report it.
Meanwhile I am having roubles binding to a semaphore created in one process, from another process. I used a simple demo app to show what is happening (full source code attached) >From one process (creator.c) a semaphore is created and binded by its registry name "namedSem": rt_task_shadow (&task, "creatorTask", 20, 0); rt_sem_create(&sem, "namedSem", 0, S_FIFO); rt_sem_bind(&sem, "namedSem", TM_INFINITE); for (;;) sleep (100); So all ok here. Now keeping creator.c running in an xterm and trying to bind to this semaphore from another process (binder.c), from another xterm, it does not work: rt_task_shadow (&task, "binderTask", 20, 0); rt_sem_bind(&sem, "namedSem", TM_INFINITE); rt_sem_bind() never binds to the semaphore "namedSem". It seams it does not find it. If a timeout is set: err=rt_sem_bind(&sem, "namedSem", TM_INFINITE); it returns with error -110 (ETIMEDOUT) But the semaphore exists in registry: $> cat /var/run/xenomai/anon/4267/alchemy/semaphores/namedSem =0 I think on version 2.5.x a named object is global to the system. So when creating a semaphore named "namedSem" by a process it is visible for all other processes. Maybe in 3.x semaphores (and other objects) are local to processes? Since they are stored in the registry under the pid of the creator process? Maybe this would explain why it is possible to bind from the same process but not from another process with the same code: rt_sem_bind(&sem, "namedSem", TM_INFINITE); If this is so how to bind to an object existing in the xenomai registry (created by another process)? The second argument of rt_xxxx_bind() should include something like the PID of the creator process? PS: I am using Mercury so no /proc/xenomai support: /usr/xenomai/sbin/version -a Xenomai/mercury v3.0-rc3 -- Target: i686-pc-linux-gnu Compiler: gcc version 4.7.2 (Debian 4.7.2-5) Build args: '--with-core=mercury' '--enable-registry' '--prefix=/usr/xenomai' On 4 March 2015 at 08:40, Philippe Gerum <[email protected]> wrote: > On 03/03/2015 09:38 PM, Helder Daniel wrote: > > Done that: > > > > $> sudo pkill sysregd > > > > $> sudo ps aux | grep sysregd > > user 4045 0.0 0.1 3796 800 pts/1 S+ 20:30 0:00 grep > > sysregd > > > > all instances killed. > > > > Now launch: > > > > $> sudo /usr/xenomai/sbin/sysregd --linger --daemonize > > > > $> sudo ps aux | grep sysregd > > root 4022 0.0 0.3 3776 1888 ? Ssl 20:28 0:00 > > /usr/xenomai/sbin/sysregd --linger --daemonize > > user 4045 0.0 0.1 3796 800 pts/1 S+ 20:30 0:00 grep > > sysregd > > > > Daemon running. > > > > Now tried to run app and receive the same error: > > > > ./hello > > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"): > > Transport endpoint is not connected > > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"): > > Transport endpoint is not connected > > sysregd: create_directory_recursive("/var/run/xenomai/anon/system"): > > Transport endpoint is not connected > > 3"006.383| WARNING: [main] cannot connect to registry daemon > > 3"006.574| BUG: [main] initialization failed, EAGAIN > > > > The only plausible scenario for this issue is that sysregd got killed > (e.g. SIGKILL or SIGHUP, not SIGTERM which currently leads to a graceful > exit) while it was running, which caused the FUSE-based anon/system > mountpoint to be left over. > > To fix this, you can unmount the system mount point manually before > starting sysregd again: > > # fusermount -u /var/run/xenomai/anon/system > > We can probably do better with graceful exit and cleaning up left overs. > I'll look at this. > > -- > Philippe. > -- Helder Daniel UALG - FCT DEEI http://w3.ualg.pt/~hdaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: xenomaiRegistryCheck.tar.gz Type: application/x-gzip Size: 1425 bytes Desc: not available URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150304/2070e2ec/attachment.bin> _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
