Hey Guys,
I am working with an old Fedora ( 15 ) which has systemd enabled by default, but many of the services are still controlled by the old Sys V init scripts ( including sshd and auditd ). Looking through the service module, I noticed that for upstart you check to see if the upstart init script exists but there is no equivalent for systemd. Unfortunately you cannot use systemctl list-units as it includes services that were started with basic init scripts. You could search the directories [ /usr/lib/systemd/system, /run/systemd/system, /etc/systemd/system ] for the unit file ( assuming the name would be “%s.service”% self.name ).
I ended up just checking to see if self.svc_initscript is None in order for systemd to be chosen: For example
`
Locate a tool to enable/disable a service
if location.get(‘systemctl’,False) and check_systemd() and self.svc_initscript is None:
service is managed by systemd
self.__systemd_unit = self.name
self.svc_cmd = location[‘systemctl’]
self.enable_cmd = location[‘systemctl’]
`
I am not sure what is the best way to handle this check and would not call myself an init system expert, but if you guys think this quicker fix is good I can create a pull request.
Thanks,
Tony
I'm not sure why you are checking this, systemd can act upon the sysV
scripts, we actually patched it this way as the previous behavior of
using the scripts directly led to conflicts with systemd users.
Really? I am having trouble with it, granted I am using a relatively ancient operating system.
`
- name: restart ssh RedHat
sudo: yes
service: name=sshd state=restarted
when: ansible_os_family == ‘RedHat’
ignore_errors: yes
{“failed”: true}
msg: failure 1 running systemctl show for ‘sshd’: Failed to issue method call: Unit name sshd is not valid.
`
I know in the issue ( #915 ansible-modules-core ) I put the auditd call which was doing both start and enabled but I am having issues with all states currently. Any chance you can point me to the issue that caused you to change the behavior so it calls systemctl even if the service is an init.d script. I chose to use the init script because that mimicked the behavior that the /sbin/service bash script does on both Fedora 15 and Centos7.
Centos7 – SERVICEDIR = /etc/init.d/
`
[centos@master-1 ~]$ tail -n 11 $(which service)
if [ -f “${SERVICEDIR}/${SERVICE}” ]; then
env -i PATH=“$PATH” TERM=“$TERM” SYSTEMCTL_IGNORE_DEPENDENCIES=${SYSTEMCTL_IGNORE_DEPENDENCIES} SYSTEMCTL_SKIP_REDIRECT=${SYSTEMCTL_SKIP_REDIRECT} “${SERVICEDIR}/${SERVICE}” ${ACTION} ${OPTIONS}
elif [ -x “${ACTIONDIR}/${SERVICE}/${ACTION}” -a -n “${ACTION}” ]; then
env -i PATH=“$PATH” TERM=“$TERM” SYSTEMCTL_IGNORE_DEPENDENCIES=${SYSTEMCTL_IGNORE_DEPENDENCIES} SYSTEMCTL_SKIP_REDIRECT=${SYSTEMCTL_SKIP_REDIRECT} “${ACTIONDIR}/${SERVICE}/${ACTION}” ${OPTIONS}
elif echo $ACTION | egrep -qw "start|stop|restart|try-restart|reload|force-reload|status|condrestart" ; then
echo $“Redirecting to /bin/systemctl ${ACTION} ${OPTIONS} ${SERVICE}.service” >&2
exec /bin/systemctl ${ACTION} ${OPTIONS} ${SERVICE}.service
else
echo $“The service command supports only basic LSB actions (start, stop, restart, try-restart, reload, force-reload, status). For other actions, please try to use systemctl.” >&2
exit 2
fi
`
Sorry I know this type of bug is more of a nuisance than really critical, but I appreciate your help.
Tony
Great to make matters worse, I do not have any issues with influxdb on CentOS 7 which is purely an SysV script. It’s probably a difference in systemd versions. Fedora 15 is systemd 26 vs Centos7 is systemd 208.
Sorry I should probably have tested this first. I understand if you guys just chalk it up as a systemd bug rather than a bug with ansible ( especially since Fedora 15 is out of service ). Hopefully my team will update the operating system soon.
Tony
Not sure, depends, this probably can be solved by detecting version
and seeing if a different behavior is needed, but I'm not sure what
that would be considering what I've learnt up to now.