Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#2557 closed defect (wontfix)

lockfile should use --data-path

Reported by: jreed Owned by: vorner
Priority: medium Milestone: Sprint-20130122
Component: logging Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: Core Feature Depending on Ticket:
Estimated Difficulty: 3 Add Hours to Ticket: 0
Total Hours: 1.84 Internal?: no

Description

I used bind10 -p to set a different data path, but still uses the compiled in localstatedir.

RuntimeError?: Unable to use interprocess sync lockfile: /var/bind10-devel/logger_lockfile

To workaround I used B10_LOCKFILE_DIR_FROM_BUILD environment variable.

Subtickets

Change History (11)

comment:1 Changed 7 years ago by jelte

  • Milestone changed from New Tasks to Sprint-20130108

comment:2 Changed 7 years ago by vorner

  • Owner set to vorner
  • Status changed from new to accepted

comment:3 Changed 7 years ago by vorner

  • Owner changed from vorner to UnAssigned
  • Status changed from accepted to reviewing

I used a private environment variable to pass it around, but the user shouldn't
be in contact with it. It seemed the easiest way around, the other possibility
would be passing options around to each process, but each process would have to
explicitly handle it, making it harder to create new ones and providing many
duplicate pieces of code.

But I didn't come up with a way to test it easily. I did confirm manually ‒ I
run once without the -p, and it created it in the default place. When I set
the -p argument, the lock file was at that place (and not in the default
one).

Proposed changelog:

The command line parameter of boss `-p` now influences the place
of logging lock file. This solves a problem when the default path
wasn't accessible by the user running bind10.

comment:4 follow-up: Changed 7 years ago by jinmei

Considering this is for an optional case, should we really solve
this particular topic separately, especially by introducing yet
another hack of environment variable?

I start feeling that it might be a good timing to clarify the
convoluted setup for various paths: what kind of concept we need, and
how we manage them (in config file, command line arg, and/or
environment variable) with which policy, and document these. If we
can solve this particular topic on top of that clarification more
cleanly, that would be the best; if we still need some kind of hack,
we can at least introduce it according to the documented policy.

And I think it's better if we can clarify it before the non-beta
release as it will be more difficult to correct the things once more
people rely on these existing hacks.

comment:5 Changed 7 years ago by jinmei

  • Owner changed from UnAssigned to vorner

comment:6 in reply to: ↑ 4 ; follow-up: Changed 7 years ago by vorner

  • Owner changed from vorner to jinmei

Hello

Replying to jinmei:

Considering this is for an optional case, should we really solve
this particular topic separately, especially by introducing yet
another hack of environment variable?

Well, the ticket is for solving this problem, not for solving (much larger)
general problem. And it is in the sprint… But I'll write an email to the ML
asking for proposed solutions.

Anyway, I think the environment variable hack is reasonable. The variable is
only between boss and the started modules. It has no effect if set from outside
and passed to boss.

I start feeling that it might be a good timing to clarify the
convoluted setup for various paths: what kind of concept we need, and
how we manage them (in config file, command line arg, and/or
environment variable) with which policy, and document these. If we
can solve this particular topic on top of that clarification more
cleanly, that would be the best; if we still need some kind of hack,
we can at least introduce it according to the documented policy.

I don't know if a config file is a good place here. We need to know the place
of lock file before we read the config, otherwise we'll get race conditions. Or
maybe not, but we would have to be very careful. Anyway, we need a way to start
as a user if we don't have a write permission to the default path, so config
file wouldn't help here. And having a path to finding configuration in a
configuration file is kind of useless.

But yes, we need to solve it somehow. But I don't think we want to do it in
this ticket.

comment:7 in reply to: ↑ 6 Changed 7 years ago by jinmei

Replying to vorner:

Considering this is for an optional case, should we really solve
this particular topic separately, especially by introducing yet
another hack of environment variable?

Well, the ticket is for solving this problem, not for solving (much larger)
general problem. And it is in the sprint… But I'll write an email to the ML
asking for proposed solutions.

I'm not arguing for solving the larger problem in this ticket. I
wondered whether it makes more sense to hold or cancel (as "won't
fix") this task until we clarify the bigger issue.

If this is a critical defect that affects many users, I see the need
for an urgent care fix. But it doesn't seem to be so - "-p" wouldn't
be used normally, and as already suggested in the ticket description,
there already seems to be a workaround.

We could fix this particular issue in some way anyway and then
consider the bigger issue. But I'd be careful about that approach,
because any new code introduced in the master branch will work as a
precedent that will hinder higher level work.

But it may be only me...so my suggestion is to get the sense of the
team on if we really want/need to fix this particular issue right now,
in any workable way. If that's the consensus I'll follow it.

comment:8 Changed 7 years ago by jinmei

  • Owner changed from jinmei to vorner

comment:9 Changed 7 years ago by vorner

  • Resolution set to wontfix
  • Status changed from reviewing to closed
  • Total Hours changed from 0 to 1.84

comment:10 Changed 7 years ago by jreed

I think "wontfix" is wrong -- maybe "stalled" instead? Maybe --data-path should be removed or this issue documented in the manual? (I am fine with stalling the ticket.)

comment:11 Changed 7 years ago by jreed

Also the plan to do "WONTFIX" was based on making a plan to fix correctly. A ticket needs to be opened to track that work.

Note: See TracTickets for help on using tickets.