> What do you need to work around? Isn't Upstart, from a userspace
> perspective, completely backwards compatible with SysV init?
>
> Can you cite your specific issues?
Yes and no; or at least that's my understanding. From what I've seen
it can be used in such a way that it appears to be sysvinit
compatible, but it doesn't have to be. For example, I can drop a file
with the following contents into /etc/event.d on a Fedora 10 box and
it will behave as a service, even though the traditional /etc/rcN.d
directories are not populated at all:
# /etc/event.d/example
start on stopped rc2
start on stopped rc3
start on stopped rc4
stop on runlevel 0
stop on runlevel 1
stop on runlevel 6
respawn
exec /usr/bin/example_daemon --arg1 --arg2
>From the CLI, I can manage this service with things like:
initctl start example
initctl stop example
initctl status example
What I've done this far in puppet is:
exec { "example-service":
command => "initctl start example",
onlyif => "initctl status example | grep -qv running",
}
So maybe it's wrong to expect the service type to handle this. Maybe
we need a specific upstart type instead?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
