* use of GNATSDB @ 2002-03-27 19:24 Mel Hatzis [not found] ` <15525.34645.542865.70528@habakuk.home.ha-schneider.de> 2002-05-17 5:06 ` Lars Henriksen 0 siblings, 2 replies; 10+ messages in thread From: Mel Hatzis @ 2002-03-27 19:24 UTC (permalink / raw) To: help-gnats I'm trying to setup a separate database instance by adding a line into the share/gnats/databases file and setting the GNATSDB env variable to point to it. I can successfully 'telnet localhost port#' and, say, lockdb, but when I try using pr-edit it ends up locking the default database. Grokking through the code, I find that client_init_gnats in client.c is invoking 'chdb default' because the scanenv function always sets database to 'default' during initialization. My question is..."wouldn't it make more sense to do the equivalent of 'database = getenv ("GNATSDB")' rather than blindly setting it to 'default'? -- Mel Hatzis Juniper Networks Inc. _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <15525.34645.542865.70528@habakuk.home.ha-schneider.de>]
[parent not found: <3CA6046B.1060004@juniper.net>]
[parent not found: <15528.10405.211358.551224@habakuk.home.ha-schneider.de>]
* Re: use of GNATSDB [not found] ` <15528.10405.211358.551224@habakuk.home.ha-schneider.de> @ 2002-04-30 22:18 ` Mel Hatzis 0 siblings, 0 replies; 10+ messages in thread From: Mel Hatzis @ 2002-04-30 22:18 UTC (permalink / raw) To: Hans-Albert; +Cc: help-gnats Looking at the use of the GNATSDB environment variable throughout the code, it seems somewhat ambiguous. On the one hand, it can be set to a database name corresponding to an entry in the databases file, and on the other hand, it can be set to a colon separated tuple defining a 'remote' database, as follows: hostname:portnumber:databasename:username:password I'd like to suggest that two variables be used for these different purposes to cleanly delineate and clearly specify the intended functionality. My proposal is to continue to use GNATSDB as the 'colon separated tuple' and introduce GNATSID to replace the use of GNATSDB in findOrLoadDatabase (in database.c). I've included an earlier email exchange related to the topic below... My apologies if this is not the right forum for such a discussion. -- Mel Hatzis Juniper Networks, Inc. Hans-Albert Schneider wrote: >>>>>>"Mel" == Mel Hatzis <hatzis@juniper.net> writes: >>>>>> > > Mel> I believe I have the latest code...version 1.42 of > Mel> client.c. > > Yes, that's the version I've got, too. > > Mel> The problem occurs around 13 lines from the bottom of > Mel> the scanEnv function... > > Mel> if (*database == NULL) > Mel> { > Mel> *database = xstrdup ("default"); > Mel> } > > Mel> If you look closely, you'll note that even though the > Mel> env. variable is read, it is not used to initialize the > Mel> 'database' variable....and therefore, the lines I've > Mel> pasted above end up setting it to 'default'. > > I see... It is even a bit more complicated: > > If GNATSDB is a colon separated tuple of > hostname:portnumber:databasename:username:password > then "database" gets initialized, but not if it is the name of a > database listed in the "databases" file. > > (The tuple format is described in the manual in "Environment > variables and GNATS tools" in chapter "The GNATS user tools". It > is probably intended for databases that must be accessed across > the net, but are not listed in the "databases" file.) > > Even worse: I do not see how scanEnv deals with a *local* > database at all. > > A workaround seems to be to specify the database name via option > --database or -d. This is passed to client_init_gnats(), then to > scanEnv(), and is left untouched. > > > I don't dare to change the code, because I do not know it good > enough to be sure not to break another place. > > > Hans-Albert > > _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: use of GNATSDB 2002-03-27 19:24 use of GNATSDB Mel Hatzis [not found] ` <15525.34645.542865.70528@habakuk.home.ha-schneider.de> @ 2002-05-17 5:06 ` Lars Henriksen 2002-05-17 5:24 ` Lars Henriksen 2002-05-17 10:33 ` Dirk Bergstrom 1 sibling, 2 replies; 10+ messages in thread From: Lars Henriksen @ 2002-05-17 5:06 UTC (permalink / raw) To: Mel Hatzis; +Cc: help-gnats On Wed, Mar 27, 2002 at 07:21:11PM -0800, Mel Hatzis wrote: > I'm trying to setup a separate database instance by adding a line > into the share/gnats/databases file and setting the GNATSDB env > variable to point to it. I can successfully 'telnet localhost port#' > and, say, lockdb, but when I try using pr-edit it ends up locking > the default database. I can't reproduce this behaviour. Whether GNATSDB is set or not, the command "pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit --database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>" honors GNATSDB as well as the --database option. > Grokking through the code, I find that client_init_gnats > in client.c is invoking 'chdb default' because the scanenv function > always sets database to 'default' during initialization. There must be more to it than that, but I haven't yet been able to figure out what. Lars Henriksen _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: use of GNATSDB 2002-05-17 5:06 ` Lars Henriksen @ 2002-05-17 5:24 ` Lars Henriksen 2002-05-17 5:30 ` Lars Henriksen 2002-05-17 10:33 ` Dirk Bergstrom 1 sibling, 1 reply; 10+ messages in thread From: Lars Henriksen @ 2002-05-17 5:24 UTC (permalink / raw) To: Mel Hatzis; +Cc: help-gnats On Fri, May 17, 2002 at 02:03:08PM +0200, Lars Henriksen wrote: > On Wed, Mar 27, 2002 at 07:21:11PM -0800, Mel Hatzis wrote: > > I'm trying to setup a separate database instance by adding a line > > into the share/gnats/databases file and setting the GNATSDB env > > variable to point to it. I can successfully 'telnet localhost port#' > > and, say, lockdb, but when I try using pr-edit it ends up locking > > the default database. > > I can't reproduce this behaviour. Whether GNATSDB is set or not, the command > "pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit > --database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>" > honors GNATSDB as well as the --database option. That wasn't the whole story. In fact GNATSDB is honored by pr-edit when you specify a remote database, but not when you specify a local one. Lars Henriksen _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: use of GNATSDB 2002-05-17 5:24 ` Lars Henriksen @ 2002-05-17 5:30 ` Lars Henriksen 2002-05-17 11:09 ` Mel Hatzis 0 siblings, 1 reply; 10+ messages in thread From: Lars Henriksen @ 2002-05-17 5:30 UTC (permalink / raw) To: Mel Hatzis; +Cc: help-gnats On Fri, May 17, 2002 at 02:21:49PM +0200, Lars Henriksen wrote: > On Fri, May 17, 2002 at 02:03:08PM +0200, Lars Henriksen wrote: > > On Wed, Mar 27, 2002 at 07:21:11PM -0800, Mel Hatzis wrote: > > > I'm trying to setup a separate database instance by adding a line > > > into the share/gnats/databases file and setting the GNATSDB env > > > variable to point to it. I can successfully 'telnet localhost port#' > > > and, say, lockdb, but when I try using pr-edit it ends up locking > > > the default database. > > > > I can't reproduce this behaviour. Whether GNATSDB is set or not, the command > > "pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit > > --database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>" > > honors GNATSDB as well as the --database option. > > That wasn't the whole story. In fact GNATSDB is honored by pr-edit when > you specify a remote database, but not when you specify a local one. That should have been: That wasn't the whole story. In fact GNATSDB is honored by "pr-edit --lockdb" when you specify a remote database, but not when you specify a local one. Lars Henriksen _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: use of GNATSDB 2002-05-17 5:30 ` Lars Henriksen @ 2002-05-17 11:09 ` Mel Hatzis 2002-05-17 11:33 ` Lars Henriksen 0 siblings, 1 reply; 10+ messages in thread From: Mel Hatzis @ 2002-05-17 11:09 UTC (permalink / raw) To: Lars Henriksen; +Cc: help-gnats Lars Henriksen wrote: > On Fri, May 17, 2002 at 02:21:49PM +0200, Lars Henriksen wrote: > >>On Fri, May 17, 2002 at 02:03:08PM +0200, Lars Henriksen wrote: >> >>>On Wed, Mar 27, 2002 at 07:21:11PM -0800, Mel Hatzis wrote: >>> >>>>I'm trying to setup a separate database instance by adding a line >>>>into the share/gnats/databases file and setting the GNATSDB env >>>>variable to point to it. I can successfully 'telnet localhost port#' >>>>and, say, lockdb, but when I try using pr-edit it ends up locking >>>>the default database. >>>> >>>I can't reproduce this behaviour. Whether GNATSDB is set or not, the command >>>"pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit >>>--database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>" >>>honors GNATSDB as well as the --database option. >>> >>That wasn't the whole story. In fact GNATSDB is honored by pr-edit when >>you specify a remote database, but not when you specify a local one. >> > > That should have been: > > That wasn't the whole story. In fact GNATSDB is honored by "pr-edit --lockdb" > when you specify a remote database, but not when you specify a local one. > > Lars Henriksen > Let's clear some things up... the test I'm running is: GNATSDB=test $gnats_home/libexec/gnats/pr-edit --lockdb (let's ignore all other uses of GNATSDB and stick with this one) My $gnats_home/etc/gnats/databases file looks like: default:Bug database:/usr/local/com/gnatsdb:server.juniper.net:1529 test:GNATS Test:/homes/hatzis/local/gnats/test:server.juniper.net:1529 Let's also define local vs remote...as far as the code is concerned, it's remote if the line in the databases file defines the server and port number ...as per the last line in databaseSpecIsNetConn which reads: return (dbEnt->fieldcount > 3) ? 1 : 0; So, as far as my test is concerned, local mode is not used at all. When I run the 'pr-edit --lockdb' command, I don't see a gnats.lock in my test database... bash-2.03$ ls /homes/hatzis/local/gnats/test/gnats-adm addresses current index states categories dbconfig locks/ submitters classes gnatsd.access responsible but I do see a gnats.lock file in the default database... bash-2.03$ ls /usr/local/com/gnatsdb/gnats-adm addresses classes gnats.lock locks/ states categories dbconfig gnatsd.access responsible submitters -Mel _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: use of GNATSDB 2002-05-17 11:09 ` Mel Hatzis @ 2002-05-17 11:33 ` Lars Henriksen 0 siblings, 0 replies; 10+ messages in thread From: Lars Henriksen @ 2002-05-17 11:33 UTC (permalink / raw) To: Mel Hatzis; +Cc: help-gnats, Dirk Bergstrom On Fri, May 17, 2002 at 11:06:14AM -0700, Mel Hatzis wrote: > Let's clear some things up... the test I'm running is: > > GNATSDB=test $gnats_home/libexec/gnats/pr-edit --lockdb > > (let's ignore all other uses of GNATSDB and stick with this one) > > My $gnats_home/etc/gnats/databases file looks like: > > default:Bug database:/usr/local/com/gnatsdb:server.juniper.net:1529 > test:GNATS Test:/homes/hatzis/local/gnats/test:server.juniper.net:1529 I believe you. That was the combination I didn't try! I had GNATSDB itself point to the remote host. Lars Henriksen _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: use of GNATSDB 2002-05-17 5:06 ` Lars Henriksen 2002-05-17 5:24 ` Lars Henriksen @ 2002-05-17 10:33 ` Dirk Bergstrom 2002-05-17 11:15 ` Lars Henriksen 1 sibling, 1 reply; 10+ messages in thread From: Dirk Bergstrom @ 2002-05-17 10:33 UTC (permalink / raw) To: Lars Henriksen; +Cc: Mel Hatzis, help-gnats On 5/17/2002 5:03 AM, this issued forth from the mind of Lars Henriksen: > I can't reproduce this behaviour. Whether GNATSDB is set or not, the command > "pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit > --database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>" > honors GNATSDB as well as the --database option. this is a totally different issue. as you probably know, gnats has two separate code paths: "localhost mode", in which the particular program you're running directly interacts with the database. "network mode" in which the program talks to gnatsd over a socket. i could rant extensively about how foolish, wasteful & bug-prone this is, but i'll save that for another day, and stick to this particular example of the folly. so in pr-edit, the "network mode" lockdb code opens a socket to gnatsd and issues a LKDB command, and gnatsd locks the database. in "localhost mode", pr-edit makes a call to gnats_lock() (actually, it calls foo, which calls bar, which calls gnats_lock), which is the same call that gnatsd makes. this *does* lock the database, but then, at the very end of main(), there's a check that says something like: if (gnats_locked) { unlock_gnats() } this check is entirely reasonable, if you're trying to do an edit, or an append, but it's just wrong if you're trying to lock the database. so, you happen to have run into one of the many, many subtle and outrageous bugs in localhost mode. this is why i counsel people to *always* use network mode, even when talking to a local database. how, you ask, do you make sure you're using network mode? by specifying either --host or --port or both. -- Dirk Bergstrom dirk@juniper.net Computer Geek v: 707.433.0564 Juniper Networks Inc. f: 707.433.0769 "it *looks* like a nail; lemme grab my hammer..." _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: use of GNATSDB 2002-05-17 10:33 ` Dirk Bergstrom @ 2002-05-17 11:15 ` Lars Henriksen 2002-05-17 11:21 ` Dirk Bergstrom 0 siblings, 1 reply; 10+ messages in thread From: Lars Henriksen @ 2002-05-17 11:15 UTC (permalink / raw) To: Dirk Bergstrom; +Cc: Mel Hatzis, help-gnats On Fri, May 17, 2002 at 10:31:10AM -0700, Dirk Bergstrom wrote: > On 5/17/2002 5:03 AM, this issued forth from the mind of Lars Henriksen: > > I can't reproduce this behaviour. Whether GNATSDB is set or not, the command > > "pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit > > --database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>" > > honors GNATSDB as well as the --database option. > > this is a totally different issue. Is it? The issue is how or whether GNATSDB is honered by (for example) pr-edit and it was claimed, without reservations, that it always ended up locking the default database. As far as I can see, you confirm below that this is not the case. > so in pr-edit, the "network mode" lockdb code opens a socket to gnatsd > and issues a LKDB command, and gnatsd locks the database. ... > in "localhost > mode", pr-edit makes a call to gnats_lock() (actually, it calls foo, > which calls bar, which calls gnats_lock), which is the same call that > gnatsd makes. this *does* lock the database, but then, at the very end > of main(), there's a check that says something like: > > if (gnats_locked) { > unlock_gnats() > } > > this check is entirely reasonable, if you're trying to do an edit, or an > append, but it's just wrong if you're trying to lock the database. Thanks for the explanations. They agree with my observations. > so, you happen to have run into one of the many, many subtle and > outrageous bugs in localhost mode. this is why i counsel people to > *always* use network mode, even when talking to a local database. But of course you are right that this behaviour has nothing to do with GNATSDB. > how, you ask, do you make sure you're using network mode? by specifying > either --host or --port or both. Or by setting GNATSDB to point to the remote database. Lars Henriksen _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: use of GNATSDB 2002-05-17 11:15 ` Lars Henriksen @ 2002-05-17 11:21 ` Dirk Bergstrom 0 siblings, 0 replies; 10+ messages in thread From: Dirk Bergstrom @ 2002-05-17 11:21 UTC (permalink / raw) To: Lars Henriksen; +Cc: Mel Hatzis, help-gnats On 5/17/2002 11:13 AM, this issued forth from the mind of Lars Henriksen: > On Fri, May 17, 2002 at 10:31:10AM -0700, Dirk Bergstrom wrote: >> On 5/17/2002 5:03 AM, this issued forth from the mind of Lars Henriksen: >> > I can't reproduce this behaviour. Whether GNATSDB is set or not, the command >> > "pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit >> > --database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>" >> > honors GNATSDB as well as the --database option. >> this is a totally different issue. > Is it? The issue is how or whether GNATSDB is honered by (for example) pr-edit > and it was claimed, without reservations, that it always ended up locking > the default database. As far as I can see, you confirm below that this is > not the case. i guess i wasn't very clear in my explanation: using pr-edit in localhost mode, it is IMPOSSIBLE to lock ANY database. the program locks the db, then unlocks it a few lines later. it's a bug in the localhost mode code, one of many. -- Dirk Bergstrom dirk@juniper.net Computer Geek v: 707.433.0564 Juniper Networks Inc. f: 707.433.0769 "it *looks* like a nail; lemme grab my hammer..." _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2002-05-17 18:33 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-03-27 19:24 use of GNATSDB Mel Hatzis [not found] ` <15525.34645.542865.70528@habakuk.home.ha-schneider.de> [not found] ` <3CA6046B.1060004@juniper.net> [not found] ` <15528.10405.211358.551224@habakuk.home.ha-schneider.de> 2002-04-30 22:18 ` Mel Hatzis 2002-05-17 5:06 ` Lars Henriksen 2002-05-17 5:24 ` Lars Henriksen 2002-05-17 5:30 ` Lars Henriksen 2002-05-17 11:09 ` Mel Hatzis 2002-05-17 11:33 ` Lars Henriksen 2002-05-17 10:33 ` Dirk Bergstrom 2002-05-17 11:15 ` Lars Henriksen 2002-05-17 11:21 ` Dirk Bergstrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).