[*** ] A start job is running for dhcpcd on enp2s0f0.

fabianbl · 2016-06-04 15:14:58

When I booted my computer today and had no ethernet connection, I got this error:

[*** ] A start job is running for dhcpcd on enp2s0f0 (14 s / 1min 30s).

I was a especially confused as I never had this problem before. It just connected via the ethernet connection if it was plugged in and otherwise not. I'm not sure if I enabled the dhcpcd service myself or if it is on by default when installing Arch Linux. In any case, I disabled it, and I enabled it again with:

sudo service enable dhcpcd@enp2s0f0.service .

But I still get the same message when booting the computer. Everything works fine if the ethernet cable is plugged in. As far as I understood, the dhcpcd client should just start as soon as the state of enp2s0f0 link is UP?

So actually, what I want is to have a ethernet connection as soon as I plug in an ethernet cable, but it should not block my booting process. How can I do that?

Docbroke · 2016-06-04 15:22:41

same here, apparently caused by latest systemd update to 230-3

fabianbl · 2016-06-04 15:47:09

You're absolutely right! I just downgraded to version 229 of systemd and I had the problem no longer.

I'm quite new to Arch, someone knows how/where to report this problem?

fabianbl · 2016-06-04 15:49:31

Ah, I just saw there are already some bugs reported in the bug tracker which are related to systemd: https://bugs.archlinux.org/. But I'm not sure if this specific bug has been reported...

Last edited by fabianbl (2016-06-04 16:04:51)

loqs · 2016-06-05 00:26:24

https://git.archlinux.org/svntogit/pack … aa4257a02f
First commit for the arch packaging of systemd 230 2016-05-22 10:08:52 (GMT)
https://bugs.archlinux.org/index/proj1? … &sort=desc
Last bug report against systemd was opened on 2016-5-14 20:55 (GMT)
So the last bug report was before was packaged for arch.
So if there is a bug in 230 no one has filed a bug report about it.
OffTopic:
Took over an hour generating a url string for that bug report query that fluxbb would accept and still generated a valid url.
Edit:
Amended bugtracker url to show closed bugs as well. The change does not appear to affect findings.

Last edited by loqs (2016-06-05 00:49:32)

madpierre · 2016-06-05 00:42:24

Install wicd and wicd-gtk. Disable dhcpcd, and enable wicd?

zerophase · 2016-06-05 03:44:45

I had that too for my wireless. The name of my wireless changed from the update. Just had to disable the old name and enable the new name.

josealb77 · 2016-06-05 09:15:37

Hardly the same here (I think I don't have to open a new thread):
It occurs with systemd-230, not with 229. Occurs during the boot, but after that, I've got internet. I use ethernet and static ip, no dhcp, and I still have the issue (but as I've said, despite this I've got internet after booting):

All boots fine until it reaches:

[ OK ]   Started A basic static ethernet conncection
[***] A start job is running for sys-subsystem-net-devices-eth0.device (1min 23s / 1min 30s)

Then, after having to wait for 1min 30 s, where it should appear [ OK ] in green in the left appears a word in yellow that I'm not fast enough to read (I think that word is DEMAND, but I'm still not sure) and the boot process continues without problems.

The dmesg output is this:

[   17.765252] r8169 0000:02:00.0 enp2s0: link down
[   17.765253] r8169 0000:02:00.0 enp2s0: link down
[   17.765298] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[   19.851693] r8169 0000:02:00.0 enp2s0: link up
[   19.851708] IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes ready

I've tried to disable ipv6 in /proc/sys/net/ipv6/conf/all/disable_ipv6 and /proc/sys/net/ipv6/conf/enp2s0/disable_ipv6 without results, so the use of ipv6 does not seem to be the problem.

What drives me mad is that I get the same output with systemd-229. The first output says that enp2s0 is down and not ready, but the next message says that is up and that link becomes ready. So, which "start job" is running for sys-subsystem-net-devices-eth0.device that does not finish, makes me wait for 1min 30s, and not even finish in that time but after it all I've got internet anyway???? With systemd-230, because systemd-229 get over it, I do not have to wait and I still have internet.

Last edited by josealb77 (2016-06-05 09:27:18)

Trilby · 2016-06-05 16:07:32

This seems to be not only for the interfaces that are not used, but even those that are. I'm getting this on my wireless now. I get the "start job" message but it only waits until the wireless can be connected.

It seems the network.target is no longer being brought up in parallel with other targets, but now it is a hard dependency of user-sessions and multi-user targets:

$ 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.

multi-user.target @10.123s
└─getty.target @10.123s
  └─getty@tty1.service @10.116s
    └─systemd-user-sessions.service @10.109s +4ms
      └─network.target @10.096s
        └─dhcpcd@wls1.service @1.112s +8.983s
          └─sys-subsystem-net-devices-wls1.device @1.111s

Bluesm@n · 2016-06-05 21:28:47

I have the same problem with dhcpcd on my workstation. Everything is the same as with systemd 229. The only exception is a delay for about 10s with the same message as described in the topic.

loqs · 2016-06-05 22:15:00

At a very rough look of commits touching files in the units directory this https://github.com/systemd/systemd/comm … e247557770 seems as though it might be able to cause the issue.
Only examined by inspection not tried reverting it.
Edit:
Setting /usr/lib/systemd/system/systemd-user-sessions.service/etc/systemd/system/systemd-user-sessions.service to

#  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=Permit User Sessions
Documentation=man:systemd-user-sessions.service(8)
After=remote-fs.target nss-user-lookup.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-user-sessions start
ExecStop=/usr/lib/systemd/systemd-user-sessions stop

Seems to work ( the simpler drop in version did not work as dependency was being removed )

Edit2:

Docbroke wrote:

@loqs, the suggested file already exists (with systemd 230-3), and is no different than what you have posted

Copied the original rather than modified version thanks to Docbroke for pointing that out. Corrected to now be the modified version.
Should also have been /etc/systemd/system/systemd-user-sessions.service not /usr/lib/systemd/system/systemd-user-sessions.service

Last edited by loqs (2016-06-06 02:33:44)

Docbroke · 2016-06-06 01:37:28

@loqs, the suggested file already exists (with systemd 230-3), and is no different than what you have posted

EDIT: just checked the link you posted, and it seems that "After = network.target", needs to be removed, that solves the issue.

Last edited by Docbroke (2016-06-06 01:50:03)

josealb77 · 2016-06-06 07:10:22

PERFECT!! That worked for me!!

sjaak · 2016-06-06 08:44:15

I was almost ready to start searching the issue regarding the dhcpcd . I'll just wait untill the devs fix it

andmars · 2016-06-16 03:53:24

still present with systemd 230-4

jasonwryan · 2016-06-16 04:17:20

andmars wrote:

still present with systemd 230-4

And have you disabled the requisite service?

andmars · 2016-06-16 04:25:06

jasonwryan wrote:

andmars wrote:
still present with systemd 230-4
And have you disabled the requisite service?

Well, of course I did...I most deffinitely did...I mean, I did it just now, removing "network.target". That does indeed fix the issue :-)

WeeDram · 2016-06-18 18:21:05

I have had the same problem and read this thread with the idea of trying to fix it. However, in post #11 "/etc/systemd/system/systemd-user-sessions.service" is mentioned. Is this a text file? I don't have it there and find finds an executable file elsewhere. Where am I going wrong in my thinking and how do deal with this problem? I'm a real newbie here and a slightly extend reply would be appreciated.

Also, just as learning item, several posts mention such things as "systemd 230-3" or "systemd 230-4". How does one get such specific information?

felixculpa · 2016-06-18 21:49:57

WeeDram wrote:

I have had the same problem and read this thread with the idea of trying to fix it. However, in post #11 "/etc/systemd/system/systemd-user-sessions.service" is mentioned. Is this a text file? I don't have it there and find finds an executable file elsewhere. Where am I going wrong in my thinking and how do deal with this problem? I'm a real newbie here and a slightly extend reply would be appreciated.
Also, just as learning item, several posts mention such things as "systemd 230-3" or "systemd 230-4". How does one get such specific information?

Your terminal can give you the info:

$ pacman -Qi systemd | grep Version

jasonwryan · 2016-06-18 21:57:32

felixculpa wrote:

Your terminal can give you the info:
$ pacman -Qi systemd | grep Version

pacman -Q systemd

WeeDram · 2016-06-19 00:12:08

Thank you! Simple things like that are sometimes hard to find in a search.

hellpe · 2016-06-21 23:03:35

I'm still not getting how to fix this issue though. What service shoud I disable and how? (and can I really disable it safely?) Is `/etc/systemd/system/systemd-user-sessions.service` a file I need to create, since it doesn't exist on my setup? Or should I rather wait for the next version of systemd to bring a fix?

loqs · 2016-06-22 00:01:23

hellpe wrote:

I'm still not getting how to fix this issue though. What service shoud I disable and how?

See post #11 in this thread the issue here is a dependency upstream added for network.target

hellpe wrote:

(and can I really disable it safely?)

See the committ message from the link in post #11 that documents why the change was made. Removing the dependancy will allow that issue to occurr.

hellpe wrote:

Is `/etc/systemd/system/systemd-user-sessions.service` a file I need to create, since it doesn't exist on my setup?

See UNIT FILE LOAD PATH section of man 5 systemd.unit. /etc/systemd/system/systemd-user-sessions.service is being used to override the shipped unit file /usr/lib/systemd/system/systemd-user-sessions.service

hellpe wrote:

Or should I rather wait for the next version of systemd to bring a fix?

What is your source for upstream reverting to the old behavior?

hellpe · 2016-06-22 19:31:55

loqs wrote:

hellpe wrote:
Or should I rather wait for the next version of systemd to bring a fix?
What is your source for upstream reverting to the old behavior?

I wasn't speaking under that assumption. I was rather assuming that a future package update might somehow fix the issue without having to override systemd's default configuration, which looks like a temporary workaround to me. So, should I apply the fix you've suggested in post #11 right now, or should I expect Arch packagers to patch the issue in the foreseeable future? (not that I badly need my SSH sessions to end cleanly, but I would rather keep my system tweaks to a minimum amount, unless there is no cleaner way.)

loqs · 2016-06-22 19:53:55

hellpe wrote:

loqs wrote:
hellpe wrote:
Or should I rather wait for the next version of systemd to bring a fix?
What is your source for upstream reverting to the old behavior?
I wasn't speaking under that assumption. I was rather assuming that a future package update might somehow fix the issue without having to override systemd's default configuration, which looks like a temporary workaround to me. So, should I apply the fix you've suggested in post #11 right now, or should I expect Arch packagers to patch the issue in the foreseeable future? (not that I badly need my SSH sessions to end cleanly, but I would rather keep my system tweaks to a minimum amount, unless there is no cleaner way.)

Arch in general does not apply patches that have not been accepted upstream. Looking at https://github.com/systemd/systemd/blob … service.in no change has occurred since the comitt that introduced this issue.
Looking at https://github.com/systemd/systemd/issues it does not seem to have been reported upstream.
I can not speak for others but I did not report this upstream because:
1) It may only be an issue with certain network managers ( reports seem limited to using netctl and dhcpcd
2) This appears to be an intentional change ( perhaps unknowingly breaking netctl and dhcpdp based services ) and I can not see it being resolved without an alternative solution to having networking only shutdown after user sessions.
Given that I can not estimate if or when the old behavior would be restored.
Edit:
Appears to reported here ( filed against dhcpcd https://bugs.archlinux.org/task/49685 )

Last edited by loqs (2016-06-24 15:22:16)

Arch Linux

#1 2016-06-04 15:14:58

[*** ] A start job is running for dhcpcd on enp2s0f0.

#2 2016-06-04 15:22:41

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#3 2016-06-04 15:47:09

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#4 2016-06-04 15:49:31

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#5 2016-06-05 00:26:24

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#6 2016-06-05 00:42:24

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#7 2016-06-05 03:44:45

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#8 2016-06-05 09:15:37

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#9 2016-06-05 16:07:32

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#10 2016-06-05 21:28:47

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#11 2016-06-05 22:15:00

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#12 2016-06-06 01:37:28

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#13 2016-06-06 07:10:22

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#14 2016-06-06 08:44:15

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#15 2016-06-16 03:53:24

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#16 2016-06-16 04:17:20

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#17 2016-06-16 04:25:06

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#18 2016-06-18 18:21:05

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#19 2016-06-18 21:49:57

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#20 2016-06-18 21:57:32

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#21 2016-06-19 00:12:08

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#22 2016-06-21 23:03:35

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#23 2016-06-22 00:01:23

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#24 2016-06-22 19:31:55

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

#25 2016-06-22 19:53:55

Re: [*** ] A start job is running for dhcpcd on enp2s0f0.

Board footer