You are not logged in.

#1 2013-01-22 05:20:58

WindPower
Member
Registered: 2012-09-06
Posts: 12

Run custom systemd service before NetworkManager

Hi, I am trying to write a systemd service that runs and completes before NetworkManager.service starts.

I tried this:

[Unit]
Description=Custom service test
Before=NetworkManager.service

[Service]
Type=oneshot
ExecStart=/usr/bin/echo Custom service test 1
ExecStart=/usr/bin/sleep 5
ExecStart=/usr/bin/echo Custom service test 2

[Install]
WantedBy=network.target

While the custom service does start, I got this rather strange output:

Jan 22 00:12:46 localhost echo[1166]: Custom service test 1
Jan 22 00:12:48 localhost kernel: NVRM: GPU at 0000:02:00: GPU-(snip)
... some unrelated messages (acpid, kdm, etc) ...
Jan 22 00:12:49 localhost systemd-logind[1170]: Linked /tmp/.X11-unix/X0 to /run/user/1000/X11-display.
Jan 22 00:13:13 localhost echo[1254]: Custom service test 2
Jan 22 00:12:50 localhost systemd[1]: Started Custom service test.
Jan 22 00:12:50 localhost systemd[1]: Starting Network Manager...

As you can see, while everything appears in the expected order in the log, the timestamps look very wrong. The "Custom service test 2" says "00:13:13", yet it is in the middle of "00:12:49" and "00:12:50". What gives?

Also, notice that the first echo was at 00:12:46, but NetworkManager started at 00:12:50, which is only 4 seconds later. The "sleep" in the custom services should have made it start at 00:12:51 at the earliest. I don't understand why things are not being respected.

The output I'd expect to see is something like this:

Jan 22 00:12:46 localhost echo[1166]: Custom service test 1
...
Jan 22 00:12:51 localhost echo[1254]: Custom service test 2
Jan 22 00:12:51 localhost systemd[1]: Started Custom service test.
Jan 22 00:12:51 localhost systemd[1]: Starting Network Manager...

I have also made sure that it shows up in NetworkManager.service's After list:

$ systemctl show -p After NetworkManager.service
After=mycustomservice.service syslog.target systemd-journald.socket dbus.socket basic.target

Offline

#2 2013-01-22 17:30:50

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: Run custom systemd service before NetworkManager

Sooooo this begs the question: what are you really trying to do?

Offline

#3 2013-01-23 00:12:50

WindPower
Member
Registered: 2012-09-06
Posts: 12

Re: Run custom systemd service before NetworkManager

falconindy wrote:

Sooooo this begs the question: what are you really trying to do?

I'm trying to write a script that changes the interface's MAC address before NetworkManager gets a chance to take over the network interface. I'm aware that there's a page about exactly that on the wiki. I started with the systemd service from the bottom of the page, which says "Before=dhcpcd@%i.service". I changed that line to use "NetworkManager.service", and I changed the ExecStart line to "/usr/bin/macchanger -A myinterface" in order to get a random MAC address, instead of setting a fixed one like the example shows. Then I saw that macchanger's output was being mixed with NetworkManager's output in the journal, so I decided to try and write a custom service just for testing, making it start before NetworkManager, in order to see if it really was systemd's fault or if it was something macchanger-specific. Then I noticed the strange behavior described in the OP, didn't really know what to do about it, so I posted this topic. That's the story so far...

Last edited by WindPower (2013-01-23 00:13:22)

Offline

#4 2013-01-23 00:47:04

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: Run custom systemd service before NetworkManager

A udev rule would be far more suitable for this sort of thing.

Offline

#5 2013-01-24 07:04:29

Stebalien
Member
Registered: 2010-04-27
Posts: 1,237
Website

Re: Run custom systemd service before NetworkManager


Steven [ web : git ]
GPG:  327B 20CE 21EA 68CF A7748675 7C92 3221 5899 410C
Do not email: honeypot@stebalien.com

Offline

Board footer

Powered by FluxBB