#1937 PR merged: Remove After=syslog.target form dbus.service #1230¶

Labels: enhancement, cleanup, fixed / solved / done

gdha opened issue at 2018-10-22 16:03:¶

• Type: Enhancement

• Impact: Low

• Reference to related issue (URL): #1230

• How was this pull request tested? will test via rear-automated-testing

• Brief description of the changes in this pull request: see issue #1230

jsmeix commented at 2018-10-23 07:38:¶

@gdha
I am afraid I cannot actually review systemd related things because
in practice I had to learn that I know nothing about systemd units setup:
Each time I tried to get any systemd unit setup done things ended in havoc.
Probably systemd is just too complicated for a simple mind like me
or systemd is a too fast moving target for a slow mind like mine ;-)

According to
https://github.com/rear/rear/issues/1230#issuecomment-311085676
from Jun 26, 2017 the syslog.target became obsolete by now
so that I wonder if disabling of After=syslog.target may cause
regressions when ReaR is used on an older system were an
older systemd is in use where that target is still needed?
Simply put: Is that change here sufficiently backward compatible?

@rear/contributors
could another ReaR contributor have a look here?

gdha commented at 2018-10-23 16:18:¶

@jsmeix The dbus.service file was created by me 7 years ago for Fedora 16 of 17 (I guess), or equal to RHEL 6 (I think). However, RHEL 6 is still not using systemd so we are on the safe side here.
All more recent Linux distributions are evolved from the old systemd incarnation, so we are good here as well. I'm pretty sure it will not have a negative impact on the start-up of systemd based systems.

jsmeix commented at 2018-10-24 08:12:¶

@gdha
thank you for the explanation.

Because After=syslog.target will get only disabled but not completely removed
we are fully sufficiently on the safe side here because a user of an old systemd
can manually re-enable it again if he needs it in his particular case.

---

[Export of Github issue for rear/rear.]