[ClusterLabs] Fedora 31 - systemd based resources don't start

[Ricardo Esteves]

Hi,

Yes, i also don't understand why is trying to stop them first.

SELinux is disabled:

# getenforce
Disabled

All systemd services controlled by the cluster are disabled from
starting at boot:

# systemctl is-enabled httpd
disabled

# systemctl is-enabled openvpn-server at 01-server
disabled


On 17/02/2020 20:28, Ken Gaillot wrote:
> On Mon, 2020-02-17 at 17:35 +0000, Maverick wrote:
>> Hi,
>>
>> When i start my cluster, most of my systemd resources won't start:
>>
>> Failed Resource Actions:
>>   * apache_stop_0 on boss1 'OCF_TIMEOUT' (198): call=82,
>> status='Timed Out', exitreason='', last-rc-change='1970-01-01
>> 01:00:54 +01:00', queued=29ms, exec=197799ms
>>   * openvpn_stop_0 on boss1 'OCF_TIMEOUT' (198): call=61,
>> status='Timed Out', exitreason='', last-rc-change='1970-01-01
>> 01:00:54 +01:00', queued=1805ms, exec=198841ms
> These show that attempts to stop failed, rather than start.
>
>> So everytime i reboot my node, i need to start the resources manually
>> using systemd, for example:
>>
>> systemd start apache
>>
>> and then pcs resource cleanup
>>
>> Resources configuration:
>>
>> Clone: apache-clone
>>   Meta Attrs: maintenance=false
>>   Resource: apache (class=systemd type=httpd)
>>    Meta Attrs: maintenance=false
>>    Operations: monitor interval=60 timeout=100 (apache-monitor-
>> interval-60)
>>                start interval=0s timeout=100 (apache-start-interval-
>> 0s)
>>                stop interval=0s timeout=100 (apache-stop-interval-0s)
>>
>>
>>
>> Resource: openvpn (class=systemd type=openvpn-server at 01-server)
>>    Meta Attrs: maintenance=false
>>    Operations: monitor interval=60 timeout=100 (openvpn-monitor-
>> interval-60)
>>                start interval=0s timeout=100 (openvpn-start-interval-
>> 0s)
>>                stop interval=0s timeout=100 (openvpn-stop-interval-
>> 0s)
>>
>>
>>
>> Btw, if i try a debug-start / debug-stop the mentioned resources
>> start and stop ok.
> Based on that, my first guess would be SELinux. Check the SELinux logs
> for denials.
>
> Also, make sure your systemd services are not enabled in systemd itself
> (e.g. via systemctl enable). Clustered systemd services should be
> managed by the cluster only.