David,
What distro/OS are you running on? Have you tried looking
in$APP_DIR/log/app.log ?
That init script is not compliant with the Fedora/RedHat spec, so I'm
not sure if that would have anything to do with it (or, if you're on a
modern version of a Fedora/RHEL derivative, systemd/upstart take-over...)
What are the "minor variations for [your] environment"? They could
certainly be the problem, so it would be helpful if you could
pastebin/dpaste/gist the actual script you're running.
Here's a pattern I've often used for things like this (note this is from
memory, so syntax may need to be adjusted a bit):
1) change the path to the init script (your File resource) to
/etc/init.d/node.orig
2) As it *looks* to me like it should work for this script, change the
first line of the script to "#!/bin/bash -x" which will run print bash
debugging information as commands are run (same as set -x).
3) manually, give /etc/init.d/node this content:
#!/bin/bash
date >> /var/log/node-wrapper.log
echo "Args: $@" >> /var/log/node-wrapper.log
# this next line executes /etc/init.d/node with the same args as this
script, and logs all output
/etc/init.d/node.orig "$@" 2>&1 >> /var/log/node-wrapper.log
ret=$?
echo "exited $ret" >> /var/log/node-wrapper.log
exit $?
EOF
That will at least give you a log of the date/time, arguments,
output/stderr, and exit code.
-Jason
On 11/22/2013 05:23 PM, David Ashby wrote:
> I've been experiencing some odd behavior with puppet and checking the
> status of running processes. Let me see if I can explain it:
>
> I have a very simple node.js socket server I'm attempting to
> puppetize. It is managed through an init.d script with start, stop,
> status, and restart. The init.d script runs perfectly fine as any
> other user in the system. However, when puppet attempts to check
> status or start the server, it fails and reports it received '1' on exit.
>
> I don't believe that the script has any hidden requirements of
> environment variables that aren't getting transferred around -- like I
> said, it's /very/ simple. Additionally, adding debugging echo
> statements to the script to try and prove that it's executing at all
> don't appear to fire, either. It has the same permissions as plenty of
> other functioning init scripts. I'm pretty much at my wit's end on
> this one.
>
> Relevant code:
>
> class service::nodesocketserver {
> file { '/etc/init.d/node':
> ensure => present,
> owner => 'root',
> group => 'root',
> mode => '0755',
> source => 'puppet:///modules/nodejs/node',
> }
>
> service { 'node':
> ensure => running,
> enable => true,
> hasstatus => true,
> hasrestart => true,
> require => File['/etc/init.d/node'],
> }
> }
>
> /etc/init.d/node is https://github.com/chovy/node-startup with some
> minor variations for my specific environment.
>
> Again, everything works great when I run it manually but falls down
> when I throw puppet at it. Any advice, more debugging angles I could take?
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/70dbf595-112a-4649-8798-7d78c7b7cc5c%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/52920743.6090207%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.
