The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
mcollectived should expand members of the libdir to full paths
|Assignee:||R.I. Pienaar||% Done:|
|Keywords:||Affected mCollective version:||2.0.0|
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.
#2 Updated by R.I. Pienaar almost 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 almost 2 years ago
- File daemon.txt added
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 almost 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 almost 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.