Force ordering on systemd daemon reload before service restart about puppet-systemd HOT 15 CLOSED

This is confirmed, and this is a documentation issue. The only way I can get the service to restart AFTER the daemon-reload is using the extra 'require' -

class autologin::ubuntu {
        $srcfile = "puppet:///modules/autologin/ubuntu"
        $dest = "/etc/systemd/system/[email protected]/override.conf"

        systemd::dropin_file { 'override.conf':
                unit => '[email protected]',
                source => $srcfile,
        } ~> service { '[email protected]':
                ensure => 'running',
                require => Class['systemd::systemctl::daemon_reload'],
        }
}

from puppet-systemd.

@xrobau could you provide a PR to update the README.md?

from puppet-systemd.

Oh, if you do decide to do this, make sure to restrict the collector to systemd services only

from puppet-systemd.

@bastelfreak @ekohl @trevor-vaughan

what do you think of https://github.com/Yelp/puppet-systemd/pull/1 ?

from puppet-systemd.

I think closing this was a bad idea. #191 does add the collector (which is now safe due to daemon-reload removal), but still defaults to false. I've submitted #194 to resolve this issue.

from puppet-systemd.

What if there was a collector that ensured this always happened?

Class['systemd::systemctl::daemon_reload'] -> Service <||>

And then nobody could "forget" to do this or "forget" to read the docs?

from puppet-systemd.

@solarkennedy I've had cases where daemon_reload fails. I really don't want all of my Services to stop doing things because of that.

from puppet-systemd.

They wouldn't stop, but it is true, they wouldn't get refreshed during that puppet run.
But if you couldn't daemon-reload, refreshing them wouldn't help much anyway?

from puppet-systemd.

I like the idea of a collector @solarkennedy

I guess the downside that @trevor-vaughan is talking about is that you could have two services. One where the unit file changes, one where a different config changes and the second service would fail to refresh even though it didn't strictly depend on the daemon-reload.

However, I think the need for puppet to converge trumps a failed run which will converge once you fix whatever is breaking daemon-reload. I'd rather that we never have a case of a puppet run missing a service refresh (and then that service never gets restarted!) just because somebody forget to add the explicit dependency on the daemon-reload.

from puppet-systemd.

The chance of a circular dependency with such a collector is rather large. Imagine a class containing all its resources (including a service) and another class also containing all its resources that depends on the first class.

from puppet-systemd.

@ekohl That's probably a better reason not to do this than the failed service.

@mattmb The issue is that this isn't Puppet convergence (it did that during the catalog compilation), this is the system having a bug that will cause currently loaded applications to not work. So it affects previously running services instead of just new ones.

The last time I hit this issue, I couldn't resolve it without a system reboot which would have been forced much earlier if all of my services had stopped triggering.

from puppet-systemd.

Sorry, that might have been confusing, when I said convergence I meant convergence of the state of the system with what is declared in puppet. And the reason I'd love a general solution is that I don't want a case where puppet does: "change unit file" -> "restart service" -> "reload-daemon" which means that the changes in the unit file are not applied and won't even be applied in the next puppet run.

from puppet-systemd.

@ekohl can you help me visualise the circular dependency risk? If ClassA requires ClassB and both have a service defined in them and both those services require Class['systemd::systemctl::daemon_reload'] then won't puppet just do:

• Class['systemd::systemctl::daemon_reload']
• ClassB
• ClassA

from puppet-systemd.

I just ran into this ordering issue too. I agree that the resource collector is ugly but can't think of a better solution that doesn't involve having to wrap the service type as well.

from puppet-systemd.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from puppet-systemd.