tahoe-lafs/trac-2024-07-25

need more reliable way to determine when introducer is ready when started from a script (than polling for creation of introducer.furl) #275

New issue

Open

opened 2008-01-14 01:25:44 +00:00 by zooko · 2 comments

zooko commented

2008-01-14 01:25:44 +00:00

Owner

Arc is writing a script to automatically create a Tahoe grid (in order to automatically test tahoe-fuse.py). He was confused by the fact that introducer.furl is only sometimes present after starting an introducer:

0 /home/arc/trunk/contrib/fuse$ rm -rf introducer_dir/;rm -rf client_dir;PATH=${PWD}/../../bin/:${PATH} ./fusetest.py 
introducer created in introducer_dir
STARTING /home/arc/trunk/contrib/fuse/introducer_dir
introducer node probably started
0 /home/arc/trunk/contrib/fuse$ ls introducer_dir/
logs  my_nodeid  private  tahoe-introducer.tac  twistd.pid
0 /home/arc/trunk/contrib/fuse$ rm -rf introducer_dir/;rm -rf client_dir;PATH=${PWD}/../../bin/:${PATH} ./fusetest.py 
introducer created in introducer_dir
STARTING /home/arc/trunk/contrib/fuse/introducer_dir
introducer node probably started
0 /home/arc/trunk/contrib/fuse$ ls introducer_dir/
introducer.furl  logs       private               twistd.pid
introducer.port  my_nodeid  tahoe-introducer.tac

This is related to #71 -- ""client node probably started""

Arc is writing a script to automatically create a Tahoe grid (in order to automatically test `tahoe-fuse.py`). He was confused by the fact that introducer.furl is only *sometimes* present after starting an introducer: ``` 0 /home/arc/trunk/contrib/fuse$ rm -rf introducer_dir/;rm -rf client_dir;PATH=${PWD}/../../bin/:${PATH} ./fusetest.py introducer created in introducer_dir STARTING /home/arc/trunk/contrib/fuse/introducer_dir introducer node probably started 0 /home/arc/trunk/contrib/fuse$ ls introducer_dir/ logs my_nodeid private tahoe-introducer.tac twistd.pid 0 /home/arc/trunk/contrib/fuse$ rm -rf introducer_dir/;rm -rf client_dir;PATH=${PWD}/../../bin/:${PATH} ./fusetest.py introducer created in introducer_dir STARTING /home/arc/trunk/contrib/fuse/introducer_dir introducer node probably started 0 /home/arc/trunk/contrib/fuse$ ls introducer_dir/ introducer.furl logs private twistd.pid introducer.port my_nodeid tahoe-introducer.tac ``` This is related to #71 -- ""client node probably started""

tahoe-lafs added the

labels 2008-01-14 01:25:44 +00:00

tahoe-lafs added this to the eventually milestone 2008-01-14 01:25:44 +00:00

warner commented

2008-01-14 17:33:12 +00:00

Author

Owner

If there was no serious error (like missing libraries), there will be a introducer.furl present some time after starting the introducer, it's just a matter of when. "right away" is too soon.

You have a few options:

tail the logfile, watch for a message that indicates the introducer.furl file has been created.
If there is not currently such a message, add one.
poll the directory every 100ms until the file exists and can be read and contains a valid furl.
Since we write the furl with a newline, just wait until there's a complete line in the file.
wait one second and hope that was enough.

The src/allmydata/test/test_system.py test runs the introducer in the same process as the test harness, so it can do node.when_tub_ready() and get immediate notification. That isn't easy to do from outside the process.

In practical deployments, this doesn't matter, since the introducer is one of those long-running processes that is generally constructed and launched by a human, well before any clients need to learn the introducer.furl, so running 'tahoe start' and then manually doing 'cat introducer.furl' is sufficient. For an automated setup process written in python, I'd do the poll-every-10Hz thing. For one written in bash, I guess I'd do the same.

If there was no serious error (like missing libraries), there *will* be a introducer.furl present some time after starting the introducer, it's just a matter of when. "right away" is too soon. You have a few options: * tail the logfile, watch for a message that indicates the introducer.furl file has been created. If there is not currently such a message, add one. * poll the directory every 100ms until the file exists and can be read and contains a valid furl. Since we write the furl with a newline, just wait until there's a complete line in the file. * wait one second and hope that was enough. The src/allmydata/test/test_system.py test runs the introducer in the same process as the test harness, so it can do node.when_tub_ready() and get immediate notification. That isn't easy to do from outside the process. In practical deployments, this doesn't matter, since the introducer is one of those long-running processes that is generally constructed and launched by a human, well before any clients need to learn the introducer.furl, so running 'tahoe start' and then manually doing 'cat introducer.furl' is sufficient. For an automated setup process written in python, I'd do the poll-every-10Hz thing. For one written in bash, I guess I'd do the same.

tahoe-lafs added

minor

and removed

major

labels 2008-02-06 02:16:28 +00:00

tahoe-lafs modified the milestone from eventually to undecided

2008-06-01 20:47:19 +00:00

tahoe-lafs added

code-nodeadmin

and removed

operational

labels 2011-05-21 16:28:35 +00:00

tahoe-lafs changed title from ~~timing of creation of introducer.furl~~ to need more reliable way to determine when introducer is ready when started from a script (than polling for creation of introducer.furl)

2011-05-21 16:28:35 +00:00

Brian Warner <warner@lothar.com> commented

2017-09-19 17:20:49 +00:00

Author

Owner

In 04b34b6/trunk:

Merge PR417: rewrite tahoe start/stop/daemonize

* refs ticket:1148 (splits up startstop_node, improves coverage)
* refs ticket:275 ('start' probably doesn't exit until furl is written)
* refs ticket:1121 (probably improves coverage)
* refs ticket:1377 (probably fixed)
* refs ticket:2149 (might influence, probably won't fix)
* refs ticket:719 (probably improved)

In [04b34b6/trunk](/tahoe-lafs/trac-2024-07-25/commit/04b34b6fd2bb112942d2cb8ea41ef11ee4c72347): ``` Merge PR417: rewrite tahoe start/stop/daemonize * refs ticket:1148 (splits up startstop_node, improves coverage) * refs ticket:275 ('start' probably doesn't exit until furl is written) * refs ticket:1121 (probably improves coverage) * refs ticket:1377 (probably fixed) * refs ticket:2149 (might influence, probably won't fix) * refs ticket:719 (probably improved) ```