[EN] After systemctl isolate multi-user.target network is lost ...

[krisbee]

Not sure exactly which update introduced this unwanted behaviour.  It was sometime prior to Xmas and I'm wondering if it is a bug, or my misconfiguration.  I'm currently using Network Manager with a static IP.

systemctl isolate multi-user.target leads to a dns-clean.service failure and loss of network connection. The network functions OK on return to graphical mode.

Code: [Select]

Dec 28 17:44:10 sweep systemd[1]: Starting Clean up any mess left by 0dns-up...
Dec 28 17:44:10 sweep mkdir[22965]: /bin/mkdir: cannot create directory ‘/var/run/pppconfig’: File exists
Dec 28 17:44:10 sweep systemd[1]: ^[[0;1;39mdns-clean.service: Control process exited, code=exited status=1
Dec 28 17:44:10 sweep systemd[1]: Failed to start Clean up any mess left by 0dns-up.
Dec 28 17:44:10 sweep systemd[1]: ^[[0;1;39mdns-clean.service: Unit entered failed state.
Dec 28 17:44:10 sweep systemd[1]: ^[[0;1;39mdns-clean.service: Failed with result 'exit-code'.




systemd version 228-2+b1


This problem makes DU a bit tricky.

[paxmark2]

That sounds similar to a previous bug.  I could sleuth more.  EDIT
http://forum.siduction.org/index.php?topic=5901.msg48641#msg48641   
 - not the same problem, but via the same action.  end edit.

However, a different path  to getting the  X shut down to perform a dist-upgrade  try

"systemctl stop lightdm.service"   (or sddm.service if using that)

peace out.

[krisbee]

I did see that thread, but no one else has flagged this behaviour with the network connection being lost.  Stopping sddm results, not surprisingly, in the same behaviour.

I should have said that a "systemctl restart ifpugd.service" brings the interface back up after it has been lost, so is this an ifup/down bug in systemd, or just my install is screwed up.  I'm never going to remember to do a "apt-get dist-upgrade -d" only in graphical mode before switching text mode, so I'll just live with the minor incovenience for now.   

As it happens I have a bigger problem with suspend at the moment. 

[dibl]

Confirmed -- I have been observing this issue for some months now, on a wired ethernet interface, not so much on a wireless interface.  My new d-u process for all siduction systems:

Code: [Select]

(in X, as root) apt update
apt full-upgrade -d
{Alt-Ctrl F1 & log in as root}
systemctl isolate multi-user.target
{get logged out}
{log back in as root}
apt full-upgrade
{for ethernet systems only}
ifup eth0
systemctl isolate graphical.target && exit

It is certainly more complicated than the pre-systemd days, but it works reliably.

[piper]

Confirmed -- I have been observing this issue for some months now, on a wired ethernet interface, not so much on a wireless interface.  My new d-u process for all siduction systems:


Code: [Select](in X, as root) apt update
apt full-upgrade -d
{Alt-Ctrl F1 & log in as root}
systemctl isolate multi-user.target
{get logged out}
{log back in as root}
apt full-upgrade
{for ethernet systems only}
ifup eth0
systemctl isolate graphical.target && exit

It is certainly more complicated than the pre-systemd days, but it works reliably.

Unless your using

Predictable Network Interface Names

Starting with v197 systemd/udev will automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme ("eth0", "eth1", "wlan0", ...), but should fix real problems.

ifdown eth0
ifup eth0

is now

ifdown enp4s0
ifup enp4s0

[dibl]

Starting with v197 systemd/udev will automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme ("eth0", "eth1", "wlan0", ...), but should fix real problems.

ifdown eth0
ifup eth0

is now

ifdown enp4s0
ifup enp4s0

 

Thanks Piper!


But, does any of that relate to the termination of networking service when you

Code: [Select]

systemctl isolate multi-user.target

on a wired ethernet system?

[krisbee]

Confirmed -- I have been observing this issue for some months now, on a wired ethernet interface, not so much on a wireless interface.  My new d-u process for all siduction systems:

Code: [Select]

(in X, as root) apt update
apt full-upgrade -d
{Alt-Ctrl F1 & log in as root}
systemctl isolate multi-user.target
{get logged out}
{log back in as root}
apt full-upgrade
{for ethernet systems only}
ifup eth0
systemctl isolate graphical.target && exit

It is certainly more complicated than the pre-systemd days, but it works reliably.

My problem was with a wired connection. So thanks for the confirmation. It's a long way round from plain old "init 3".