[SOLVED] Systemd autostarting services

XpYunkr · 2017-11-23 16:15:52

I am having trouble understanding how autostarting with systemd works.

What I am trying to do at the moment:

[Unit]
Description= Network Manager

[Service]
ExecStart=/usr/bin/NetworkManager
Type=forking

[Install]
WantedBy=multi-user.target

This works for the Network Manager but if I try to adjust for example bluetooth:

[Unit]
Description=Bluetooth Service

[Service]
ExecStart=/usr/lib/bluetooth/bluetoothd
Type=forking

[Install]
WantedBy=bluetooth.target

This doesn't work. I take the ExecStart path to be the same as given in the /usr/lib/systemd/system/bluetooth.service and also WantedBy.

I read up on the Type in an

Infopage on systemd ,
but this raises more questions:

The article states "... it is recommended to also use the PIDFile= option, so that systemd can identify the main process of the daemon". Where do I find out the PIDFile?

In general where do I find all the essentials that are necessary to make an autostart file (if it is possible to answer
this)

Thanks for the help and greetings!

Last edited by XpYunkr (2017-11-24 12:54:33)

ewaller · 2017-11-23 16:29:39

What is bluetooth.target? Change that line back to multi-user target.
https://wiki.archlinux.org/index.php/systemd#Targets

V1del · 2017-11-23 16:40:04

You really shouldn't try to reinvent the wheel and create your own service files for services that already have a well maintained and supported service file. Both of these you are trying to use here might potentially break assumptions other services are making about these.You really shouldn't be using them in the way you are adjusting them now, you will break something sooner or later

What is essential and necessary depends on the type of service you want to start, there's no generally applicable answer to that.

PIDFiles are relevant if that is what your service uses to keep track of a forking daemon, they will be generated by said daemon, and you would know if you were using a service where that would be relevant. Both bluetoothd and NetworkManager aren't forking daemons, the main processes keeps running and they register on dbus.

An example for a forking service: https://git.archlinux.org/svntogit/pack … es/tomcat8

Here the jsvc process is only used at the beginning to start the actual server (with reduced privileges) After that has happened jsvc ends, and what remains is a running server (which is a different process from the original jsvc -- it has forked away from jsvc) and by passing in a PIDFile systemd knows that the server it should actually be monitoring is listed in the PIDFile (the pidfile contains, as the name implies, the PID of the tomcat server)

If any of these terms I just used confuse you, you should do some further reading on these (outside of a "how does systemd work" mindset), as these have existed before systemd and are essential to understanding on why and how this is set up as it is

@Eric https://www.freedesktop.org/software/sy … oth.target that's a valid special target, to be invoked on detecting an available bluethooth device.

Last edited by V1del (2017-11-23 17:03:16)

ewaller · 2017-11-23 16:58:01

Well, I'll be. Always learning

NuSkool · 2017-11-23 22:19:19

@XpYunkr

My take on what you may be missing is just enable the service. For example "systemctl enable <unit>" will auto start it. See: https://wiki.archlinux.org/index.php/sy … sing_units

As for finding whats available to enable, etc, (I'm still learning systemd stuff after years) something like:

$ systemctl list-unit-files --all
$ systemctl list-unit-files | sort
$ ls /usr/lib/systemd/system | sort

This list showed the following on my system:

NetworkManager ....
bluetooth ...

For more specific, something like:

$ systemctl list-unit-files | grep NetworkManager
$ systemctl list-unit-files | grep bluetooth

Then you can:

$ cat /usr/lib/systemd/system/bluetooth.target
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Bluetooth
Documentation=man:systemd.special(7)
StopWhenUnneeded=yes

or:

$ sudo <editor> /usr/lib/systemd/system/bluetooth.target

I also believe the naming convention for targets create some confusion. Would be nice if the init or "run level" units had a unique name like runlevel targets or something. Example:

$ systemctl list-unit-files | grep target
basic.target                                static   
bluetooth.target                            static   
cryptsetup-pre.target                       static   
cryptsetup.target                           static   
ctrl-alt-del.target                         disabled 
default.target                              indirect 
emergency.target                            static   
exit.target                                 disabled 
final.target                                static   
getty-pre.target                            static   
getty.target                                static   
graphical.target                            static   
halt.target                                 disabled 
hibernate.target                            static   
hybrid-sleep.target                         static   
initrd-fs.target                            static   
initrd-root-device.target                   static   
initrd-root-fs.target                       static   
initrd-switch-root.target                   static   
initrd.target                               static   
kexec.target                                disabled 
local-fs-pre.target                         static   
local-fs.target                             static   
machines.target                             disabled 
multi-user.target                           indirect 
network-online.target                       static   
network-pre.target                          static   
network.target                              static   
nfs-client.target                           disabled 
nss-lookup.target                           static   
nss-user-lookup.target                      static   
paths.target                                static   
poweroff.target                             disabled 
printer.target                              static   
reboot.target                               disabled 
remote-cryptsetup.target                    disabled 
remote-fs-pre.target                        static   
remote-fs.target                            enabled  
rescue.target                               static   
rpcbind.target                              static   
runlevel0.target                            disabled 
runlevel1.target                            static   
runlevel2.target                            indirect 
runlevel3.target                            indirect 
runlevel4.target                            indirect 
runlevel5.target                            static   
runlevel6.target                            disabled 
shutdown.target                             static   
sigpwr.target                               static   
sleep.target                                static   
slices.target                               static   
smartcard.target                            static   
sockets.target                              static   
sound.target                                static   
suspend.target                              static   
swap.target                                 static   
sysinit.target                              static   
system-update.target                        static   
time-sync.target                            static   
timers.target                               static   
umount.target                               static 

  
$ systemctl list-units --type=target
UNIT                LOAD   ACTIVE SUB    DESCRIPTION                                                                                                       
basic.target        loaded active active Basic System                                                                                                      
cryptsetup.target   loaded active active Local Encrypted Volumes                                                                                           
getty.target        loaded active active Login Prompts                                                                                                     
local-fs-pre.target loaded active active Local File Systems (Pre)                                                                                          
local-fs.target     loaded active active Local File Systems                                                                                                
multi-user.target   loaded active active Multi-User System                                                                                                 
network.target      loaded active active Network                                                                                                           
paths.target        loaded active active Paths                                                                                                             
remote-fs.target    loaded active active Remote File Systems                                                                                               
slices.target       loaded active active Slices                                                                                                            
sockets.target      loaded active active Sockets                                                                                                           
sound.target        loaded active active Sound Card                                                                                                        
swap.target         loaded active active Swap                                                                                                              
sysinit.target      loaded active active System Initialization                                                                                             
time-sync.target    loaded active active System Time Synchronized                                                                                          
timers.target       loaded active active Timers

See for former init runlevel appr equivelents: https://wiki.archlinux.org/index.php/sy … md_targets

As for creating custom units and auto enabling them, I've wrote bash scripts, and call it with a custom service placed in /etc/systemd/system, then enable it with systemctl. You can also call some commands directly from the unit file, in the exec line. There was a generic example in the systemd wiki.

Here's an old service file example I used, but admittedly have a lot to learn with these. The bash script just redirected the journalctl -b output (text), to a file.

[Unit]
Description=Write "journalctl -b" to /var/log/boot.jctl.log
After=getty.target

[Service]
Type=oneshot
ExecStart=/etc/systemd/system/jctl.boot.sh


[Install]
WantedBy=multi-user.target

progandy · 2017-11-23 23:03:02

$ systemctl list-unit-files | grep NetworkManager
$ systemctl list-unit-files | grep bluetooth
$ cat <path-to-unit>

It is much simpler to use the tools systemctl provides:

$ systemctl cat bluetooth.service
$ systemctl edit bluetooth.service

I also believe the naming convention for targets create some confusion. Would be nice if the init or "run level" units had a unique name like runlevel targets or something.

the "bootup" manpage has a nice description of the common boot targets. Then there are even "runlevel#.target" aliases you can use to match runlevels to the systemd names if you check them with e.g. "systemctl cat runlevel5.target".

Last edited by progandy (2017-11-23 23:10:49)

NuSkool · 2017-11-23 23:32:21

Thanks, always nice learning new stuff about systemd. Problem is rarely need to use it outside enable, etc.

Did you mean edit rather than cat? I've read about edit, but not tried it yet. Still doing things manually copy to /etc and enable them. Would definitely save some steps though!

$ systemctl cat bluetooth.service
No files found for bluetooth.service.

$ systemctl edit bluetooth.service
No files found for bluetooth.service.
Run 'systemctl edit --force bluetooth.service' to create a new unit.

Or, first time I tried using list-unit-files like this, showed:

$ systemctl list-unit-files bluetooth*
UNIT FILE        STATE 
bluetooth.target static

1 unit files listed.

$ systemctl list-unit-files NetworkManager*
UNIT FILE                          STATE   
NetworkManager-dispatcher.service  enabled 
NetworkManager-wait-online.service disabled
NetworkManager.service             enabled

3 unit files listed.

Last edited by NuSkool (2017-11-23 23:34:59)

loqs · 2017-11-23 23:36:38

$ pacman -Fo /usr/lib/systemd/system/bluetooth.service
usr/lib/systemd/system/bluetooth.service is owned by extra/bluez 5.47-2

NuSkool · 2017-11-23 23:55:48

@progandy

EDIT: OK, the I think the service has to be ~~enabled~~ installed for cat. Nice!

$ systemctl cat NetworkManager
# /usr/lib/systemd/system/NetworkManager.service
[Unit]
Description=Network Manager
Documentation=man:NetworkManager(8)
Wants=network.target
After=network-pre.target dbus.service
Before=network.target 

[Service]
Type=dbus
BusName=org.freedesktop.NetworkManager
ExecReload=/usr/bin/dbus-send --print-reply --system --type=method_call --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager o
#ExecReload=/bin/kill -HUP $MAINPID
ExecStart=/usr/bin/NetworkManager --no-daemon
Restart=on-failure
# NM doesn't want systemd to kill its children for it
KillMode=process
CapabilityBoundingSet=CAP_NET_ADMIN CAP_DAC_OVERRIDE CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID CAP_SYS_MODULE CAP_AUDIT_WRITE CAP_

# ibft settings plugin calls iscsiadm which needs CAP_SYS_ADMIN
#CapabilityBoundingSet=CAP_SYS_ADMIN

ProtectSystem=true
ProtectHome=read-only

[Install]
WantedBy=multi-user.target
Alias=dbus-org.freedesktop.NetworkManager.service
Also=NetworkManager-dispatcher.service


# /usr/lib/systemd/system/NetworkManager.service.d/NetworkManager-ovs.conf
[Unit]
After=openvswitch.service
lines 1-34/34 (END)

@logs Thanks. Yea I can usually find them, just curious how the "systemctl cat" thing worked. I think I have it figured now.

Last edited by NuSkool (2017-11-24 04:12:57)

loqs · 2017-11-24 00:02:37

No the service does not need to be enabled for systemctl cat

$ systemctl cat bluetooth.service 
# /usr/lib/systemd/system/bluetooth.service
[Unit]
Description=Bluetooth service
Documentation=man:bluetoothd(8)
ConditionPathIsDirectory=/sys/class/bluetooth

[Service]
Type=dbus
BusName=org.bluez
ExecStart=/usr/lib/bluetooth/bluetoothd
NotifyAccess=main
#WatchdogSec=10
#Restart=on-failure
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
LimitNPROC=1
ProtectHome=true
ProtectSystem=full

[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.service
$ systemctl status bluetooth.service 
● bluetooth.service - Bluetooth service
   Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:bluetoothd(8)

NuSkool · 2017-11-24 01:00:55

OK, my system does not have bluetooth.service, only bluetooth.target which is a systemd file. You guys must have bluez installed?

$ ls /usr/lib/systemd/system | grep blue
bluetooth.target

systemctl list-unit-files --all | grep blue
bluetooth.target                            static  


$ systemctl cat bluetooth.service
No files found for bluetooth.service.


 $ systemctl cat bluetooth.target
# /usr/lib/systemd/system/bluetooth.target
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Bluetooth
Documentation=man:systemd.special(7)
StopWhenUnneeded=yes

Now I'm late for dinner figuring this out. I'll check back later....

EDIT BELOW: see post #9 also

progandy wrote:

Then there are even "runlevel#.target" aliases you can use to match runlevels to the systemd names if you check them with e.g. "systemctl cat runlevel5.target".

Nice to know! So based on what you said + verification below, rather than have default run level set (link) to "multi-user.target", one could use a link, with "systemctl set-default runlevel3.target". The default.target link in /etc... would just point to runlevel3.target link, to multi-user.target. So that takes care of any naming issues with targets. Just remember runlevel#s.

$ls -l /usr/lib/systemd/system | grep  runlevel*
lrwxrwxrwx 1 root root   15 Nov 10 03:04 runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root   13 Nov 10 03:04 runlevel1.target -> rescue.target
lrwxrwxrwx 1 root root   17 Nov 10 03:04 runlevel2.target -> multi-user.target
lrwxrwxrwx 1 root root   17 Nov 10 03:04 runlevel3.target -> multi-user.target
lrwxrwxrwx 1 root root   17 Nov 10 03:04 runlevel4.target -> multi-user.target
lrwxrwxrwx 1 root root   16 Nov 10 03:04 runlevel5.target -> graphical.target
lrwxrwxrwx 1 root root   13 Nov 10 03:04 runlevel6.target -> reboot.target


$ systemctl status default.target
● multi-user.target - Multi-User System
   Loaded: loaded (/usr/lib/systemd/system/multi-user.target; indirect; vendor preset: disabled)
   Active: active since Wed 2017-11-22 09:18:02 PST; 1 day 12h ago
     Docs: man:systemd.special(7)

$ systemctl status runlevel3.target
● multi-user.target - Multi-User System
   Loaded: loaded (/usr/lib/systemd/system/multi-user.target; indirect; vendor preset: disabled)
   Active: active since Wed 2017-11-22 09:18:02 PST; 1 day 11h ago
     Docs: man:systemd.special(7)

op, Sorry if hijacking.

Last edited by NuSkool (2017-11-24 06:33:06)

XpYunkr · 2017-11-24 10:41:41

No Problem NuSkool, I'm glad it inspired some discussion. Thanks also for
the input on how to get an overview over the services. Thanks for the advice V1del
I just kind of liked tinkering around with it and playing with fire.

I will need some time to process all the input, but for now
to get autostart going I will try to enable the services and remove the
files that I created is that right?

V1del · 2017-11-24 11:22:31

Correct. In reverse order, of course, remove your files and then enable the system provided services.

@Slightly OT discussion
Since it's tangentially related I'm not going to split off here, in general most of these things you are experimenting with are already well described in our wiki, so anyone interested should read the relevant page https://wiki.archlinux.org/index.php/Systemd

XpYunkr · 2017-11-24 12:53:11

Thanks that worked. I will mark the thread as solved then.

Arch Linux

#1 2017-11-23 16:15:52

[SOLVED] Systemd autostarting services

#2 2017-11-23 16:29:39

Re: [SOLVED] Systemd autostarting services

#3 2017-11-23 16:40:04

Re: [SOLVED] Systemd autostarting services

#4 2017-11-23 16:58:01

Re: [SOLVED] Systemd autostarting services

#5 2017-11-23 22:19:19

Re: [SOLVED] Systemd autostarting services

#6 2017-11-23 23:03:02

Re: [SOLVED] Systemd autostarting services

#7 2017-11-23 23:32:21

Re: [SOLVED] Systemd autostarting services

#8 2017-11-23 23:36:38

Re: [SOLVED] Systemd autostarting services

#9 2017-11-23 23:55:48

Re: [SOLVED] Systemd autostarting services

#10 2017-11-24 00:02:37

Re: [SOLVED] Systemd autostarting services

#11 2017-11-24 01:00:55

Re: [SOLVED] Systemd autostarting services

#12 2017-11-24 10:41:41

Re: [SOLVED] Systemd autostarting services

#13 2017-11-24 11:22:31

Re: [SOLVED] Systemd autostarting services

#14 2017-11-24 12:53:11

Re: [SOLVED] Systemd autostarting services

Board footer