[Gluster-users] gluster v6.8: systemd units disabled after install

[Hu Bert]

Hi Alex & Strahil,

I (roughly) documented the installation process:

- install gluster packages
- start services (glusterd, glustereventsd) manually
- create volume & mount

After that i did a reboot of server1 to see if everything's fine
afterwards - no, services weren't started. Same on server2. On server3
i enabled both services -> after the reboot everything was fine.

That was the status on server1:

systemctl status glusterd.service
● glusterd.service - GlusterFS, a clustered file-system server
   Loaded: loaded (/lib/systemd/system/glusterd.service; disabled;
vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:glusterd(8)

preset: enabled; but status disabled - i don't know how that may have
happened, as i surely didn't disable them. Strange.


Best Regards,
Hubert

Am Sa., 11. Apr. 2020 um 15:25 Uhr schrieb Strahil Nikolov
<hunter86_bg at yahoo.com>:
>
> On April 11, 2020 2:19:54 PM GMT+03:00, Alexander Iliev <ailiev+gluster at mamul.org> wrote:
> >Hi Hubert,
> >
> >I think this would vary from distribution to distribution and it is up
> >to the package maintainers of the particular distribution to decide
> >what
> >the default should be.
> >
> >I am using Gluster 6.6 on CentOS and the Gluster-specific services
> >there
> >were also disabled (although not exactly as in your original post - the
> >
> >vendor preset was also disabled for me, while it is enabled for you).
> >
> >This is only a speculation for this particular case, but I think the
> >idea in general is to have the system administrator explicitly enable
> >the services he wants running on reboot.
> >
> >I would argue that this is the safer approach as opposed to enabling a
> >service automatically after its installation. An example scenario would
> >
> >be - you install a service, the system is rebooted, e.g. due to a power
> >
> >outage, mistyped command, etc., the service is started automatically
> >even though it hasn't been properly configured yet.
> >
> >I guess, to really know the reasoning, the respective package
> >maintainers would need to jump in and share their idea behind this
> >decision.
> >
> >Best regards,
> >--
> >alexander iliev
> >
> >On 4/11/20 7:40 AM, Hu Bert wrote:
> >> Hi,
> >>
> >> so no one has seen the problem of disabled systemd units before?
> >>
> >> Regards,
> >> Hubert
> >>
> >> Am Mo., 6. Apr. 2020 um 12:30 Uhr schrieb Hu Bert
> ><revirii at googlemail.com>:
> >>>
> >>> Hello,
> >>>
> >>> after a server reboot (with a fresh gluster 6.8 install) i noticed
> >>> that the gluster services weren't running.
> >>>
> >>> systemctl status glusterd.service
> >>> ● glusterd.service - GlusterFS, a clustered file-system server
> >>>     Loaded: loaded (/lib/systemd/system/glusterd.service; disabled;
> >>> vendor preset: enabled)
> >>>     Active: inactive (dead)
> >>>       Docs: man:glusterd(8)
> >>>
> >>> Apr 06 11:34:18 glfsserver1 systemd[1]:
> >>> /lib/systemd/system/glusterd.service:9: PIDFile= references path
> >below
> >>> legacy directory /var/run/, updating /var/run/glusterd.pid →
> >>> /run/glusterd.pid; please update the unit file accordingly.
> >>>
> >>> systemctl status glustereventsd.service
> >>> ● glustereventsd.service - Gluster Events Notifier
> >>>     Loaded: loaded (/lib/systemd/system/glustereventsd.service;
> >>> disabled; vendor preset: enabled)
> >>>     Active: inactive (dead)
> >>>       Docs: man:glustereventsd(8)
> >>>
> >>> Apr 06 11:34:27 glfsserver1 systemd[1]:
> >>> /lib/systemd/system/glustereventsd.service:11: PIDFile= references
> >>> path below legacy directory /var/run/, updating
> >>> /var/run/glustereventsd.pid → /run/glustereventsd.pid; please update
> >>> the unit file accordingly.
> >>>
> >>> You have to enable them manually:
> >>>
> >>> systemctl enable glusterd.service
> >>> Created symlink
> >>> /etc/systemd/system/multi-user.target.wants/glusterd.service →
> >>> /lib/systemd/system/glusterd.service.
> >>> systemctl enable glustereventsd.service
> >>> Created symlink
> >>> /etc/systemd/system/multi-user.target.wants/glustereventsd.service →
> >>> /lib/systemd/system/glustereventsd.service.
> >>>
> >>> Is this a bug? If so: already known?
> >>>
> >>>
> >>> Regards,
> >>> Hubert
> >> ________
> >>
> >>
> >>
> >> Community Meeting Calendar:
> >>
> >> Schedule -
> >> Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
> >> Bridge: https://bluejeans.com/441850968
> >>
> >> Gluster-users mailing list
> >> Gluster-users at gluster.org
> >> https://lists.gluster.org/mailman/listinfo/gluster-users
> >>
> >________
> >
> >
> >
> >Community Meeting Calendar:
> >
> >Schedule -
> >Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
> >Bridge: https://bluejeans.com/441850968
> >
> >Gluster-users mailing list
> >Gluster-users at gluster.org
> >https://lists.gluster.org/mailman/listinfo/gluster-users
>
> Hi Alex,
>
> The vendor preset is 'enabled' which means that after  install it's enabled.
> So either  someone disabled it manually or  there is a dependency issue (for example systemd can disable a service that is causing a dependency loop - for example:
> A  after B , B after C, C after A ).
>
>
> Best Regards,
> Strahil Nikolov