Jira (PUP-2790) if initctl --version doesn't list a matching string, upstart service provider fails badly.
Title: Message Title Sven Mueller commented on an issue Re: if initctl --version doesn't list a matching string, upstart service provider fails badly. Sorry for my delay in responding. This ended up on my old private email address and was sitting there for a little over two weeks, unattended. Anyway: I currently don't have the time to hone my git skills and create a pull request, I'm sorry. AFAICT, it should still apply cleanly to the latest HEAD. If I can, I will try again soon and see if there is a more reliable way to detect the upstart version in use. Testing /sbin/init instead of /sbin/initctl might work, but I haven't checked yet. Add Comment Puppet / PUP-2790 if initctl --version doesn't list a matching string, upstart service provider fails badly. We are running puppet during the installation process, using Debian installers late_command option. At this point, calling status avahi-daemon returns: - cut here - Warning: Fake initctl called, doing nothing. - cut here - (As does any other call to initctl, such as initctl list) Unfortunately, I was unable to determine if this... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (PUP-3045) exec resource with timeout doesn't kill executed command that times out
Title: Message Title
Sven Mueller created an issue
Puppet / PUP-3045
exec resource with timeout doesn't kill executed command that times out
Issue Type:
Bug
Affects Versions:
3.4.2
Assignee:
Kylo Ginsberg
Components:
Types and Providers
Created:
12/Aug/14 1:25 AM
Environment:
Linux
Priority:
Normal
Reporter:
Sven Mueller
Trivial reproduction case:
exec { sleep: command = /bin/sleep 1800, timeout = 10, }
With this, Puppet exits after roughly 10 seconds, but the sleep continues to run until the 1800 seconds are over.
My expectation would be for the sleep to get killed after the timeout hits.
As far as I can tell, the relevant code didn't change (much) till current head, so I suspect the issue still exists.
Jira (PUP-2790) if initctl --version doesn't list a matching string, upstart service provider fails badly.
Title: Message Title Sven Mueller commented on an issue Re: if initctl --version doesn't list a matching string, upstart service provider fails badly. So, I just checked yesterday. initctl is overridden during the installation, but asking telinit for the version would still work. So checking the version in telinit instead of initctl would be a more reliable way to detect the upstart version. Add Comment Puppet / PUP-2790 if initctl --version doesn't list a matching string, upstart service provider fails badly. We are running puppet during the installation process, using Debian installers late_command option. At this point, calling status avahi-daemon returns: - cut here - Warning: Fake initctl called, doing nothing. - cut here - (As does any other call to initctl, such as initctl list) Unfortunately, I was unable to determine if this... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this
Jira (PUP-2790) if initctl --version doesn't list a matching string, upstart service provider fails badly.
Title: Message Title Sven Mueller commented on an issue Re: if initctl --version doesn't list a matching string, upstart service provider fails badly. Pull request created against master branch. Add Comment Puppet / PUP-2790 if initctl --version doesn't list a matching string, upstart service provider fails badly. We are running puppet during the installation process, using Debian installers late_command option. At this point, calling status avahi-daemon returns: - cut here - Warning: Fake initctl called, doing nothing. - cut here - (As does any other call to initctl, such as initctl list) Unfortunately, I was unable to determine if this... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-3045) exec resource with timeout doesn't kill executed command that times out
Title: Message Title
Sven Mueller commented on an issue
Re: exec resource with timeout doesn't kill executed command that times out
I tried to come up with apatch that would fix this, but it seems such a patch exceeds my ruby skills.
Add Comment
Puppet / PUP-3045
exec resource with timeout doesn't kill executed command that times out
Trivial reproduction case: exec { sleep: command = /bin/sleep 1800, timeout = 10, } With this, Puppet exits after roughly 10 seconds, but the sleep continues to run until the 1800 seconds are over. My expectation would be for the sleep to get killed after the timeout hits. As far as I can tell, the relevant code didn't change (muc...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2481) Naginator: Allow parameters to be forced to absent
Title: Message Title Sven Mueller created an issue Puppet / PUP-2481 Naginator: Allow parameters to be forced to absent Issue Type: Improvement Affects Versions: 3.4.3 Assignee: Kylo Ginsberg Components: Types and Providers Created: 06/May/14 2:19 AM Priority: Normal Reporter: Sven Mueller While converting some of our active checks to passive ones (without changing their names), we realized that there is no way (at least no documented one) to remove the command parameter from nagios_service definitions from within puppet/naginator. It would be nice if this quote from the “cron” type would also be true for the nagios_* types: “All cron parameters support absent as a value; this will remove any existing values for that field.” Add Comment
Jira (PUP-2790) if initctl --version doesn't list a matching string, upstart service provider fails badly.
Title: Message Title Sven Mueller created an issue Puppet / PUP-2790 if initctl --version doesn't list a matching string, upstart service provider fails badly. Issue Type: Bug Affects Versions: 3.4.2 Assignee: Kylo Ginsberg Components: Types and Providers Created: 17/Jun/14 9:26 AM Environment: Ubuntu 14.04 Priority: Normal Reporter: Sven Mueller We are running puppet during the installation process, using Debian installers late_command option. At this point, calling status avahi-daemon returns: - cut here - Warning: Fake initctl called, doing nothing. - cut here - (As does any other call to initctl, such as initctl list) Unfortunately, I was unable to determine if this was on STDOUT or (partially) on STDERR, because it was replaced in the meantime by the standard initctl from upstart. However, that output causes this: 17 Jun 2014 14:32:00 puppet.py:1289 DEBUG PUPPET: Debug: Executing '/sbin/status avahi-daemon' 17 Jun 2014 14:32:00 puppet.py:1289 DEBUG PUPPET: Error:
Jira (PUP-2790) if initctl --version doesn't list a matching string, upstart service provider fails badly.
Title: Message Title Sven Mueller updated an issue Puppet / PUP-2790 if initctl --version doesn't list a matching string, upstart service provider fails badly. Change By: Sven Mueller Affects Version/s: 3.6.2 Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2790) if initctl --version doesn't list a matching string, upstart service provider fails badly.
Title: Message Title Sven Mueller updated an issue Puppet / PUP-2790 if initctl --version doesn't list a matching string, upstart service provider fails badly. Crude patch that fixes the issue I observed. However, it is probably not the best approach, since it simply assumes that if the provider is selected (has to happen manually in this case) and /sbin/initctl --version does not contain the right marker initctl (upstart, than the version of upstart is assumed to be post 2011-03-15 (and post the 0.9.0 release). Change By: Sven Mueller Attachment: puppet.patch Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2790) if initctl --version doesn't list a matching string, upstart service provider fails badly.
Title: Message Title Sven Mueller updated an issue Puppet / PUP-2790 if initctl --version doesn't list a matching string, upstart service provider fails badly. Change By: Sven Mueller Affects Version/s: PUP 4.5.2 Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2790) if initctl --version doesn't list a matching string, upstart service provider fails badly.
Title: Message Title Sven Mueller commented on PUP-2790 Re: if initctl --version doesn't list a matching string, upstart service provider fails badly. Just a quick update: I currently don't have any time to work on a pull request. However, using "/sbin/init --version" instead of "/sbin/initctl --version" works fine for us, also during installations, when initctl, status, start, ... are all overridden. telinit apparently (from my older comments) would also work, but I didn't check that on newer versions of upstart. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5577) confine :exists => "/run/systemd/system" breaks chroot installation
Title: Message Title Sven Mueller commented on PUP-5577 Re: confine :exists => "/run/systemd/system" breaks chroot installation Not sure if I should re-open this issue or create a new one: The check for /run/systemd/system also breaks management of services in Debian chroots (such as the debootstrap chroot created during installations from debian-installer - in which we run Puppet for the first time during automated installations). The problem is that it checks for a running systemd, it doesn't check for systemd to be in use by the given system. The proper check to see if systemd is used on a given system would be to check if /sbin/init is a link to /lib/systemd/systemd Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6984) alias on Package/Exec resources produces misleading warning
Title: Message Title
Sven Mueller created an issue
Puppet / PUP-6984
alias on Package/Exec resources produces misleading warning
Issue Type:
Bug
Affects Versions:
PUP 4.8.0
Assignee:
Unassigned
Created:
2016/12/07 10:24 AM
Priority:
Normal
Reporter:
Sven Mueller
An alias on (at least) package and exec resources that worked fine to resolve a dependency at least in Puppet 3.4 doesn't work anymore in Puppet 4.8.0. I would expect that the manifest below would not create the Warning it gives. (I'm surprised by a warning that the dependency isn't found, but then getting a "dependency failed" on just that resource, though referenced by the title, not the alias, which in turn is OK)
Almost minimal reproduction case:
$ cat /tmp/t.pp; sudo puppet apply --detailed-exitcodes /tmp/t.pp; echo $?
$Id$ package {'postfix': alias => 'mta', ensure => latest, }
exec {'/bin/false': alias => 'something', }
notify {'Depended on mta': require => [Exec['something'], Package['mta']], }
Warning: Could not find resource 'Exec[something]' in parameter 'require' (at /tmp/t.pp:12) Warning: Could not find resource 'Package[mta]' in parameter 'require' (at /tmp/t.pp:12) Notice: Compiled catalog for 90cdc197-bd0d-4ee2-8e22-cf4962548eb1
Jira (PUP-6984) alias on Package/Exec resources produces misleading warning
Title: Message Title
Sven Mueller commented on PUP-6984
Re: alias on Package/Exec resources produces misleading warning
If you only allow referencing the resources by their title, the alias metaparameter looses its meaning completely. And while I don't know current training material, it was provided in the past as "the" way to allow interoperability while keeping manifests readable/meaningful.
Consider this:
package {'apache2': ensure => present, alias => 'http-server', }
vs.
package {'http-server': ensure => present, name => 'apache2' }
When installation of the package fails, the first tells you which package failed to install (apache2), while the second will tell you a symbolic name (and later on the command, but this also gets confusing).
I agree that the server should warn about undefined resources.
But a resource definition with an alias should define one resource with two names, so this bug is not about a misleading warning in the end, but about an oversight in the change that was merged at 668fef0: It should not just look at resource titles, but also at their aliases.
I'm not sure if unless catalog.resource(r.to_s) should be replaced with something else, or if catalog.resource() is incorrect here and should also return resources by alias.
Add Comment
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6984) alias on Package/Exec resources produces misleading warning
Title: Message Title Sven Mueller commented on PUP-6984 Re: alias on Package/Exec resources produces misleading warning After reading a bit more, I'm unconvinced that the check from PUP-5855 is actually helpful, unless auto-generated resources (like the file provider can create, IIUC - I never really used that, instead making each dependency and stage of directory creations explicit) are also deprecated. In any case, not allowing explicit aliased makes the language feature unusable. Do you intend to mark that metaparameter as deprecated? And many style guides I came across said to use actual pathnames in File resources (and more generally: Don't use the attribute tagged as namevar, unless you have very good reason to do so. I'm not sure your quest to only refer to resources by their title is such a good reason. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7926) vendored pathspec library has an over-reaching regexp
Title: Message Title Sven Mueller created an issue Puppet / PUP-7926 vendored pathspec library has an over-reaching regexp Issue Type: Bug Assignee: Sven Mueller Created: 2017/09/08 9:08 AM Priority: Trivial Reporter: Sven Mueller pathspec has a regular _expression_ to match for Windows drive letters. It is contains [a-zA-z] - which unintentionally also matches _, ^ and other non-letter characters between Z and a. See https://github.com/highb/pathspec-ruby/pull/16 for the pull request for upstream pathspec-ruby. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Jira (FACT-3064) Please update Google GCE instance check
Title: Message Title Sven Mueller created an issue Facter / FACT-3064 Please update Google GCE instance check Issue Type: Bug Assignee: Unassigned Components: Facter 3, Facter 4 Created: 2021/08/09 1:40 AM Priority: Normal Reporter: Sven Mueller Hi. Currently, Facter checks if it is running on Google's GCE by checking if the bios vendor is "Google". However, this happens to also be the case on some non-GCE systems (I think also in the Linux VM on Chromebooks as well as some other odd systems), leading to timeout when trying to talk to the Metadata server. https://cloud.google.com/compute/docs/instances/managing-instances has updated the detection method (avoiding the metadata server) to: sudo dmidecode -s system-product-name | grep "Google Compute Engine" Google Compute Engine For Linux. Please update facter accordingly. Add Comment
