Mailing List Archive

On Tue, 14 Oct 2003 sowmini.varadhan@sun.com wrote:

> Here's a bug in the code that's been bothering me:
>
> It's possible to start multiple copies of these daemons without
> even a whimper, sometimes. For example,
>
> # ./ospfd -f /usr/local/etc/ospfd.conf &
> [1] 6173

[snip]

> # ./ospfd -f /usr/local/etc/ospfd.conf &
> [2] 6174

[snip]

> The second one actually failed to open the raw socket, but notice
> the lack of any warnings/errors..

ah eek. yes.

> and, if you had a conf file that asks for things to be logged to a
> file, it's not really possible to figure out which incarnation is
> printing what. Another annoying effect is that doing a 'ps' leaves
> you wondering which is the useful daemon, and which ones are just
> hanging out.

yes.

> So, a simple solution, in the case of routing protocol daemons is
> to bail out if they can't open the raw socket- if they can't
> communicate with their peers in the domain, no point sitting around
> and doing nothing.

possibly.

> In the case of zebra itself, one doesn't really have a raw socket,

On Linux you'd have the netlink socket, and its some type socket on
solaris
too isnt it?

> but, if we are using a TCP/IP vty_port, the call to bind() from
> vty_serv_sock will fail, and we can bail out at that point. This
> solution would also kick in for the routing daemons, and I don't
> really see the harm in that (comments??)

no. i might depend on zebra to set a crucial static route for me. vty
socket might not be created, but kernel socket might well be
functional. ditto for protocol daemons.

to exit it should be serious. eg, vty exits if no conf file is found.

> But that still leaves me with 2 unsolved cases:
>
> 1. what if I start up 2 copies of zebra,
> # zebra -P port1
> # zebra -P port2
> My opinion is that this is probably ok- whoever's doing it
> must have a good (though mysterious) reason, and they shouldn't
> be forbidden from it.

could be very strange.

> 2. what if vtysh is being used instead of TCP/IP? The call to bind()
> from vty_serv_un() is not going to fail for the second incarnation.

> bind();
> /* try to write lock the file and bail out if unsuccesful */

well, i dont think you can bind a unix socket to a file that exists -
however... vty /may/ unlink the socket first (orphaning the first
processes socket), and then call bind - which is what vty_serv_un
does, which i guess is what you meant. :)

> what's the most portable system call for file-locking? fcntl?
> flock?

flock is deprecated i think. use fcntl - presuming it works on pipes.

> --Sowmini

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
If it smells it's chemistry, if it crawls it's biology, if it doesn't work
it's physics.

On Tue, 2003-10-14 at 16:45, Paul Jakma wrote:

> >
> > 1. what if I start up 2 copies of zebra,
> > # zebra -P port1
> > # zebra -P port2
> > My opinion is that this is probably ok- whoever's doing it
> > must have a good (though mysterious) reason, and they shouldn't
> > be forbidden from it.
>
> could be very strange.

Virtual routing? IpInfusion? :)

That said, does anybody utilize multiple instances of routing daemons? I
read some place that Quagga OSPF does not support it, but BGP does.

Regards,
/Amit
--
.| Amit Kucheria |.
...| Wireless Systems Engineer |...
.....| Metric Systems Corp., San Diego, CA |.....
......| www.metricsystems.com |......

On Tue, 14 Oct 2003, Amit Kucheria wrote:

> Virtual routing?

:)

thats an interesting idea actually, and probably why people howled
when i wondered whether we should just remove the TCP-Zserv support.

> IpInfusion? :)

what do you mean? :)

> That said, does anybody utilize multiple instances of routing
> daemons? I read some place that Quagga OSPF does not support it,

OSPF wouldnt no. it could be made to.

ripd no longer will either, once Sowmini's patches go in.

> but BGP does.

yes, bgpd could, if you made sure to bind the vty TCP sockets to
different addresses or ports. (though, why bother - bgp supports
multiple instances internally).

> Regards,
> /Amit

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
APL is a natural extension of assembler language programming;
...and is best for educational purposes.
-- A. Perlis

Amit Kucheria wrote:

> Virtual routing? IpInfusion? :)
>
> That said, does anybody utilize multiple instances of routing daemons? I
> read some place that Quagga OSPF does not support it, but BGP does.

Never done it, although way back it seemed to have been a noted feature
of the modular design of zebra... I can't really see how it can work
though. Neither can multiple instances of a protocol be identified
uniquely by zebra's RIB, so unless they connect to distinct instances of
zebra it seems quite useless; nonetheless, multiple instances of zebra
seem just as useless, as they cannot reflect each other's routes on the
kernel. So, go figure... ;->

There is, however, a certain functionality to which I believe multiple
instances are desirable, and it is serving as backup instances for zebra
and/or routing daemons, residing on redundant portions of the same
machine or distinct machines. However, current zebra/quagga does not
support it, and anyway it requires a detailed design of the redundancy
relation, algorithm and protocol, so that's pretty much sci-fi at the
moment.

Gilad

> > In the case of zebra itself, one doesn't really have a raw socket,
>
> On Linux you'd have the netlink socket, and its some type socket on
> solaris
> too isnt it?

Isn't this the socket to read/write routing info from/to the kernel?
There's no bind() associated with the socket (it's designed for
multiple listeners, so there's no reason why 2 processes to
be able to succesfully open the socket), so that won't help.

> > but, if we are using a TCP/IP vty_port, the call to bind() from
> > vty_serv_sock will fail, and we can bail out at that point. This
> > solution would also kick in for the routing daemons, and I don't
> > really see the harm in that (comments??)
>
> no. i might depend on zebra to set a crucial static route for me. vty
> socket might not be created, but kernel socket might well be
> functional. ditto for protocol daemons.

Well, if there's already a zebra listening at the vty port, you should
be using that zebra to set up the crucial static route.

when you have 2 zebras sitting around, they could be stepping on
each other's work. It's not a Good Thing.

> > 2. what if vtysh is being used instead of TCP/IP? The call to bind()
> > from vty_serv_un() is not going to fail for the second incarnation.
>
> > bind();
> > /* try to write lock the file and bail out if unsuccesful */
>
> well, i dont think you can bind a unix socket to a file that exists -

Unfortunately, the standard practice (also followed by zebra) is to
do an unlink() before the bind.

Reason for this is that the file may already exist from a previous
incarnation of zebra that has now terminated.

So that doesn't help.

> > what's the most portable system call for file-locking? fcntl?
> > flock?
>
> flock is deprecated i think. use fcntl - presuming it works on pipes.

Let me give it a try.

--Sowmini

On Tue, 2003-10-14 at 17:22, Paul Jakma wrote:
> On Tue, 14 Oct 2003, Amit Kucheria wrote:
>
> > Virtual routing?
> thats an interesting idea actually, and probably why people howled
> when i wondered whether we should just remove the TCP-Zserv support.

I have done a different virtual routing implementation based on
modifications to the linux IP stack.

> > IpInfusion? :)
>
> what do you mean? :)

Check out the products of ipinfusion. Zebra was later modified to become
ZebOS which is touted as a PC-based routing engine. The beauty of the
virtual routing concept is that you can think of it in terms of virtual
hosting of websites.

Consider being an ISP/Telecom provider with 100 corporate clients. Now
think of setting up a few boxes and virtually partitioning them so that
each client's routing needs are served by a virtual router. The physical
interfaces on the boxes are partitioned amongst the virtual router
instances - cannot be shared. But each virtual router has separate RIB
yada yada..

> > That said, does anybody utilize multiple instances of routing
> > daemons? I read some place that Quagga OSPF does not support it,
>
> OSPF wouldnt no. it could be made to.
>
> ripd no longer will either, once Sowmini's patches go in.

hmm. I wonder if its time to fragment ripd into standalone ripd and
virtual routing ripd daemon? Though I doubt that many people even use it
anymore.

> > but BGP does.
>
> yes, bgpd could, if you made sure to bind the vty TCP sockets to
> different addresses or ports. (though, why bother - bgp supports
> multiple instances internally).

See virtual routing above.

/Amit
--
.| Amit Kucheria |.
...| Wireless Systems Engineer |...
.....| Metric Systems Corp., San Diego, CA |.....
......| www.metricsystems.com |......

On Tue, 2003-10-14 at 22:06, Gilad Arnold wrote:
> Amit Kucheria wrote:
>
> > Virtual routing? IpInfusion? :)
> >
> > That said, does anybody utilize multiple instances of routing daemons? I
> > read some place that Quagga OSPF does not support it, but BGP does.
>
> Never done it, although way back it seemed to have been a noted feature
> of the modular design of zebra... I can't really see how it can work
> though. Neither can multiple instances of a protocol be identified
> uniquely by zebra's RIB, so unless they connect to distinct instances of
> zebra it seems quite useless; nonetheless, multiple instances of zebra
> seem just as useless, as they cannot reflect each other's routes on the
> kernel. So, go figure... ;->

Thats the whole point!! They should NOT reflect each other's routes.
Multiple forwarding tables, one for each virtual router (zebra+protocol
daemons).

Please see previous email about virtual routing.

> There is, however, a certain functionality to which I believe multiple
> instances are desirable, and it is serving as backup instances for zebra
> and/or routing daemons, residing on redundant portions of the same
> machine or distinct machines. However, current zebra/quagga does not
> support it, and anyway it requires a detailed design of the redundancy
> relation, algorithm and protocol, so that's pretty much sci-fi at the
> moment.

I fail to see the use of multiple instances on a single machine. If the
machine fails, you lose everything.

On different machines, that seems to be akin to VRRP, so that loss of
one machine does not affect routing services.

/Amit

--
.| Amit Kucheria |.
...| Wireless Systems Engineer |...
.....| Metric Systems Corp., San Diego, CA |.....
......| www.metricsystems.com |......

Just to remind everyone, I have a virtual routing and forwarding
project for linux. http://linux-vrf.sf.net/

It is fully functional and it just needs someone to write the quagga
CLI for it. (actually I have a patch laying around that was sent
to me which provides some of this functionallilty, I have never tried to
integrate it into quagga)

On Wed, Oct 15, 2003 at 09:27:27AM -0700, Amit Kucheria wrote:
> On Tue, 2003-10-14 at 17:22, Paul Jakma wrote:
> > On Tue, 14 Oct 2003, Amit Kucheria wrote:
> >
> > > Virtual routing?
> > thats an interesting idea actually, and probably why people howled
> > when i wondered whether we should just remove the TCP-Zserv support.
>
> I have done a different virtual routing implementation based on
> modifications to the linux IP stack.
>
> > > IpInfusion? :)
> >
> > what do you mean? :)
>
> Check out the products of ipinfusion. Zebra was later modified to become
> ZebOS which is touted as a PC-based routing engine. The beauty of the
> virtual routing concept is that you can think of it in terms of virtual
> hosting of websites.
>
> Consider being an ISP/Telecom provider with 100 corporate clients. Now
> think of setting up a few boxes and virtually partitioning them so that
> each client's routing needs are served by a virtual router. The physical
> interfaces on the boxes are partitioned amongst the virtual router
> instances - cannot be shared. But each virtual router has separate RIB
> yada yada..
>
> > > That said, does anybody utilize multiple instances of routing
> > > daemons? I read some place that Quagga OSPF does not support it,
> >
> > OSPF wouldnt no. it could be made to.
> >
> > ripd no longer will either, once Sowmini's patches go in.
>
> hmm. I wonder if its time to fragment ripd into standalone ripd and
> virtual routing ripd daemon? Though I doubt that many people even use it
> anymore.
>
> > > but BGP does.
> >
> > yes, bgpd could, if you made sure to bind the vty TCP sockets to
> > different addresses or ports. (though, why bother - bgp supports
> > multiple instances internally).
>
> See virtual routing above.
>
> /Amit
> --
> .| Amit Kucheria |.
> ...| Wireless Systems Engineer |...
> .....| Metric Systems Corp., San Diego, CA |.....
> ......| www.metricsystems.com |......



> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev


--
James R. Leu
jleu@mindspring.com

On Wed, 2003-10-15 at 09:43, James R. Leu wrote:
> Just to remind everyone, I have a virtual routing and forwarding
> project for linux. http://linux-vrf.sf.net/
>
> It is fully functional and it just needs someone to write the quagga
> CLI for it. (actually I have a patch laying around that was sent
> to me which provides some of this functionallilty, I have never tried to
> integrate it into quagga)

I had a look at it a while back and it seemed half-baked. You seem to be
making lots of progress! :)

Why don't you send the patch to the quagga-dev list? You might find
somebody looking for this feature and might help in writing the CLI.

Regards,
/Amit
--
.| Amit Kucheria |.
...| Wireless Systems Engineer |...
.....| Metric Systems Corp., San Diego, CA |.....
......| www.metricsystems.com |......

Hi James,

On Wed, 15 Oct 2003, James R. Leu wrote:

> Just to remind everyone, I have a virtual routing and forwarding
> project for linux. http://linux-vrf.sf.net/
>
> It is fully functional and it just needs someone to write the
> quagga CLI for it. (actually I have a patch laying around that was
> sent to me which provides some of this functionallilty, I have
> never tried to integrate it into quagga)

Yes, its very interesting, along with the MPLS work you (?) have done
too. What I'm curious about is what the Linux kernel will do wrt to
your work and MPLS/VRF. Have you spoken to DM at all?

NB: Perforce? :)

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Thus spake the master programmer:
"When a program is being tested, it is too late to make design changes."
-- Geoffrey James, "The Tao of Programming"

On Wed, 15 Oct 2003 sowmini.varadhan@sun.com wrote:

> Isn't this the socket to read/write routing info from/to the
> kernel?

yes, I mean failure to open this socket is a condition that should
result in exit().

> There's no bind() associated with the socket (it's designed for
> multiple listeners, so there's no reason why 2 processes to be able
> to succesfully open the socket), so that won't help.

sorry, was referring to what should be an exit condition.

> Well, if there's already a zebra listening at the vty port, you
> should be using that zebra to set up the crucial static route.
>
> when you have 2 zebras sitting around, they could be stepping on
> each other's work. It's not a Good Thing.

hmm.. yes.

> Unfortunately, the standard practice (also followed by zebra) is to
> do an unlink() before the bind.

yep.

> Reason for this is that the file may already exist from a previous
> incarnation of zebra that has now terminated.

another solution perhaps is to use the pid file as the key. And
indeed, lib/pid_output.c does seem to have a pid_output_lock which
tries to get exclusive creat on the pid file and exit otherwise.

so perhaps nothing more needs to be done other than rename
pid_output and pid_output_lock? :)

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
When I was crossing the border into Canada, they asked if
I had any firearms with me. I said, "Well, what do you need?"
-- Steven Wright

On Wed, Oct 15, 2003 at 06:13:04PM +0100, Paul Jakma wrote:
> Hi James,
>
> On Wed, 15 Oct 2003, James R. Leu wrote:
>
> > Just to remind everyone, I have a virtual routing and forwarding
> > project for linux. http://linux-vrf.sf.net/
> >
> > It is fully functional and it just needs someone to write the
> > quagga CLI for it. (actually I have a patch laying around that was
> > sent to me which provides some of this functionallilty, I have
> > never tried to integrate it into quagga)
>
> Yes, its very interesting, along with the MPLS work you (?) have done
> too. What I'm curious about is what the Linux kernel will do wrt to
> your work and MPLS/VRF. Have you spoken to DM at all?

I am as well ;-)

I've spoken to David Miller about my MPLS work. At one point he was
writting his own MPLS implementation, we had words. I've 'ping'd him a
couple of time to see what he plans to do, but I always get the "I'm too busy"
response.

I've posted my VRF patch to net-dev, and I didn't get much of a response.

Now that plans for 2.7 are being made, I should talk with David Miller again
to see if my work can be included.

>
> NB: Perforce? :)
>

I used it heavily at my previous employer. I really like it's branching and
merging capabilities, plus it is fast. I got an 'open source' licence, so
I can use it.

At my current employer we use Arch (tla) and I've gotten used to the
way it works. It still feels a bit clumsy compared to p4, but it
is getting better. Despite Arch being a little clumsy, I think it is the
best open source revision control package availble (no offence to the SVN
people out there).

> regards,
> --
> Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
> warning: do not ever send email to spam@dishone.st
> Fortune:
> Thus spake the master programmer:
> "When a program is being tested, it is too late to make design changes."
> -- Geoffrey James, "The Tao of Programming"

--
James R. Leu

> another solution perhaps is to use the pid file as the key. And
> indeed, lib/pid_output.c does seem to have a pid_output_lock which
> tries to get exclusive creat on the pid file and exit otherwise.
>
> so perhaps nothing more needs to be done other than rename
> pid_output and pid_output_lock? :)

yeah, I thought about that, but the daemons also allow the pid_file
as a command-line argument, so 2 daemons could completely miss each
other's existence because they are locking the wrong file.

I'm leaning towards locking a .lock extension to the vtysh file.
e.g., /var/run/zebra.vty.lock. Opinions?

--Sowmini

On Wed, 15 Oct 2003, James R. Leu wrote:

> I am as well ;-)
>
> I've spoken to David Miller about my MPLS work. At one point he
> was writting his own MPLS implementation, we had words.

Yeah, I noticed a few bk changelogs from him had "[MPLS]" as the
subject :)

> I've 'ping'd him a couple of time to see what he plans to do, but I
> always get the "I'm too busy" response. I've posted my VRF patch to
> net-dev, and I didn't get much of a response.

ah well.

> Now that plans for 2.7 are being made, I should talk with David
> Miller again to see if my work can be included.

Yeah, or at least find out which way DM thinks it should be done :)

Anyway, yes, we're very curious about which way VRF support is going
to go.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Think lucky. If you fall in a pond, check your pockets for fish.
-- Darrell Royal

On Wed, 15 Oct 2003 sowmini.varadhan@sun.com wrote:

> yeah, I thought about that, but the daemons also allow the pid_file
> as a command-line argument, so 2 daemons could completely miss each
> other's existence because they are locking the wrong file.

but if the user specifies seperate lock file arguments, then we can
presume they know what they want, no? (perhaps we should also have a
vty unix socket path argument).

> I'm leaning towards locking a .lock extension to the vtysh file.
> e.g., /var/run/zebra.vty.lock. Opinions?

I'd go with pid file lock and add an argument to specify vty socket.
Then per default, daemons wont start twice, while still allowing user
to 'try' to run daemons twice.

> --Sowmini

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
FORTRAN is a good example of a language which is easier to parse
using ad hoc techniques.
-- D. Gries
[What's good about it? Ed.]

> but if the user specifies seperate lock file arguments, then we can
> presume they know what they want, no?

Ok, I'll buy that.

> (perhaps we should also have a vty unix socket path argument).

perhaps, but I'm not going to try to attack that right now.

Here's the patch with the fixes:

lib/vty.c
- exit if vty_serv_sock cannot create a vty endpoint.
- fixed a couple of warnings (in vty_save_cwd) on the side.

lib/pid_output.c
- make pid_output call pid_output_lock.
- do real file-locking, instead of getting confused by crud
left over from previous runs of the daemon.

ospfd/ospf_network.c
- exit if raw socket cannot be created

===================================================================
RCS file: ospfd/ospf_network.c,v
retrieving revision 1.2
diff -uwb -r1.2 ospfd/ospf_network.c
--- ospfd/ospf_network.c 2003/06/04 13:59:39 1.2
+++ ospfd/ospf_network.c 2003/10/17 14:28:05
@@ -166,8 +166,8 @@
if ( ospfd_privs.change (ZPRIVS_LOWER) )
zlog_err ("ospf_sock_init: could not lower privs, %s",
strerror (errno) );
- zlog_warn ("ospf_read_sock_init: socket: %s", strerror (errno));
- return -1;
+ zlog_err ("ospf_read_sock_init: socket: %s", strerror (errno));
+ exit(-1);
}


===================================================================
RCS file: lib/pid_output.c,v
retrieving revision 1.1.1.1
diff -uwb -r1.1.1.1 lib/pid_output.c
--- lib/pid_output.c 2002/12/13 20:15:29 1.1.1.1
+++ lib/pid_output.c 2003/10/17 17:34:43
@@ -21,10 +21,15 @@
*/

#include <zebra.h>
+#include <fcntl.h>
+#include <log.h>
+
+pid_t pid_output_lock(char *);

pid_t
pid_output (char *path)
{
+#ifndef F_WRLCK
FILE *fp;
pid_t pid;

@@ -38,6 +43,9 @@
return -1;
}
return pid;
+#else
+ return pid_output_lock(path);
+#endif
}

pid_t
@@ -46,32 +54,35 @@
int tmp;
int fd;
pid_t pid;
- char buf[16], *p;
+ char buf[16];
+ struct flock lock;

pid = getpid ();

- fd = open (path, O_RDWR | O_CREAT | O_EXCL, 0644);
- if (fd < 0)
- {
- fd = open (path, O_RDONLY);
+#ifdef F_WRLCK
+ fd = open (path, O_RDWR | O_CREAT, 0644);
if (fd < 0)
- fprintf (stderr, "Can't creat pid lock file, exit\n");
- else
{
- read (fd, buf, sizeof (buf));
- if ((p = index (buf, '\n')) != NULL)
- *p = 0;
- fprintf (stderr, "Another process(%s) running, exit\n", buf);
- }
+ zlog_err( "Can't creat pid lock file %s (%s), exit",
+ path, strerror(errno));
exit (-1);
}
else
{
+ bzero(&lock, sizeof(lock));
+ lock.l_type = F_WRLCK;
+ lock.l_whence = SEEK_END;
+
+ if (fcntl(fd, F_SETLK, &lock) < 0)
+ {
+ zlog_err("Could not lock pid_file %s, exit", path);
+ exit (-1);
+ }
+
sprintf (buf, "%d\n", (int) pid);
tmp = write (fd, buf, strlen (buf));
- close (fd);
}
-
+#endif
return pid;
}

===================================================================
RCS file: lib/vty.c,v
retrieving revision 1.8
diff -uwb -r1.8 lib/vty.c
--- lib/vty.c 2003/10/15 23:08:55 1.8
+++ lib/vty.c 2003/10/17 14:44:14
@@ -1716,7 +1716,7 @@
}

#if defined(HAVE_IPV6) && !defined(NRL)
-void
+static int
vty_serv_sock_addrinfo (const char *hostname, unsigned short port)
{
int ret;
@@ -1778,11 +1778,12 @@
while ((ainfo = ainfo->ai_next) != NULL);

freeaddrinfo (ainfo_save);
+ return ret;
}
#endif /* HAVE_IPV6 && ! NRL */

/* Make vty server socket. */
-void
+static int
vty_serv_sock_family (const char* addr, unsigned short port, int family)
{
int ret;
@@ -1818,7 +1819,7 @@
/* Make new socket. */
accept_sock = sockunion_stream_socket (&su);
if (accept_sock < 0)
- return;
+ return accept_sock;

/* This is server, so reuse address. */
sockopt_reuseaddr (accept_sock);
@@ -1830,7 +1831,7 @@
{
zlog_warn("can't bind socket");
close (accept_sock); /* Avoid sd leak. */
- return;
+ return ret;
}

/* Listen socket under queue 3. */
@@ -1839,11 +1840,12 @@
{
zlog (NULL, LOG_WARNING, "can't listen socket");
close (accept_sock); /* Avoid sd leak. */
- return;
+ return ret;
}

/* Add vty server event. */
vty_event (VTY_SERV, accept_sock, NULL);
+ return 0;
}

#ifdef VTYSH
@@ -1851,7 +1853,7 @@
#include <sys/un.h>

/* VTY shell UNIX domain socket. */
-void
+static int
vty_serv_un (char *path)
{
int ret;
@@ -1871,7 +1873,7 @@
if (sock < 0)
{
perror ("sock");
- return;
+ return sock;
}

/* Make server socket. */
@@ -1889,7 +1891,7 @@
{
perror ("bind");
close (sock); /* Avoid sd leak. */
- return;
+ return ret;
}

ret = listen (sock, 5);
@@ -1897,7 +1899,7 @@
{
perror ("listen");
close (sock); /* Avoid sd leak. */
- return;
+ return ret;
}

umask (old_mask);
@@ -1915,6 +1917,7 @@
}

vty_event (VTYSH_SERV, sock, NULL);
+ return 0;
}

/* #define VTYSH_DEBUG 1 */
@@ -2012,25 +2015,33 @@
void
vty_serv_sock (const char *addr, unsigned short port, char *path)
{
+ int ret = 0;
+
/* If port is set to 0, do not listen on TCP/IP at all! */
if (port)
{

#ifdef HAVE_IPV6
#ifdef NRL
- vty_serv_sock_family (addr, port, AF_INET);
- vty_serv_sock_family (addr, port, AF_INET6);
+ ret = (vty_serv_sock_family (addr, port, AF_INET) ||
+ vty_serv_sock_family (addr, port, AF_INET6));
#else /* ! NRL */
- vty_serv_sock_addrinfo (addr, port);
+ ret = vty_serv_sock_addrinfo (addr, port);
#endif /* NRL*/
#else /* ! HAVE_IPV6 */
- vty_serv_sock_family (addr,port, AF_INET);
+ ret = vty_serv_sock_family (addr,port, AF_INET);
#endif /* HAVE_IPV6 */
}

+ if (ret < 0)
+ exit (-1);
+
#ifdef VTYSH
- vty_serv_un (path);
+ ret = vty_serv_un (path);
+ if (ret < 0)
+ exit (-1);
#endif /* VTYSH */
+
}

/* Close vty interface. */
@@ -2762,14 +2773,14 @@
void
vty_save_cwd ()
{
- char cwd[MAXPATHLEN];
+ char cwd[MAXPATHLEN], *c = NULL;

- cwd[0] = getcwd (cwd, MAXPATHLEN);
+ c = getcwd (cwd, MAXPATHLEN);

- if (!cwd)
+ if (c == NULL)
{
chdir (SYSCONFDIR);
- cwd[0] = getcwd (cwd, MAXPATHLEN);
+ c = getcwd (cwd, MAXPATHLEN);
}

vty_cwd = XMALLOC (MTYPE_TMP, strlen (cwd) + 1);

Amit Kucheria wrote:

>>Never done it, although way back it seemed to have been a noted feature
>>of the modular design of zebra... I can't really see how it can work
>>though. Neither can multiple instances of a protocol be identified
>>uniquely by zebra's RIB, so unless they connect to distinct instances of
>>zebra it seems quite useless; nonetheless, multiple instances of zebra
>>seem just as useless, as they cannot reflect each other's routes on the
>>kernel. So, go figure... ;->
>
>
> Thats the whole point!! They should NOT reflect each other's routes.
> Multiple forwarding tables, one for each virtual router (zebra+protocol
> daemons).

I see your point, but:

(1) then again, it requires truely orthogonal routing instances in
kernel -- your still can't bind more than one protocol instance to a
single port, can you?

(2) multiple instances of zebra may suggest a very modular approach for
virtual routing, however I think that minor extensions to a single zebra
daemon to support multi-contexts make more sense: you get the actual
notion of a virtual context explicitly addressed by your routing engine,
you may control further aspects of your context by zebra itself
(interface binding, etc), and you get this info distributed to your
routing daemons respectively. Same applies for the routing daemons
themselves -- also seems more at hand (IMO).


>>There is, however, a certain functionality to which I believe multiple
>>instances are desirable, and it is serving as backup instances for zebra
>>and/or routing daemons, residing on redundant portions of the same
>>machine or distinct machines. However, current zebra/quagga does not
>>support it, and anyway it requires a detailed design of the redundancy
>>relation, algorithm and protocol, so that's pretty much sci-fi at the
>>moment.
>
>
> I fail to see the use of multiple instances on a single machine. If the
> machine fails, you lose everything.

All depends on your machine... ;-> if it's an extendable rack that can
allow several forwarding cards in it, but is still conveived as a
unified (self-contained) redundant platform, then you may need this
functionality in zebra. Otherwise, you probably don't.

Gilad

On Fri, 17 Oct 2003 sowmini.varadhan@sun.com wrote:

> > (perhaps we should also have a vty unix socket path argument).
>
> perhaps, but I'm not going to try to attack that right now.

:)

> Here's the patch with the fixes:
>
> lib/vty.c
> - exit if vty_serv_sock cannot create a vty endpoint.

Hmm.. I still dont agree with this. certainly not for exiting if
either tcp or unix socket fails, both /maybe/.... but still, I'd
rather the daemon start up and at least potentially still install
important routes - doesnt matter if i cant configure/monitor it, at
least it means that possibly: i can still access that box or: i can
defer fixing the problem (and attendent restart) till a more
convenient time, where otherwise that might not be true.

> - fixed a couple of warnings (in vty_save_cwd) on the side.

urg, yes doh, fixed a leak with a bug. thanks for spotting it.

> lib/pid_output.c
> - make pid_output call pid_output_lock.
> - do real file-locking, instead of getting confused by crud
> left over from previous runs of the daemon.

thanks. (hmm.. i hope noone runs quagga from nfs :) )

> ospfd/ospf_network.c
> - exit if raw socket cannot be created

thanks.

> +#ifndef F_WRLCK

NB: I've changed this to HAVE_FCNTL and added fcntl to configure.ac
as a function to be checked.

> + bzero(&lock, sizeof(lock));

bzero/bcopy appear not to be very portable, memset/memcpy/etc..
appear more portable.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
The number of computer scientists in a room is inversely proportional
to the number of bugs in their code.