Am Wed, 5 Oct 2016 18:00:41 +0530
schrieb "Raghavendra. H. R" <>:

> Andrei,
> Your doubt is absolutely correct. Default target of the system as
> nothing to do with auto start of services.
> I checked both &, surprisingly I
> don't see any big difference in these. Both of the files are almost
> same except have dependency *After=* with
> *rescue.service &* which is restricting
> from starting.
> However don't depend on rescue services, so it is
> active & started. And by making as dependency in my
> unit file solved my problem.
> Hopefully if I remove the rescue services dependency from
> and add it as dependency then my service should
> come up without failures.

"After=" does not have such an impact. It won't block a service from
starting if the services in "After=" aren't started. It's just an
ordering dependency. If the dependents aren't enabled they are just
ignored. Instead, "Requires=" and "Wants=" give stronger dependencies.

You can check the status of

$ systemctl status
● - Multi-User System
   Loaded: loaded (/usr/lib/systemd/system/; static; vendor 
preset: disabled)
   Active: active since Mo 2016-10-03 16:44:14 CEST; 3 days ago
     Docs: man:systemd.special(7)

Okt 03 16:44:14 jupiter.sol.local systemd[1]: Reached target Multi-User System.

$ systemctl get-default

As you see, has been pulled in for me. You can check
the order of targets started with:

$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character. @5.383s
└─ @5.383s
  └─ @5.383s
    └─systemd-nspawn@gentoo\x2delasticsearch\x2dbase.service @2.219s +3.164s
      └─ @2.204s
        └─systemd-networkd.service @2.031s +172ms
          └─dbus.service @2.005s
            └─ @1.920s
              └─ @1.920s
                └─docker.socket @1.896s +24ms
                  └─ @1.889s
                    └─systemd-timesyncd.service @1.649s +239ms
                      └─systemd-tmpfiles-setup.service @1.576s +66ms
                        └─ @1.575s
                          └─run-user-500.mount @5.403s
                            └─ @565ms
                              └─systemd-tmpfiles-setup-dev.service @383ms +179ms
                                └─kmod-static-nodes.service @148ms +42ms

Also, take note that "After=" doesn't wait for a service to finish
its startup. Maybe, your service is just triggered way to early? You
may want to add "" or similar synchronization
points of the graph above.

Make sure that after editing "WantedBy=" you may need to "systemctl
reenable" your service. If you didn't use "systemctl edit --full" you
may also need to use "systemctl daemon-reload" before re-enabling the
service. Otherwise you may see strange effects similar to what you

> Thanks for your valuable feedback.
> Regards,
> Raghavendra H R
> --
> Regards,
> Raghavendra. H. R
> (Raghu)
> On Wed, Oct 5, 2016 at 4:55 PM, Andrei Borzenkov <>
> wrote:
> > On Wed, Oct 5, 2016 at 1:19 PM, Raghavendra. H. R
> > <> wrote:  
> > > It's working fine now. We should give the default target of the
> > > system  
> > for  
> > > WantedBy= of the Install section.
> > > So I used in the Install section and it fixed my
> > > issue. 
> >
> > I doubt it was the reason. pulls in
> > unless you have very customized unit definitions.


Replies to list-only preferred.

systemd-devel mailing list

Reply via email to