The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
`puppet resource file` reports "Cannot manage files of type socket"
|Assignee:||Josh Cooper||% Done:|
|Affected Puppet version:||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
12:38 milo |> puppet --version 2.7.2 12:38 milo |> puppet resource file /etc/hosts Could not run: Cannot manage files of type socket
#2 Updated by Josh Cooper over 3 years ago
- Assignee set to Josh Cooper
When a unix domain socket is present in /, this functionality worked in 0.25.1, was broken in 0.25.2 (#3165), and been broken ever since. It appears #3165 was masking this bug, so when #3165 was fixed in 2.6.5, this bug was uncovered.
#4 Updated by Josh Cooper over 3 years ago
Previously the command ‘puppet resource file’ would enumerate all files in the root directory, and generate an exception if the file type was not a directory, file, or link. It would also do this when a file or directory was specified, e.g. ‘puppet resource file /etc/hosts’. The reason is because the find and search methods of the ral terminus both call Puppet::Type.instances, which returns an array of all instances it knows about. In the case of the file type, it recurses one level from the root directory (the root and its direct children). Owen submitted a match for #3165 that eliminated this behavior, but Jesse added the functionality back in when he merged Owen’s patch.
Ideally, puppet could be modified to handle the other file types gracefully, e.g. unix domain socket, and do something with them, perhaps skipping over them, warning, etc. But this change was deemed to big for 2.6. Though we should revisit for 2.7 and see if a better solution can be implemented.
Also, in the case of file types, it is not necessary for the ral’s find method to call the type’s instances method — because it can directly create a file instance with the specified name. However, for other types that have multiple providers, e.g. package, this is not true. In other words, each provider must be asked if it provides an instance with that name. (The code actually walks every provider and every instance for each provider so that it can warn if an instance with the same name is provided by multiple providers.)
However, the ral’s search method does need to call the instances method to return all instances. Ideally, the instances method should know in what context it is being invoked (find vs search) so that it can do the right thing based on the context and type, e.g. file vs package. One idea I had was to add two methods, find_instances and search_instances, to Puppet::Type, and have each invoke the instances method by default. Then for types that want different behavior like file, can return an empty array for find_instances, but do what it does now for search_instances. Again this is too big of a change for 2.6, and it still means ‘puppet resource file’ would fail in the presence of other file types in the root.
After discussions with Nigel, Nick, and Matt, I changed the resource application to return an error message (listing files in the root directory is not supported). This seemed appropriate seeing as how this behavior (executing puppet resource file with or without a file path) has been broken since 0.25.2 when a file type other than directory, file or links is in the root directory.