[Puppet Users] Re: Puppet's call to /sbin/service somehow different than calling from the command line?
On Mar 1, 2:14 pm, Brian Ferris wrote: > For what it's worth, I finally debugged this issue. Great! > Hopefully this will help if anyone ever runs into a similar issue down the > road. Thanks for that. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet's call to /sbin/service somehow different than calling from the command line?
For what it's worth, I finally debugged this issue. When Puppet executes the service command, it forks and (by default) closes the stdin, stdout, stderr and all other open file descriptors before executing the service command. This turned out to be my undoing, as closing stdin seems to be what caused all the problems for my java daemon. A simple "cat /dev/null | java ..." in the daemon init script did the trick, though I haven't debugged specifically what the issue was with java. Hopefully this will help if anyone ever runs into a similar issue down the road. Thanks, Brian On Thu, Feb 25, 2010 at 6:52 AM, jcbollinger wrote: > > > On Feb 24, 9:53 am, Brian Ferris wrote: > > Yes to running in enforcing mode. I just tried turning enforcing mode > off > > with a call to "setenforce 0" and I still get the same behavior. > > Hmmm. This still feels like a possibility. The SELinux context of > the puppetd process is definitely different from the SELinux context > of an interactive shell, so that is a difference such as you asked > about. It might be worth checking your logs for denial advices. > > Alternatively, are you using ACLs on your filesystem? It could be > that one or more of the needed jars have ACLs that prevent puppetd > access, even though the base file permissions appear to allow it. > > Are any of the needed jars located on a remote file system? That > could bring additional access rules into play that might discriminate > between you and puppetd. > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet's call to /sbin/service somehow different than calling from the command line?
On Feb 24, 9:53 am, Brian Ferris wrote: > Yes to running in enforcing mode. I just tried turning enforcing mode off > with a call to "setenforce 0" and I still get the same behavior. Hmmm. This still feels like a possibility. The SELinux context of the puppetd process is definitely different from the SELinux context of an interactive shell, so that is a difference such as you asked about. It might be worth checking your logs for denial advices. Alternatively, are you using ACLs on your filesystem? It could be that one or more of the needed jars have ACLs that prevent puppetd access, even though the base file permissions appear to allow it. Are any of the needed jars located on a remote file system? That could bring additional access rules into play that might discriminate between you and puppetd. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet's call to /sbin/service somehow different than calling from the command line?
Yes to running in enforcing mode. I just tried turning enforcing mode off with a call to "setenforce 0" and I still get the same behavior. On Wed, Feb 24, 2010 at 6:14 AM, jcbollinger wrote: > > > On Feb 24, 1:17 am, Brian Ferris wrote: > > What's the difference in execution contexts? > > One more guess: are you running SELinux in enforcing mode? > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet's call to /sbin/service somehow different than calling from the command line?
On Feb 24, 1:17 am, Brian Ferris wrote: > What's the difference in execution contexts? One more guess: are you running SELinux in enforcing mode? John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet's call to /sbin/service somehow different than calling from the command line?
On Feb 24, 1:17 am, Brian Ferris wrote: > I see it changing the > status of the service from stopped to running, and yet my Java service > fails with random NoClassDefFound errors. For classes belonging to your application, to external jars, or to the system library? [...] > Now, I know you're immediately going to guess that I have some > classpath setup incorrectly or a permissions problem or something. It's not a guess: you definitely have a classpath problem. Following Craig's suggestion, you might consider looking at the CLASSPATH environment variable. I strongly recommend against relying on CLASSPATH, by the way, as doing so is prone to problems exactly like this. Instead, specify your classpath on the command line. Even better: package all the needed classes (except those from the standard runtime library) into the same jar, identify the entry point via a Main-Class: entry in its manifest, and run the sucker using "java -jar". You mention that you have checked permissions, etc.. I assume, then, that you are aware that if the puppetd process does not have read permission on one or more of the needed jars, or, recursively, the directories containing them, then those jars are effectively not in the classpath. Also, do you give the *absolute* path to each jar in your classpath? One more thing: does your initscript use the absolute pathname of the java runtime executable? If not, and if there is more than one Java runtime installed, then it may be that puppetd is running a different java than you do from the command line. That might contribute to your issue. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
