[Spread-users] Spread as a real daemon

[Yair Amir]

John,

If you give the singleton machine its IP address and multicast address
that you will later use, it will work. This machine will not talk with
the others (using Spread 4 only) until you put it in the same configuration
file and the others' configuration file is also updated to the same.
If you follow this approach, the daemon on the singleton machine will
not exit. I think this should solve your problem - and that is the
way we envisioned it to happen.

In general, if you replace the IP address / multicast address of
a daemon, it has to exit because it does not have the same identity
anymore. Spread is a strong-semantics messaging system and the
semantic guarantees have to be kept even during these configuration
changes.

Cheers,

	:) Yair.

John Robinson wrote:
> Hi all,
> 
> We are looking to install the spread daemon as a real Linux daemon - you 
> know, starts on reboot, can be cycled while the system is running, 
> detaches itself from stdin/out/err.  We can do all this with a /etc/rc.d 
> shell script riding above it [can share this if anyone is interested]. 
> Target platforms are RHEL4, Fedora, and SuSe, if that matters.
> 
> Here's the issue:
> 
> We are happily using the cluster-reconfiguration feature of Spread 4.0. 
>  This is one problem we have bumped into:
> 
> We would like to configure a new machine to add to the cluster by 
> installing spread on it and starting its daemon, say with just a private 
> Spread segment, then adding it to the existing segment with spmonitor. 
> However, if we do this, it won't join the pre-existing segment without 
> cycling its daemon, which requires root access, which we would prefer to 
> avoid.  In other words, if there are two separate spread segments (one 
> the singleton new machine), and we try to get them to combine into one 
> segment with a matched config file, it doesn't succeed.  We have thought 
> of a way to make this work by watching for the spread.conf file to 
> appear, and then firing up the daemon at the right time (this would be a 
> separete daemon-watching daemon, if you will).  Doesn't seem elegant.
> 
> What would help out here, and we have been tempted to put this into the 
> spread daemon, is if the daemon can start with a non-existant config 
> file (perhaps with an extra switch to say "keep running if the config 
> file isn't there yet"), and then have it just wake up periodically to 
> wait for the config file to appear and then go through all the rest of 
> its initialization to join the (newly-expanded) segment.
> 
> Have we missed something obvious?  Has someone wrestled with this issue?
> 
> Many thanks; the product has been working great for us (thankfully, we 
> have necesary flow control =:).
> 
> /jr
> 
> 
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
> 
>