Jira (PUP-3483) Systemd provider doesn't scan for changed units

2018-10-23 Thread Vincent Lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Vincent Lours commented on  PUP-3483  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Systemd provider doesn't scan for changed units   
 

  
 
 
 
 

 
 Hi Jeff Silverman, As you, I use to create my own systemd unit file.  But from my understanding, the 2 actions listed in your post does not required any daemon-reload. According the man documentation, the "enable" command reload the systemd configuration after creating the symlink: 

enable NAME... Enable one or more unit files or unit file instances, as specified on the command line. This will create a number of symlinks as encoded in the "[Install]" sections of the unit files. After the symlinks have been created, the systemd configuration is reloaded (in a way that is equivalent to daemon-reload) to ensure the changes are taken into account immediately. [...]
 And I've made few tests. When a new unit file is created, the systemd is adding it automatically to the config:  
 
 
 
 
 Example of creation of new unit file  
 
 
 
 
 sh-4.2# cat /etc/centos-release  
 
 
 CentOS Linux release 7.5.1804 (Core)  
 
 
 sh-4.2# ls -l /usr/lib/systemd/system/mytest.service  
 
 
 ls: cannot access /usr/lib/systemd/system/mytest.service: No such file or directory  
 
 
 sh-4.2# systemctl list-unit-files | grep mytest  
 
 
 sh-4.2# vi /usr/lib/systemd/system/mytest.service  
 
 
 sh-4.2# cat /usr/lib/systemd/system/mytest.service  
 
 
 [Unit]  
  

Jira (PUP-3483) Systemd provider doesn't scan for changed units

2018-09-27 Thread Vincent Lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Vincent Lours assigned an issue to Vincent Lours  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-3483  
 
 
  Systemd provider doesn't scan for changed units   
 

  
 
 
 
 

 
Change By: 
 Vincent Lours  
 
 
Assignee: 
 Vincent Lours  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
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-9075) File type "replace => false" doesn't allow to remove the file if "ensure => absent"

2018-09-20 Thread Vincent Lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Vincent Lours assigned an issue to Eric Sorenson  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9075  
 
 
  File type "replace => false" doesn't allow to remove the file if "ensure => absent"   
 

  
 
 
 
 

 
Change By: 
 Vincent Lours  
 
 
Assignee: 
 Eric Sorenson  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
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-9075) File type "replace => false" doesn't allow to remove the file if "ensure => absent"

2018-09-16 Thread Vincent Lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Vincent Lours commented on  PUP-9075  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: File type "replace => false" doesn't allow to remove the file if "ensure => absent"   
 

  
 
 
 
 

 
 Hi Eric Sorenson, Thanks for your answer, and I can understand why you don't want to change it. However I cannot imagine what should be the "normal" behaviour expected by people who set a file 'absent', other than to get it removed. I'm pretty sure that nobody already noticed that the file was not removed after changing the ensure status of this kind of "file" in the hiera config. From my point of view the true behaviour should be to remove it, no matter what. Furthermore, I cannot imagine to remove the "replace" from my manifest, as the file ensure can be different depending of the server type.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
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-9075) File type "replace => false" doesn't allow to remove the file if "ensure => absent"

2018-09-16 Thread Vincent Lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Vincent Lours assigned an issue to Unassigned  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9075  
 
 
  File type "replace => false" doesn't allow to remove the file if "ensure => absent"   
 

  
 
 
 
 

 
Change By: 
 Vincent Lours  
 
 
Assignee: 
 Vincent Lours  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
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-3483) Systemd provider doesn't scan for changed units

2018-08-21 Thread Vincent Lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Vincent Lours commented on  PUP-3483  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Systemd provider doesn't scan for changed units   
 

  
 
 
 
 

 
 Eric Thompson thanks for your message. I've made the modification, but I'm still waiting for the CLA confirmation message (I've raised the issue CLA-31about that). I hope to be able to submit the PR soon ^^  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
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-9075) File type "replace => false" doesn't allow to remove the file if "ensure => absent"

2018-08-20 Thread Vincent Lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Vincent Lours created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9075  
 
 
  File type "replace => false" doesn't allow to remove the file if "ensure => absent"   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 PUP 5.5.3  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 Catalog Application  
 
 
Created: 
 2018/08/20 7:55 PM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Vincent Lours  
 
 
Original Estimate: 
4 hours 
 
 
Remaining Estimate:  
4 hours 
 

  
 
 
 
 

 
 Puppet Version: 5.5.4 Puppet Server Version: PE-2018.1.3.1 OS Name/Version: Centos 7.5 You can manage files in puppet with the option "replace => false". Which allow you to not change the content. However, if you decide to remove this file later, by only changing the ensure value, the file will not be removed. How to reproduce: From a Centos docker image, I've created a simple manifest  
 
to create a file with "replace => false" 
apply the manifest 
change the content to check that the replace is working 
apply the manifest, with no change 
Set the file to be 'absent' 
apply the manife

Jira (PUP-3483) Systemd provider doesn't scan for changed units

2018-08-01 Thread vincent lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 vincent lours commented on  PUP-3483  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Systemd provider doesn't scan for changed units   
 

  
 
 
 
 

 
 Hi Eric Thompson, Can you review on the suggested fix and pass it to the Engineering team if it fits puppet's requirements ? That should definitively remove the need of any Notify to a Exec['systemctl-daemon-reload'] for all systemd services.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
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-9021) [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart

2018-07-26 Thread vincent lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 vincent lours updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9021  
 
 
  [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart   
 

  
 
 
 
 

 
Change By: 
 vincent lours  
 

  
 
 
 
 

 
 *Module Version:* Resource Type: service*Puppet Version:* Puppet Enterprise agent, all versions before 2018.1.2*OS Name/Version:* Centos 7Can you add *an option* to allow a Systemd service to be reloaded instead of restarted when Notify (refreshable).Because some of the Systemd service have a reload option to avoid the service to be restarted, and only reload the config.  As example "_httpd_", that you want to keep alive instead of killing/starting all children process.*Desired Behavior:* Something like: {code}notify => Service[httpd = { 'option' :refresh_option  => 'reload'}, service2, service3 = {'option' => 'restart'} ] {code}which can be checked in /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/service.rb filewith something like _(It's just an example as I'm not a Ruby expert and I was not able to follow the full workflow of the Resource Type Service)_:{code}  feature :refreshable, "The provider can restart the service.",  :methods => :refreshable[ 'option' :refresh_option ] == 'reload' ? [:reload] : [:restart]{code}And match a new function in /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/service/systemd.rb{code}  def reloadcmddaemon_reload? #This line can be a new feature requested from PUP-3483[command(:systemctl), "reload", @resource[:name]]  end  def reloadbegin  superrescue Puppet::Error => e  raise Puppet::Error.new(prepare_error_message(@resource[:name], 'restart', e))end  end{code}*Actual Behavior:* notify => Service[httpd]  Which has only one action defined in the puppet agent code: /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/service.rb{code}  Type.newtype(:service) do@doc = "Manage running services.  Service support unfortunately varies  widely by platform --- some platforms have very little if any concept of a  running service, and some have a very codified and powerful concept.  Puppet's service support is usually capable of doing the right thing, but  the more information you can provide, the better behaviour you will get.  Puppet 2.7 and newer expect init scripts to have a working status command.  If this isn't the case for any of your services' init scripts, you will  need to set `hasstatus` to false and possibly specify a custom status  command in the `status` attribute. As a last resort, Puppet will attempt to  search the process table by calling whatever command is listed in the `ps`  fact. The default search pattern is the name of the service, but you can  specify it with the `pattern` attribute.  **Refresh:** `service` resources can respond to refresh events (via  `notify`, `subscribe`, or the `~>` arrow). If a `service` receives an  event from another resource, Puppet will restart the service it manages.  The actual command used to rest

Jira (PUP-9021) [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart

2018-07-26 Thread vincent lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 vincent lours updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9021  
 
 
  [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart   
 

  
 
 
 
 

 
Change By: 
 vincent lours  
 

  
 
 
 
 

 
 *Module Version:* Resource Type: service*Puppet Version:* Puppet Enterprise agent, all versions before 2018.1.2*OS Name/Version:* Centos 7Can you add *an option* to allow a Systemd service to be reloaded instead of restarted when Notify (refreshable).Because some of the Systemd service have a reload option to avoid the service to be restarted, and only reload the config.  As example "_httpd_", that you want to keep alive instead of killing/starting all children process.*Desired Behavior:* Something like: {code}notify => Service[httpd = {:refresh_option => 'reload'}, service2, service3 = { 'option' :refresh_option  => 'restart'} ] {code}which can be checked in /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/service.rb filewith something like _(It's just an example as I'm not a Ruby expert and I was not able to follow the full workflow of the Resource Type Service)_:{code}  feature :refreshable, "The provider can restart the service.",  :methods => :refreshable[:refresh_option] == 'reload' ? [:reload] : [:restart]{code}And match a new function in /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/service/systemd.rb{code}  def reloadcmddaemon_reload? #This line can be a new feature requested from PUP-3483[command(:systemctl), "reload", @resource[:name]]  end  def reloadbegin  superrescue Puppet::Error => e  raise Puppet::Error.new(prepare_error_message(@resource[:name], 'restart', e))end  end{code}*Actual Behavior:* notify => Service[httpd]  Which has only one action defined in the puppet agent code: /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/service.rb{code}  Type.newtype(:service) do@doc = "Manage running services.  Service support unfortunately varies  widely by platform --- some platforms have very little if any concept of a  running service, and some have a very codified and powerful concept.  Puppet's service support is usually capable of doing the right thing, but  the more information you can provide, the better behaviour you will get.  Puppet 2.7 and newer expect init scripts to have a working status command.  If this isn't the case for any of your services' init scripts, you will  need to set `hasstatus` to false and possibly specify a custom status  command in the `status` attribute. As a last resort, Puppet will attempt to  search the process table by calling whatever command is listed in the `ps`  fact. The default search pattern is the name of the service, but you can  specify it with the `pattern` attribute.  **Refresh:** `service` resources can respond to refresh events (via  `notify`, `subscribe`, or the `~>` arrow). If a `service` receives an  event from another resource, Puppet will restart the service it manages.  The actual command used to restart 

Jira (PUP-9021) [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart

2018-07-26 Thread vincent lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 vincent lours updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9021  
 
 
  [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart   
 

  
 
 
 
 

 
Change By: 
 vincent lours  
 

  
 
 
 
 

 
 *Module Version:* Resource Type: service*Puppet Version:* Puppet Enterprise agent, all versions before 2018.1.2*OS Name/Version:* Centos 7Can you add *an option* to allow a Systemd service to be reloaded instead of restarted when Notify (refreshable).Because some of the Systemd service have a reload option to avoid the service to be restarted, and only reload the config.  As example "_httpd_", that you want to keep alive instead of killing/starting all children process.*Desired Behavior:* Something like: {code}notify => Service[httpd ,  = {'option' => '  reload '}, service2, service3 = {'option' => 'restart'} ] {code}which can be checked in /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/service.rb filewith something like _(It's just an example as I'm not a Ruby expert and I was not able to follow the full workflow of the Resource Type Service)_:{code}  feature :refreshable, "The provider can restart the service.",  :methods => :refreshable[ 1 'option' ] == 'reload' ? [:reload] : [:restart]{code}And match a new function in /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/service/systemd.rb{code}  def reloadcmddaemon_reload? #This line can be a new feature requested from PUP-3483[command(:systemctl), "reload", @resource[:name]]  end  def reloadbegin  superrescue Puppet::Error => e  raise Puppet::Error.new(prepare_error_message(@resource[:name], 'restart', e))end  end{code}*Actual Behavior:* notify => Service[httpd]  Which has only one action defined in the puppet agent code: /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/service.rb{code}  Type.newtype(:service) do@doc = "Manage running services.  Service support unfortunately varies  widely by platform --- some platforms have very little if any concept of a  running service, and some have a very codified and powerful concept.  Puppet's service support is usually capable of doing the right thing, but  the more information you can provide, the better behaviour you will get.  Puppet 2.7 and newer expect init scripts to have a working status command.  If this isn't the case for any of your services' init scripts, you will  need to set `hasstatus` to false and possibly specify a custom status  command in the `status` attribute. As a last resort, Puppet will attempt to  search the process table by calling whatever command is listed in the `ps`  fact. The default search pattern is the name of the service, but you can  specify it with the `pattern` attribute.  **Refresh:** `service` resources can respond to refresh events (via  `notify`, `subscribe`, or the `~>` arrow). If a `service` receives an  event from another resource, Puppet will restart the service it manages.  The actual command used to restart the service depends on

Jira (PUP-9021) [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart

2018-07-26 Thread vincent lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 vincent lours updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9021  
 
 
  [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart   
 

  
 
 
 
 

 
Change By: 
 vincent lours  
 

  
 
 
 
 

 
 *Module Version:* Resource Type: service*Puppet Version:* Puppet Enterprise agent, all versions before 2018.1.2*OS Name/Version:* Centos 7Can you add *an option* to allow a Systemd service to be reloaded instead of restarted when Notify (refreshable).Because some of the Systemd service have a reload option to avoid the service to be restarted, and only reload the config.  As example "_httpd_", that you want to keep alive instead of killing/starting all children process.*Desired Behavior:* Something like: {code}notify => Service[httpd, reload] {code}which can be checked in /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/service.rb  filewith  something like _(It's just an example as I'm not a Ruby expert and I was not able to follow the full workflow of the Resource Type Service)_:{code}  feature :refreshable, "The provider can restart the service.",  :methods => :refreshable[1] == 'reload' ? [:reload] : [:restart]{code}And match a new function in /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/service/systemd.rb{code}  def reloadcmddaemon_reload? #This line can be a new feature requested from PUP-3483[command(:systemctl), "reload", @resource[:name]]  end  def reloadbegin  superrescue Puppet::Error => e  raise Puppet::Error.new(prepare_error_message(@resource[:name], 'restart', e))end  end{code}*Actual Behavior:* notify => Service[httpd]  Which has only one action defined in the puppet agent code: /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/service.rb{code}  Type.newtype(:service) do@doc = "Manage running services.  Service support unfortunately varies  widely by platform --- some platforms have very little if any concept of a  running service, and some have a very codified and powerful concept.  Puppet's service support is usually capable of doing the right thing, but  the more information you can provide, the better behaviour you will get.  Puppet 2.7 and newer expect init scripts to have a working status command.  If this isn't the case for any of your services' init scripts, you will  need to set `hasstatus` to false and possibly specify a custom status  command in the `status` attribute. As a last resort, Puppet will attempt to  search the process table by calling whatever command is listed in the `ps`  fact. The default search pattern is the name of the service, but you can  specify it with the `pattern` attribute.  **Refresh:** `service` resources can respond to refresh events (via  `notify`, `subscribe`, or the `~>` arrow). If a `service` receives an  event from another resource, Puppet will restart the service it manages.  The actual command used to restart the service depends on the platform and  can be configured:  * If you set `hasrestart` to tru

Jira (PUP-9021) [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart

2018-07-26 Thread vincent lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 vincent lours updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9021  
 
 
  [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart   
 

  
 
 
 
 

 
Change By: 
 vincent lours  
 

  
 
 
 
 

 
 *Module Version:* Resource Type: service*Puppet Version:* Puppet Enterprise agent, all versions before 2018.1.2*OS Name/Version:* Centos 7Can you add *an option* to allow a Systemd service to be reloaded instead of restarted when Notify (refreshable).Because some of the Systemd service have a reload option to avoid the service to be restarted, and only reload the config.  As example "_httpd_", that you want to keep alive instead of killing/starting all children process.*Desired Behavior:* Something like: {code}notify => Service[httpd, reload]  or notify => Service[httpd =  { option => reload}]{ code}which can be checked in /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/service.rb something like _(It's just an example as I'm not a Ruby expert and I was not able to follow the full workflow of the Resource Type Service)_:{code}  feature :refreshable, "The provider can restart the service.",   if  : refreshable[1] == 'reload': methods =>  [ : reload]  else:methods => [:restart]  end{code}or{code}feature : refreshable , "The provider can restart the service.",  if :refreshable [ 'option' 1 ] == 'reload' :methods =>  ?  [:reload]   else : methods =>  [:restart]   end {code}  And match a new function in /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/service/systemd.rb{code}  def reloadcmddaemon_reload? #This line can be a new feature requested from PUP-3483[command(:systemctl), "reload", @resource[:name]]  end  def reloadbegin  superrescue Puppet::Error => e  raise Puppet::Error.new(prepare_error_message(@resource[:name], 'restart', e))end  end{code}*Actual Behavior:* notify => Service[httpd]  Which has only one action defined in the puppet agent code: /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/service.rb{code}  Type.newtype(:service) do@doc = "Manage running services.  Service support unfortunately varies  widely by platform --- some platforms have very little if any concept of a  running service, and some have a very codified and powerful concept.  Puppet's service support is usually capable of doing the right thing, but  the more information you can provide, the better behaviour you will get.  Puppet 2.7 and newer expect init scripts to have a working status command.  If this isn't the case for any of your services' init scripts, you will  need to set `hasstatus` to false and possibly specify a custom status  command in the `status` attribute. As a last resort, Puppet will attempt to  search the process table by calling whatever command is listed in the `ps`  fact. The default search pattern is the name of the service, but you can  specify it with the `pattern` attribute.  **Refresh:** `service` resources can respond to r

Jira (PUP-9021) [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart

2018-07-26 Thread vincent lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 vincent lours updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9021  
 
 
  [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart   
 

  
 
 
 
 

 
Change By: 
 vincent lours  
 

  
 
 
 
 

 
 *Module Version:* Resource Type: service*Puppet Version:* Puppet Enterprise agent, all versions before 2018.1.2*OS Name/Version:* Centos 7Can you add *an option* to allow a Systemd service to be reloaded instead of restarted when Notify (refreshable).Because some of the Systemd service have a reload option to avoid the service to be restarted, and only reload the config.  As example "_httpd_", that you want to keep alive instead of killing/starting all children process.*Desired Behavior:* Something like: {code}notify => Service[httpd, reload] or notify => Service[httpd  = {option => reload}]{code}which can be checked in /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/service.rb something like _(It's just an example as I'm not a Ruby expert and I was not able to follow the full workflow of the Resource Type Service)_:{code}feature :refreshable, "The provider can restart the service.",  if :refreshable[ 1] == ' reload':methods => [:reload]  else:methods => [:restart]  end{code}or{code}feature :refreshable, "The provider can restart the service.",  if :refreshable[' option'] == 'reload':methods => [:reload]  else:methods => [:restart]  end{code}And match a new function in /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/service/systemd.rb{code}  def reloadcmddaemon_reload? #This line can be a new feature requested from PUP-3483[command(:systemctl), "reload", @resource[:name]]  end  def reloadbegin  superrescue Puppet::Error => e  raise Puppet::Error.new(prepare_error_message(@resource[:name], 'restart', e))end  end{code}*Actual Behavior:* notify => Service[httpd]  Which has only one action defined in the puppet agent code: /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/service.rb{code}  Type.newtype(:service) do@doc = "Manage running services.  Service support unfortunately varies  widely by platform --- some platforms have very little if any concept of a  running service, and some have a very codified and powerful concept.  Puppet's service support is usually capable of doing the right thing, but  the more information you can provide, the better behaviour you will get.  Puppet 2.7 and newer expect init scripts to have a working status command.  If this isn't the case for any of your services' init scripts, you will  need to set `hasstatus` to false and possibly specify a custom status  command in the `status` attribute. As a last resort, Puppet will attempt to  search the process table by calling whatever command is listed in the `ps`  fact. The default search pattern is the name of the service, but you can  specify it with the `pattern` attribute.  **Refresh:** `service` resources can respond to refresh events (via  `noti

Jira (PUP-9021) [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart

2018-07-26 Thread vincent lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 vincent lours commented on  PUP-9021  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart   
 

  
 
 
 
 

 
 The Issue PUP-3483 - "Systemd provider doesn't scan for changed units" was the initial reference for my Systemd enhancement. I've submitted a updated code to fix the "deamon-reload" refresh on Systemd Servers.  Which make me thought about the missing reload from systemd services.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
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-9021) [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart

2018-07-26 Thread vincent lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 vincent lours created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9021  
 
 
  [Resource Type: service][Enhancement] Allow a Systemd service to be reload from a notify instead of restart   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 Types and Providers  
 
 
Created: 
 2018/07/26 5:29 AM  
 
 
Environment: 
 All OS using the provider systemd  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 vincent lours  
 

  
 
 
 
 

 
 Module Version: Resource Type: service Puppet Version: Puppet Enterprise agent, all versions before 2018.1.2 OS Name/Version: Centos 7 Can you add an option to allow a Systemd service to be reloaded instead of restarted when Notify (refreshable). Because some of the Systemd service have a reload option to avoid the service to be restarted, and only reload the config.  As example "httpd", that you want to keep alive instead of killing/starting all children process. Desired Behavior: Something like:   
 
 
 
 
 notify => Service[httpd, reload]   
 
 
 or   
 
 
 notify => Service[httpd{option => reload}]
  
 
   

Jira (PUP-3483) Systemd provider doesn't scan for changed units

2018-07-19 Thread vincent lours (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 vincent lours commented on  PUP-3483  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Systemd provider doesn't scan for changed units   
 

  
 
 
 
 

 
 Hi guys, Based on Hunter (Hunner) Haugen's comment, I was able to implement this functionality in the Puppet Agent code. Even if I'm not a Ruby Expert, it was quite simple to figure how to implement it. Including this code in the Puppet Agent code will check if the "NeedDaemonReload" is set to 'yes' or everything else (default: 'no') Which will cause a "systemctl daemon-reload" only once, when required. The NeedDaemonReload check will be called on every "start" or "restart" actions. But the daemon-reload action will occur only once at the first match, as it will fix all other NeedDaemonReload requests once executed. Including this code in the puppet agent will definitively remove the need of any Notify to a Exec['systemctl-daemon-reload'] for all systemd Services managed in puppet. The code has been checked/validated with puppet-agent version 5.5.3-1.el7.x86_64. Feel Free to test and improve it.  
 
 
 
 
 # diff -ruN /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/service/systemd.rb.ori /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/service/systemd.rb  
 
 
 --- /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/service/systemd.rb.ori	2018-07-20 05:21:43.852724847 +  
 
 
 +++ /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/service/systemd.rb	2018-07-20 05:37:42.513155599 +  
 
 
 @@ -121,6 +121,15 @@  
 
 
  end  
 
 
end  
 
 
    
 
 
 +  def daemon_reload?  
 
 
 +cmd = [command(:systemctl), 'show', @resource[:name], '--property=NeedDaemonReload']