puppet and std

[Fabrice Bacchella]

I'm running puppet on a Centos 5.8

I'm trying to launch puppet as a daemon and it fail silently. --debug provides no help

So I tried to strace it, I'm getting this :

1845 close(0) = 0
1845 open("/dev/null", O_RDONLY) = 0
1845 close(1) = 0
1845 open("/dev/null", O_WRONLY|O_CREAT|O_APPEND, 0666) = 1
...
1845 dup2(1, 2) = 2
...
1845 write(2, "Could not run: Daemons must have"..., 58) = 58
| 00000 43 6f 75 6c 64 20 6e 6f 74 20 72 75 6e 3a 20 44 Could no t run: D |
| 00010 61 65 6d 6f 6e 73 20 6d 75 73 74 20 68 61 76 65 aemons m ust have |
| 00020 20 61 6e 20 61 67 65 6e 74 2c 20 73 65 72 76 65 an agen t, serve |
| 00030 72 2c 20 6f 72 20 62 6f 74 68 r, or bo th |
1845 write(2, "\n", 1) = 1
| 00000 0a . |

So if I understand it right, a message is send to a nulled stderr. Do you know how I can get it back ?

[Jo Rhett]

Are you starting puppet by hand, or using service? Try doing it by hand.

And you can always "strace -s 2048" and see the entire message.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

-- 

Jo Rhett

Net Consonance : net philanthropy to improve open source and internet projects.

[Fabrice Bacchella]

I'm starting it by hand. It's the same process (pid 1845) that is nulling stderr that is writing to it, so it's not related to the way it's launched, --debug provides no help.

Using strace is not a long term solution. It was used to understand why Puppet keep failing silently. I still not know why it's failling. But I know why it's silent : error message going to /dev/null, instead of syslog.

[jcbollinger]

On Friday, September 21, 2012 4:35:41 AM UTC-5, Fabrice Bacchella wrote:

I'm starting it by hand. It's the same process (pid 1845) that is nulling stderr that is writing to it, so it's not related to the way it's launched, --debug provides no help.

Using strace is not a long term solution. It was used to understand why Puppet keep failing silently. I still not know why it's failling. But I know why it's silent : error message going to /dev/null, instead of syslog.

Are you running "puppet agent" or just "puppet"?  It should be the former.


John

[Fabrice Bacchella]

puppet agent.

[jcbollinger]

Then my next best best is that Puppet is not finding its configuration file.  By default, it should be looking for /etc/puppet/puppet.conf.  Alternatively, perhaps there is something inconsistent in the options you are using.  I agree that it's surprising that messages are not going to syslog, and I encourage you to file a ticket.  In the meantime, the best way to troubleshoot your actual problem is to run with --no-daemonize so that output goes to the terminal.


John

[Fabrice Bacchella]

My main problem was not with puppet failing, I managed to find the cause, and it was my own mistake. I was much more suprised by the output to a null'ed stderr. I think that should never happen. Either fd2 is still stderr and it's OK to send message to it, or it's been redirected to /dev/null and no one should write to it.

[jcbollinger]

On Monday, September 24, 2012 6:11:33 PM UTC-5, Fabrice Bacchella wrote:

My main problem was not with puppet failing, I managed to find the cause, and it was my own mistake. I was much more suprised by the output to a null'ed stderr. I think that should never happen. Either fd2 is still stderr and it's OK to send message to it, or it's been redirected to /dev/null and no one should write to it.

And thus I recommended that you file a ticket.  When Puppet is running in daemon mode it does normally direct diagnostic messages to syslog.  You seem to have discovered a window when messages are no longer being sent to the terminal but are not yet being delivered to syslog.

I cannot speak specifically to why fd 2 is redirected to /dev/null, but it is fairly likely that this is a function of the Ruby implementation, not a knowing choice by Puppet.


John

[Stephen Gran]

Hi,

Redirection of stderr to /dev/null in a daemonized process is very
common in the unix world. That puppet doesn't also send that message
through it's log routines so that you can see it somewhere (presumably
syslog) is the issue that needs addressing.

It may be that you've found a race condition where something can go
wrong between closing its fds and opening its logs.

Cheers,
--
Stephen Gran
Senior Systems Integrator - guardian.co.uk

Please consider the environment before printing this email.
------------------------------------------------------------------
Visit guardian.co.uk - newspaper of the year

www.guardian.co.uk www.observer.co.uk www.guardiannews.com

On your mobile, visit m.guardian.co.uk or download the Guardian
iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad

Save up to 37% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access.
Visit guardian.co.uk/subscribe

---------------------------------------------------------------------
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.

Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.

Guardian News & Media Limited

A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP

Registered in England Number 908396