Re: BIND 10 #322: Process name in Python
BIND 10 Development
do-not-reply at isc.org
Mon Sep 27 11:12:37 UTC 2010
#322: Process name in Python
-------------------------------+--------------------------------------------
Reporter: fujiwara | Owner: jinmei
Type: enhancement | Status: reviewing
Priority: major | Milestone:
Component: Unclassified | Resolution:
Keywords: | Sensitive: 0
Estimatedhours: 0.0 | Hours: 0
Billable: 1 | Totalhours: 3.0
Internal: 0 |
-------------------------------+--------------------------------------------
Changes (by vorner):
* owner: vorner => jinmei
Comment:
Replying to [comment:6 jinmei]:
> Replying to [comment:5 vorner]:
> > That will be a little bit of a problem. Many tools (top, pstree, …)
cut too long names, so we would have many processes that would look like
„/usr/share/local/libe“ and the important information which actual process
it is would be not visible (and I think this is more common than having
two binds).
> >
> Hmm, but from quick checks the top command I can use (including one
available on bind10.isc.org) seems to cut the path itself. I've never
used pstree, but the one installed on bind10.isc.org seems to do the same
thing.
Well, there seem to be two (or more) process names or something, it cut
the path if it is the name automatically assigned to it by system. But if
I try to assign it by the setproctitle library, it does not cut the path,
it cuts it from the end if it is too long, no matter if it is just some
text or real path.
> > On the other hand, which installation it is is valuable only for the
boss. So maybe boss could have some more clever naming (like bind10
<version>) with possibility to provide custom name by --prettyname, while
other „slave“ processes would have just their basename? Would that be
suitable?
> >
> Perhaps, and one possible compromise would be to add the path to bind10
with --prettyname while keeping others short.
Ok, BoB now has full path/arg 0, others have a basename and BoB has the
--pretty-name parameter.
> No it doesn't (or I was not clear in my previous comment and we are
talking about different things). For example, in bind10/Makefile.in we
have
> {{{
> sbin_SCRIPTS = bind10
> }}}
>
> So the process_test looks for {top_dir}/src/bin/bind10/bind10.
>
> But if we do ./configure then 'make check' immediately, "bind10" doesn't
exist at the time the test is invoked because make first goes down to
src/lib and then src/bin. As a result you'd see:
Ah, sorry, I misunderstood what you ment by vanilla tree. I moved it into
src/bin/tests and made sure the scripts are created first. I didn't
reallize anyone would like to run make check and not run make first.
The make check fails now, if it is run directly, but with something
unrelated that is fixed in trunk. If I merge them locally, it is fine (I
didn't put the merge in SVN, since then the diff of a branch is harder to
create).
Thanks
--
Ticket URL: <https://bind10.isc.org/ticket/322#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list