Plumber both posts a service to /srv and sets a $plumbsrv environment variable. Our libplumb no longer uses $plumbsrv and nothing else does. It's a silly hack; rc doesn't update /env immediately, and scripts, which for instance set up subrios, cannot rely on it to clean up the plumber at the end. Instead, add the option to specify a srvname, actually check for some common errors and print a usage string. Thanks to Ori for input and a preliminary patch. Thoughts? Cheers, qwx diff 87a823332f9eaa4ff1e72f8524f6e59d1cc4f407 uncommitted --- a//sys/man/4/plumber +++ b//sys/man/4/plumber @@ -6,6 +6,9 @@ [ .B -p .I plumbing +] [ +.B -s +.I srvname ] .SH DESCRIPTION The @@ -31,11 +34,17 @@ and a set of output .I ports for dispatching messages to applications. +.PP The service is also published as a .IR srv (4) -file, named in -.BR $plumbsrv , +file, +.IR srvname , for mounting elsewhere. +By default, its name is a dot-separated concatenation +of the program's name and a process id. +A different one can be specified via the +.B -s +option. .PP Programs use .B write --- a//sys/src/cmd/plumb/fsys.c +++ b//sys/src/cmd/plumb/fsys.c @@ -218,9 +218,10 @@ clock = getclock(); if(cexecpipe(&mntfd, &srvfd) < 0) error("can't create pipe: %r"); - sprint(srvfile, "/srv/plumb.%s.%d", user, getpid()); - if(putenv("plumbsrv", srvfile) < 0) - error("can't write $plumbsrv: %r"); + if(srvname == nil) + snprint(srvfile, sizeof(srvfile), "/srv/plumb.%s.%d", user, getpid()); + else + snprint(srvfile, sizeof(srvfile), "/srv/%s", srvname); fd = create(srvfile, OWRITE|OCEXEC|ORCLOSE, 0600); if(fd < 0) error("can't create /srv file: %r"); --- a//sys/src/cmd/plumb/plumber.c +++ b//sys/src/cmd/plumb/plumber.c @@ -15,6 +15,7 @@ int printerrors=1; jmp_buf parsejmp; char *lasterror; +char *srvname; void makeports(Ruleset *rules[]) @@ -38,6 +39,13 @@ } void +usage(void) +{ + fprint(2, "usage: %s [-p plumbfile] [-s srvname]\n", argv0); + exits("usage"); +} + +void threadmain(int argc, char *argv[]) { char buf[512]; @@ -48,7 +56,13 @@ ARGBEGIN{ case 'p': - plumbfile = ARGF(); + plumbfile = EARGF(usage()); + break; + case 's': + srvname = EARGF(usage()); + break; + default: + usage(); break; }ARGEND --- a//sys/src/cmd/plumb/plumber.h +++ b//sys/src/cmd/plumb/plumber.h @@ -92,3 +92,4 @@ char *lasterror; char **ports; int nports; +char *srvname;
yes, please. named srv has long been needed
I didn't look at the patch, but yes, please do this. In the past I sometimes had to rename the srv file...
Quoth qwx@sciops.net:
> Plumber both posts a service to /srv and sets a $plumbsrv environment
> variable. Our libplumb no longer uses $plumbsrv and nothing else
> does. It's a silly hack; rc doesn't update /env immediately, and
> scripts, which for instance set up subrios, cannot rely on it to
> clean up the plumber at the end.
>
> Instead, add the option to specify a srvname, actually check for some
> common errors and print a usage string.
>
> Thanks to Ori for input and a preliminary patch. Thoughts?
>
> Cheers,
> qwx
>
Since this removes '$srvname': is anyone using it at the moment?
otherwise, this looks good to me.
Quoth qwx@sciops.net:
> It's a silly hack; rc doesn't update /env immediately, and
> scripts, which for instance set up subrios, cannot rely on it to
> clean up the plumber at the end.
Adding also the usual -m mount flag to plumber would perhaps solve
this problem for you more naturally.
> Quoth qwx@sciops.net:
> > It's a silly hack; rc doesn't update /env immediately, and
> > scripts, which for instance set up subrios, cannot rely on it to
> > clean up the plumber at the end.
>
> Adding also the usual -m mount flag to plumber would perhaps solve
> this problem for you more naturally.
I'm not sure I understand what you mean. My problem is that a
service file is posted which I can't remove if I don't know its
name. The mount point on the other hand is always /mnt/plumb.
Did I understand you correctly?
Thanks,
qwx
Quoth qwx@sciops.net:
> My problem is that a service file is posted which I can't remove
> if I don't know its name.
My point is that with the -m flag you might not need to post the
srv file to start with and the plumber process would go away
together with the namespace.
This assumes you don't need the srv file.
You might.
I usually don't.
> Quoth qwx@sciops.net:
The mount point on the other hand is always /mnt/plumb.
Wow, I'm drunk and dumb and stupid. Yes, of course the -m flag
alone doesn't change anything.
The option I implied is only posting the srv file when requested
whence you wouldn't need to clean it up afterwards in the usual
case.
Sorry for confusion.
> My point is that with the -m flag you might not need to post the > srv file to start with and the plumber process would go away > together with the namespace. [...] > The option I implied is only posting the srv file when requested > whence you wouldn't need to clean it up afterwards in the usual > case. Yeah, I see what you mean. Right now, the plumber doesn't have an option not to post a srv file, and I'm not sure -m will work nicely because libplumb relies on it being mounted there. It makes sense that $plumbsrv be ejected, and I don't see anyone or anything using it; on the other hand, I'm not sure we can only optionally post a service file without breaking people's setups. I think being able to specify another name is enough. The program doesn't use postmountsrv(2) or other srv(2) shit, so we'd have to add more code for an option to disable this or refactor or something, I don't know. I propose that we just push the patch as is unless someone sees a better solution. Thanks! qwx
> Yeah, I see what you mean. Right now, the plumber doesn't have an
> option not to post a srv file, and I'm not sure -m will work nicely
> because libplumb relies on it being mounted there.
That's bullshit, it's only the default (cf. plumb(2)). Sorry!
qwx
Pushed as is. Thanks for the input, everyone! qwx