The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #16018

mcollectived should expand members of the libdir to full paths

Added by J L over 2 years ago. Updated almost 2 years ago.

Status:ClosedStart date:08/17/2012
Priority:NormalDue date:
Assignee:R.I. Pienaar% Done:

0%

Category:Core
Target version:2.3.x
Keywords: Affected mCollective version:2.0.0
Branch:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

When daemonize=1 in server.cfg, the log indicates mcollective has started, but ps shows no processes. See daemon.txt

When daemonize=0 in server.cfg, the log indicates it has started and ps reports a proc. See foreground.txt

daemon.txt Magnifier - daemonize=1 (2.5 KB) J L, 08/17/2012 03:36 pm

foreground.txt Magnifier - daemonize=0 (5.63 KB) J L, 08/17/2012 03:36 pm

daemon.txt Magnifier (5.18 KB) J L, 08/20/2012 09:46 pm

History

#1 Updated by J L over 2 years ago

  • Subject changed from mcollective does not start up correctly is daemonize=1 to mcollectived does not start up correctly if daemonize=1

#2 Updated by R.I. Pienaar over 2 years ago

  • Status changed from Unreviewed to Needs More Information

I am not sure if this is the cause but you should use full paths in —config ../etc/server.cfg and your -I that you supply to ruby, the daemon will change its working directory before daemonizing and this might be related

#3 Updated by J L over 2 years ago

It appears the issue is with ruby not liking a relative include path and silently dying when attempting to load the plugins (unable to resolve the plugin dir). The relative config path is not causing any issues.

This command works: ruby -I /home/rad/mcollective-2.0.0/lib/ mcollectived —config ../etc/server.cfg See daemon.txt

It may make sense to change this bug to something more along the lines of “Make mcollectived handle unresolveable (or missing) library paths more gracefully”

#4 Updated by R.I. Pienaar over 2 years ago

  • Subject changed from mcollectived does not start up correctly if daemonize=1 to mcollectived should expand members of the libdir to full paths
  • Category set to Core
  • Status changed from Needs More Information to Accepted
  • Assignee set to R.I. Pienaar
  • Target version changed from 2.0.x to 2.1.x

I don’t think there is much I can do about the -I other than actually editing he ruby $: variable at run time which I don’t think is a good idea at all.

Daemonizing changes directories as is the norm in unix, relative paths just dont really make sense. From what I can tell the same would happen if you made the libdir relative in the config file – though about that I can do something.

So I’ll use this ticket to make sure we expand the paths in the mcollective libdir before adding it to our internal path list but I cant do much about the -I behavior

#5 Updated by R.I. Pienaar over 2 years ago

  • Status changed from Accepted to Needs Decision

So its actually quite hard to know whats best, given:

libdir = some/dir

I can take it relative to the directory where the config file is or relative to the current working directory.

Leaning towards just not doing this it’ll just further confuse matters.

#6 Updated by J L about 2 years ago

Given the inherent ambiguity of relative paths, what about requiring fully qualified paths?

#7 Updated by R.I. Pienaar about 2 years ago

J L wrote:

Given the inherent ambiguity of relative paths, what about requiring fully qualified paths?

yeah, def sounds like the best idea

#8 Updated by R.I. Pienaar about 2 years ago

  • Status changed from Needs Decision to Accepted
  • Target version changed from 2.1.x to 2.3.x

#9 Updated by R.I. Pienaar almost 2 years ago

  • Status changed from Accepted to Closed

Also available in: Atom PDF