[systemd-devel] Auto-start of a Service in systemd

[Kai Krakow]

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

> Andrei,
> 
> Your doubt is absolutely correct. Default target of the system as
> nothing to do with auto start of services.
> 
> I checked both graphical.target & multi-user.target, surprisingly I
> don't see any big difference in these. Both of the files are almost
> same except multi-user.target have dependency *After=* with
> *rescue.service & rescue.target* which is restricting
> multi-user.target from starting.
> 
> However graphical.target don't depend on rescue services, so it is
> active & started. And by making graphical.target as dependency in my
> unit file solved my problem.
> 
> Hopefully if I remove the rescue services dependency from
> multi-user.target 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 multi-user.target:

$ systemctl status multi-user.target
● multi-user.target - Multi-User System
   Loaded: loaded (/usr/lib/systemd/system/multi-user.target; 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
graphical.target

As you see, multi-user.target 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.

graphical.target @5.383s
└─multi-user.target @5.383s
  └─machines.target @5.383s
    └─systemd-nspawn at gentoo\x2delasticsearch\x2dbase.service @2.219s +3.164s
      └─network.target @2.204s
        └─systemd-networkd.service @2.031s +172ms
          └─dbus.service @2.005s
            └─basic.target @1.920s
              └─sockets.target @1.920s
                └─docker.socket @1.896s +24ms
                  └─sysinit.target @1.889s
                    └─systemd-timesyncd.service @1.649s +239ms
                      └─systemd-tmpfiles-setup.service @1.576s +66ms
                        └─local-fs.target @1.575s
                          └─run-user-500.mount @5.403s
                            └─local-fs-pre.target @565ms
                              └─systemd-tmpfiles-setup-dev.service @383ms +179ms
                                └─kmod-static-nodes.service @148ms +42ms
                                  └─system.slice
                                    └─-.slice

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 "After=network.target" 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
described.

> 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 <arvidjaar at gmail.com>
> wrote:
> 
> > On Wed, Oct 5, 2016 at 1:19 PM, Raghavendra. H. R
> > <raghuhr84 at gmail.com> wrote:  
> > > It's working fine now. We should give the default target of the
> > > system  
> > for  
> > > WantedBy= of the Install section.
> > > So I used graphical.target in the Install section and it fixed my
> > > issue. 
> >
> > I doubt it was the reason. grpahical.target pulls in
> > multi-user.target unless you have very customized unit definitions.


-- 
Regards,
Kai

Replies to list-only preferred.