Today I noticed after building and pushing my Ansible script to a new Ubuntu 12.04 build that it complained about S20sssd not being valid during boot. My first thought was sssd is not a init.d job but an upstart job. After looking more into the issue it seems the service module when set to enabled=yes inserts these files via update-rc.d. After looking at the source code it seems that we are using update.rc.d even for an upstart job or init job based on this:
elif os.path.exists(“/etc/init/%s.conf” % self.name):
service is managed by upstart
self.enable_cmd = location[‘update-rc.d’]
elif os.path.exists(“/etc/init.d/%s” % self.name):
service is managed by with SysV init scripts, but with update-rc.d
self.enable_cmd = location[‘update-rc.d’]
I tried searching the groups and repository for a conversation about upstart but haven’t come across much. Has it been discussed about using the .override file method to detect if the service is disabled or enabled and to disable and enable the upstart job? When looking at the code it seems like you want to stick with a binary that edits the state of the service. After reading some posts on the Ubuntu mail threads it doesn’t look like an update to initctrl or a separate binary that has this functionality is not going to be available anytime soon. So I’m trying figure out if a pull request would be considered by adding and removing .override files in /etc/init to enable and disable upstart jobs. If this isn’t an option that you would consider that Ansible just ignore the enabled argument of an upstart job in the service module. As of right now it cannot even disable the service and inserting init.d scripts via update-rc.d is completely wrong and causing boot error messages.
Thanks,
Chris
PR’s are always welcome, the main question I have is how are you going to be able to tell the difference between an upstart job on that should be managed via the init.d?
Can you please share the actual error message you saw on boot?
Haven’t heard any problems with any upstart services before in this scenario.
That being said, not many people have been enabling FreeIPA on Ubuntu given it’s a Red Hat project, but I’d like this to be functional.
Where did you install sssd from?
If you look at the code above that I pasted you are already differentiating between an upstart init script and a stystem-v script by where you find first(a .conf file in /etc/init then /etc/init.d). I would still use the same logic but change the actions using echo and the rm commands to the .override file. I tried finding a init.d System-V style script that has both and the only thing I came across was ssh but it only invokes it that way if it is in a chroot environment. In this case I would assume that running and managing a chroot environment and ssh is not common(I could be wrong…). The update-rc.d command is only to be used for System-V init script links as the man page says. So using this on an upstart job is not appropriate. I’m really only familiar with Ubuntu using upstart but from the research I’ve been doing this morning, package maintainers are either putting an upstart job for their service or the old System-V style. Even if a package maintainer gave you both, the upstart would conflict because upstart is going to start start unless the line ‘manual’ is at the end of the .conf file in /etc/init or if there is an .override file with the line ‘manual’. Hopefully this answers your question.
You can find that .override method is riddle through the Ubuntu Forums and it is also stated in Ubunto Upstart cookbook http://upstart.ubuntu.com/cookbook/.
Michael,
Here is the output from the console on boot:
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service S20sssd start
- Stopping System V initialisation compatibility [ OK ]
- Starting System V runlevel compatibility [ OK ]
- Starting save kernel messages [ OK ]
- Starting ACPI daemon [ OK ]
initctl: Unknown job: S20sssd
SSSD still starts but the reason I started looking at this was because of this error message on the console. That is when I started looking at the Ansible code to see how it was handling the upstart jobs enable and disable, which it really doesn’t. It just slams down the configs via update-rc.d and puts unnecessary files in the rc.*.d directories or removes them, still letting the upstart job start the service. As of right now Ansible cannot disable an upstart job. It doesn’t really break anything but it is not doing anything besides causing error messages at boot . When looking at the code it looks like you want a binary to manage this. Since this doesn’t exist would you consider it appropriate for Ansible to be handling the .override files with echos into file and removing the files? I guess if you did want to wait for an actual binary to handle this, can we just break out of the if statement so no action is taken on a disable or enable of a upstart job? I’m fine with adding the code to handle this either way but wanted to get your guy’s opinion on the matter before I started any work. BTW the package came from the universe repository: http://ubuntu.cs.utah.edu/ubuntu/pool/universe/s/sssd/
Thanks,
Chris
Yeah, I think definitely go ahead and send us a PR and we’ll get it reviewed.
Thanks!
Cool, Started working on the solution today should have something Friday or Monday.
-Chris
Please note .override files are not only for enabling/disabling services.
They can also be used to e.g. override exec line to pass debugging params and
things like that.
May be safer to just add/remove the 'manual' stanza from the file.
I’ve already taken this into account. It will fail if it detects the .conf file with the ‘manual’ line, it will only create and remove .override file if only the ‘manual’ line exists in it, and it will only and add or remove the ‘manual’ line if the .override file has other data.
-Chris