Bug #3370

YAML read/write locks broken on OpenBSD

Added by Robert Nagy almost 2 years ago. Updated about 1 year ago.

Status:Needs More Information Start date:03/15/2010
Priority:Normal Due date:
Assignee:Robert Nagy % Done:

0%

Category:file
Target version:-
Affected Puppet version:0.25.4 Branch:
Keywords:
Votes: 1

Description

commit:“45144a1b9da2839fd9f8a182a8f82ecb06e17292” that introduces read and write locks broke puppet on OpenBSD.

What happens is that on the first run of puppetd everything is fine, then puppetmasterd gets restarted and this error occurs:

http://pastebin.ca/1841149

Then /etc/puppet/ssl gets removed and everything is fine again but only on the first run, then the same thing happens.

Running —compile comes down to this: http://pastebin.ca/1841436

Reverting the changes makes puppet work again as expected.


Related issues

related to Puppet - Bug #1812: YAML files corrupted on server (due to high load?) Closed 12/09/2008

History

Updated by Robert Nagy almost 2 years ago

  • Category set to file

Updated by James Turnbull almost 2 years ago

  • Status changed from Unreviewed to Accepted
  • Assignee set to Markus Roberts
  • Target version set to 0.25.5

Updated by Markus Roberts almost 2 years ago

  • Status changed from Accepted to Needs More Information
  • Assignee changed from Markus Roberts to Robert Nagy
  • Priority changed from Urgent to Normal

This is my third attempt to update this ticket in the past two days (redmine is acting—odd). Sorry if I sound terse, but I’m getting tired of typing this.

  • I’m setting the ticket to Normal from Urgent (or at least trying to) since the change in question is ~a year old, there’s only this one report of the problem, and it’s not clear how the fix for #1812 could cause this in isolation.

  • I’m assigning it back to Robert as Needs more information as there are several plausible explanations for the situation, and finding the right one depends on knowing more:

** Could some other process is trying to access the yaml files on the server and locking them? 0.24.8 would have ignored this (while possibly silently corrupting the files)

** I’m assuming that what you are saying is that only the first puppetd run works, but it is possible that you mean multiple puppetd runs work until the puppetmaster is restarted. Is this the case?

** Does this happen on all nodes, or only some? If only some, is it always the same ones, and are they in anyway special?

** I’m assuming it’s the puppetmasterd that’s on OpenBSD, is that correct? Do you have the ability to try it with an alternate puppetmasterd running on another OS (assuming it’s very repeatable)? Do you have a reason for believing that it’s related to OpenBSD?

— Markus

Updated by Robert Nagy almost 2 years ago

Markus,

No other processes are accessing the yaml files at the time it’s running. The client has nothing do with it so puppetd can be running on any platform, i’ve tried OpenBSD and Linux running puppetd, the problem happens on the machine running puppetmasterd.

If i start with a clean installation i run puppetmasterd and start puppetd on the client, everything is fine. Then I kill puppetmasterd with SIGINT or SIGTERM and start it up again. At this point all the yaml files are looking good, contents are fine. Then I start puppetd on the client and suddenly the error messages pops up and the client will use it’s local cache. At this time on the server running puppetmasterd the .yaml file for the host is truncated to 0 size. And as you asked if i run puppetd e.g. 10 times w/o restarting puppetmasterd, it is still fine.

I am thinking that this is an OpenBSD only issue because if ruby uses OpenBSD’s pthread library it might cause problems, for example we cannot deal with non-blocking stdin/out/err. I am using the same setup with other operating systems too where it works just fine.

Updated by James Turnbull almost 2 years ago

  • Target version changed from 0.25.5 to 49

Updated by James Turnbull about 1 year ago

  • Target version deleted (49)

Also available in: Atom PDF