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

[Strahil Nikolov]

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