Service is not enabled for autostart at reboot

[zerr0s]

Hello, Forgive me for my bad english.

I've set the "postgresql_service_enabled: true" but the service is not "enabled" after running the role. When I try to make a grep, I can't find any tasks using this variable:

grep -ri postgresql_service_enabled *
defaults/main.yml:postgresql_service_enabled: true
README.md:postgresql_service_enabled: false # should the service be enabled, default is true

Is there a way to autostart the service using the original role ? Actually I have added this task in configure.yml:

- name: PostgreSQL | Enable PostgreSQL service
  service:
    name: "postgresql-{{ postgresql_version }}"
    enabled: yes
  when: postgresql_service_enabled

[gclough]

Can you please give some more information:

• Operating System, and version
• Details of the state of the service auto-start (systemctl status, etc.)
• Output from the Ansible log, where this part of the role was run

[zerr0s]

OS: CentOS 7.3 status:

[root@db ~]# systemctl status postgresql-10.service
● postgresql-10.service - PostgreSQL 10 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-10.service; disabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/postgresql-10.service.d
           custom.conf
   Active: active (running) since Mon 2018-06-18 14:06:12 CEST; 1min 32s ago
     Docs: https://www.postgresql.org/docs/10/static/
 Main PID: 12700 (postmaster)
   CGroup: /system.slice/postgresql-10.service
...

And this the log of the part of the role ansible.log

Ansible version: 2.4.3

[gclough]

Hmmm... I think you're right. This piece of code(ish) should be in the role:

- name: PostgreSQL | Enable service
  service:
    name: "{{ postgresql_service_name }}"
    enabled: yes
  when: postgresql_service_enabled

But I can't find it anywhere:

https://github.com/ANXS/postgresql/search?q=postgresql_service_enabled&unscoped_q=postgresql_service_enabled

I'm slammed this week, but maybe @jlozadad @UnderGreen , or @sebalix can help out.

[tvigers]

Hi,

The service currently is getting enabled by the following task calling a handler:

- name: PostgreSQL | Ensure the systemd directory for PostgreSQL exists | RedHat
  file:
    name: "/etc/systemd/system/postgresql-{{ postgresql_version }}.service.d"
    state: directory
    mode: 0755
  when: ansible_os_family == "RedHat"
  notify: restart postgresql with systemd

The handler is what is enabling the service in systemd:

  - name: restart postgresql with systemd
    systemd:
      name: "{{ postgresql_service_name }}"
      state: restarted
      enabled: yes
    when: ansible_service_mgr == 'systemd'

Which is working for me when installing PostgreSQL 9.6.

[root@postgresql ~]# systemctl status postgresql-9.6
● postgresql-9.6.service - PostgreSQL 9.6 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-9.6.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/postgresql-9.6.service.d
           └─custom.conf
   Active: active (running) since Mon 2018-07-02 14:20:34 UTC; 43min ago

It would might be better to have two tasks one for "systemd" and one for "service" so if any changes are made to the systemd unit file it can call daemon_reload.

Regards,

Tim

[aoyawale]

@tvigers your last comment is what I had submitted originally. I haven't been keeping track of what has changed but, it was there.

[milliams]

@tvigers Indeed the service is being started but it's not being enabled. Being enabled means that it's auto-started on system boot. The variable postgresql_service_enabled in this role is currently not used anywhere and does nothing as far as I can tell.

[poikilotherm]

Just stumbled over this... Can we expect a fix anytime soon or should someone open a PR to help out?

[devantoine]

Hitting this issue right now, the service is never enabled.

[github-actions[bot]]

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

[github-actions[bot]]

This issue has been closed due to inactivity. If you feel this is in error, please reopen the issue or file a new issue with the relevant details.