You are not logged in.
Pages: 1
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)
Offline
What is bluetooth.target? Change that line back to multi-user target.
https://wiki.archlinux.org/index.php/systemd#Targets
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
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)
Offline
Well, I'll be. Always learning
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
@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
Offline
$ 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)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
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)
Offline
$ pacman -Fo /usr/lib/systemd/system/bluetooth.service
usr/lib/systemd/system/bluetooth.service is owned by extra/bluez 5.47-2
Offline
@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)
Offline
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)
Offline
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
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)
Offline
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?
Offline
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
Offline
Thanks that worked. I will mark the thread as solved then.
Offline
Pages: 1