Alexander Iliev
2020-Apr-11 11:19 UTC
[Gluster-users] gluster v6.8: systemd units disabled after install
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 >
Strahil Nikolov
2020-Apr-11 13:25 UTC
[Gluster-users] gluster v6.8: systemd units disabled after install
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-usersHi 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