[SOLVED] Systemctl shows inactive service in PCS Cluster

stonith · 01-31-2018, 08:41 AM

Hi all,
first post here hence thanks to all who are reading.
I've a two node pcs cluster with VIP Address, a bounch of other resources and a vsftpd service.
My question is: we are able to login to ftp service and use it but, meanwhile, systemctl shows the vsftpd service as inactive and unloaded in the running host (and obviously on the other one).
Is that behaviour correct? I'm supposed to monitor the status with a nagios based product looking at the service status but I'm actually unable to do it.

Thanks in advance.

JockVSJock · 01-31-2018, 06:36 PM

What OS are you using?

Using systemd? If so, what happens if you try to restart the daemon?

Code:

systemctl status service-goes-here && systemctl restart service-goes-here

Does journalctl show anything along with system-analyze?

stonith · 02-01-2018, 02:29 AM

Quote:

Originally Posted by JockVSJock

What OS are you using?

Using systemd? If so, what happens if you try to restart the daemon?

Code:

systemctl status service-goes-here && systemctl restart service-goes-here

Does journalctl show anything along with system-analyze?

Hi,

we're using Centos 7.3.1611

if we run systemctl status vsftpd the output goes like this:

Code:

[root@visualweather-cls2 ~]# systemctl status vsftpd && systemctl restart vsftpd
● vsftpd.service - Vsftpd ftp daemon
   Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; disabled; vendor preset: disabled)
   Active: inactive (dead)

Jan 30 15:44:06 visualweather-cls2 systemd[1]: Starting Vsftpd ftp daemon...
Jan 30 15:44:09 visualweather-cls2 systemd[1]: vsftpd.service: control process exited, code=exited status=1
Jan 30 15:44:09 visualweather-cls2 systemd[1]: Failed to start Vsftpd ftp daemon.
Jan 30 15:44:09 visualweather-cls2 systemd[1]: Unit vsftpd.service entered failed state.
Jan 30 15:44:09 visualweather-cls2 systemd[1]: vsftpd.service failed.
[root@visualweather-cls2 ~]#

journalctl doesn't give us any clue.

I noticed that the resource seems to have a proprietary provider:

Code:

Cluster name: visualweathercls
Stack: corosync
Current DC: visualweather-cls1 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Thu Feb  1 09:27:49 2018          Last change: Sat Jan 27 12:55:22 2018 by hacluster via crmd on visualweather-cls1

2 nodes and 8 resources configured

Online: [ visualweather-cls1 visualweather-cls2 ]

Full list of resources:

 virtual_ip     (ocf::heartbeat:IPaddr2):       Started visualweather-cls2
 Resource Group: vw-storage
     vw-app     (ocf::heartbeat:Filesystem):    Started visualweather-cls2
     vw-supercache      (ocf::heartbeat:Filesystem):    Started visualweather-cls2
     vw-home    (ocf::heartbeat:Filesystem):    Started visualweather-cls2
     vw-data    (ocf::heartbeat:Filesystem):    Started visualweather-cls2
     area_test  (ocf::heartbeat:Filesystem):    Started visualweather-cls2
 VisualWeather  (ocf::ibl:visualweather):       Started visualweather-cls2
 vsftpd (ocf::ibl:vsftpd):      Started visualweather-cls2

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

this could be done by a custom installation by the software team, I'm going to investigate that thing.

sgrlscz · 02-01-2018, 11:58 AM

When you're running as a cluster, the cluster resource manager controls the services that are defined as resources. So, if vsftpd is defined as a cluster resource, then the cluster software would be managing it.

Systemd would be used to start/stop the cluster service, then the cluster service would control starting/stopping the cluster resources.

stonith · 02-02-2018, 03:08 AM

Quote:

Originally Posted by sgrlscz

When you're running as a cluster, the cluster resource manager controls the services that are defined as resources. So, if vsftpd is defined as a cluster resource, then the cluster software would be managing it.

Systemd would be used to start/stop the cluster service, then the cluster service would control starting/stopping the cluster resources.

What give me nuts is that on corosync/pacemaker running on Centos/RHEL v 6.x we don't notice a similar behaviour. For istance, we have an nfs server running several fs shares over network. Once started we already have the control of the daemon by simply submit "service nfs status".
Maybe there could be some differences between the cluster stacks?

sgrlscz · 02-02-2018, 07:44 AM

Quote:

Originally Posted by stonith

What give me nuts is that on corosync/pacemaker running on Centos/RHEL v 6.x we don't notice a similar behaviour. For istance, we have an nfs server running several fs shares over network. Once started we already have the control of the daemon by simply submit "service nfs status".
Maybe there could be some differences between the cluster stacks?

It's more likely it's because there is a huge difference between systemd and chkconfig/service.

On Centos/RHEL 6, the startup scripts could be run by calling them directly or using the service command or enabling them through chkconfig, and you'd get the same behavior because they are doing the same thing. The service command is just a script that invokes the startup script, so it doesn't distinguish between services enabled through chkconfig or started by directly invoking the startup script.

Systemd is completely different, and if it's not controlling the service itself, it can't report the status of the service. So, if corosync/pacemaker starts vsftp on it's own, systemd doesn't know it's running.

stonith · 02-02-2018, 07:47 AM

Thanks for your reply, everything is clear now