[Xorp-users] Error writing to routing socket: No such process

[Ben Greear]

On 07/28/2010 12:44 PM, Edwin Schokkenbroek wrote:
>
> On Jul 28, 2010, at 9:35 PM, Ben Greear wrote:
>
>> On 07/28/2010 12:18 PM, Edwin Schokkenbroek wrote:
>>> Hello Ben,
>>>
>>> Thank you for your quick response. I already started to experiment with xopr.ct. I ran into it when trying to solve the errors mentioned earlier.
>>>
>>> 010/07/28 21:07:59  ERROR xorpsh:1807 XRL +468 xrl_router.cc get_sender ] Could not create XrlPFSender for protocol = "unix" address = ":var:tmp:xrl.POm5vR"
>>> [ 2010/07/28 21:07:59  ERROR xorpsh:1807 LIBCOMM +831 comm_user.c comm_connect_unix ] Error connecting to unix socket.  Path: /var/tmp/xrl.cwKcRV.  Error: Permission denied
>>> [ 2010/07/28 21:07:59  ERROR xorpsh:1807 XRL +63 xrl_pf_factory.cc create_sender ] XrlPFSenderFactory::create failed: XrlPFConstructorError from line 131 of xrl_pf_unix.cc: Could not connect to /var/tmp/xrl.cwKcRV
>>>
>>> (These messages are going on forever.)
>>>
>>> The message is clear, and easy to explain,  xorp_rtrmgr is started as the root user. However I start the xorpsh as a other user with less privileges.
>>> When I change the ownership of the file in /var/tmp I'm able to login.
>>>
>>> But when I reboot the machine or I start another vimage (or jail with vnet ) I ran into the same problem again. I guess xorp_rtrmgr is creating the files as root.
>>>
>>> Since the messages appear very quickly I'm not able to see the messages when xorp_rtrmgr is started.
>>
>> I could add an option to create the /var/tmp/ file as read/write by everyone (or maybe
>> just the xorp group), I suppose.
>
> I think a xorp group is the most clean way . read/write everyone could maybe introduce a security issue ?
>
> The dir /var/tmp is already world writeable permissions (on my system):
>
> drwxrwxrwt  3 beheer  wheel  2048 Jul 28 21:27 /var/tmp/
>
>>
>> One thing I just noticed:  I have 126,000 or so xrl files in /var/tmp/
>> on one of my test machines.
>>
>> That can't be good :P
>
> Nope....  hopefully the filesystem has enough inodes ;-)
>>
>> Aside from the permissions issue, does xorp.ct fix that other bug you reported?
>
> Well I managed to start one xopr_rtmgr in a vimage,  however the other xorp_rtr_mgr seems to hang.
>
> I recieve a lot of messages :

The messages look OK to me (some seem scary, but I've been seeing them for years
and they don't seem to cause harm, so I haven't bothered to track them down yet).

The one issue that might be a problem is the timer expiry warnings, but if the
system is slow/virtual, that might be normal and it will probably work better
once all the processes are started.

I don't know anything about vimages, but you might have to do some tricks
to get two xorps to run on the same OS at the same time.  If the vimage looks
like a separate machine (like vmware, xemu, etc), then it should be OK.

For the process that hangs, what makes you think so?  Can you run 'strace' or
whatever the BSD equiv is to see if it's really hung in a system call, or
'top' to see if it's spinning 100% CPU?

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com