[opensuse-factory] 13.1 Base:System:Legacy systemd, emergency mode and slow rebooting
https://bugzilla.opensuse.org/show_bug.cgi?id=832220 systemd-fsck loops forever when errors can't be fixed automatically, makes system unbootable https://bugzilla.opensuse.org/show_bug.cgi?id=924488 fstab entry prevents booting no emergency shell NAICT, these two bugs have a solution in the same source, systemd-210 from Base:System:Legacy, and may amount to the same bug. In 13.1 AFAICT, emergency mode has never worked. With current systemd-208: 1: Attempting to boot with 1 on kernel cmdline produces a prompt that refuses to accept a password. 2: Attempting to boot when fstab has a spelling error in a volume label for an entry that is not noauto results in an emergency shell incapable of accepting a login These two problems are solved on several 13.1 systems here by installing systemd-210 and its deps, BUT: once 210 is installed, the reboot command, if noauto NFS(4) fstab entries have been manually started, results in intolerable delay between reboot command start and restart success. The fastest reboot I've experienced since making this determination is about 7 minutes (typical on i586 host hs80e). The longest, infinite (repeatable on i586 host gx27c; occasional on host hs80e). The reboot delay is from stop jobs for NFS. Running 'umount -a' prior to reboot avoids the delay. Adding nfsvers=3 to fstab options may or may not avoid the delay. Avoiding seems possibly to depend on not having actually accessed files from the nfs mount points. On same machines, delay does not happen with TW or 13.2, while their emergency modes work as expected. What to do? 13.1 is due to go Evergreen before too long, 13.2 is a bad idea here unless a fix for https://bugzilla.opensuse.org/show_bug.cgi?id=919836 comes along soon, and for several reasons, Leap won't be an option here either. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
26.09.2015 11:39, Felix Miata пишет:
once 210 is installed, the reboot command, if noauto NFS(4) fstab entries have been manually started, results in intolerable delay between reboot command start and restart success.
Could you make available output of "systemctl dump" after manually mounting NFS filesystem; tell which one was mounted. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov composed on 2015-09-26 21:04 (UTC+0300):
Felix Miata composed:
once 210 is installed, the reboot command, if noauto NFS(4) fstab entries have been manually started, results in intolerable delay between reboot command start and restart success.
Could you make available output of "systemctl dump" after manually mounting NFS filesystem; tell which one was mounted.
# systemctl dump Unknown operation 'dump'. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
26.09.2015 21:55, Felix Miata пишет:
Andrei Borzenkov composed on 2015-09-26 21:04 (UTC+0300):
Felix Miata composed:
once 210 is installed, the reboot command, if noauto NFS(4) fstab entries have been manually started, results in intolerable delay between reboot command start and restart success.
Could you make available output of "systemctl dump" after manually mounting NFS filesystem; tell which one was mounted.
# systemctl dump Unknown operation 'dump'.
Ah, right, it had been moved into systemd-analyze. You may need to install it additionally, I do not remember (it is part of systemd package in TW). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
26.09.2015 11:39, Felix Miata пишет:
once 210 is installed, the reboot command, if noauto NFS(4) fstab entries have been manually started, results in intolerable delay between reboot command start and restart success.
Your systemd configuration dump shows two issues a) network-online.target is not started. The end effect is lack of serialization between NFS unmount and stopping of interfaces on shutdown. When NFS mount is started automatically from fstab, network-online.target is pulled in, but not when NFS is mounted manually. I believe there were some patches related to this but I cannot find anything looking now. The simplest fix is to manually enable network-online.target: ln -s /usr/lib/systemd/system/network-online.target /etc/systemd/system/default.target.wants. This problem is more or less openSUSE 13.1 specific, because in subsequent releases (and other distros I am aware of) interfaces are started before network.target which is normally always active. May be I had to use network.target instead too in my patch. b) network@.service lacks dependency on network-online.target. This should have been fixed in bnc#857031. Did you miss some updates? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov composed on 2015-09-27 09:40 (UTC+0300):
Felix Miata composed:
once 210 is installed, the reboot command, if noauto NFS(4) fstab entries have been manually started, results in intolerable delay between reboot command start and restart success.
Your systemd configuration dump shows two issues
a) network-online.target is not started. The end effect is lack of serialization between NFS unmount and stopping of interfaces on shutdown. When NFS mount is started automatically from fstab, network-online.target is pulled in, but not when NFS is mounted manually. I believe there were some patches related to this but I cannot find anything looking now. The simplest fix is to manually enable network-online.target:
ln -s /usr/lib/systemd/system/network-online.target /etc/systemd/system/default.target.wants.
Booted host hs80e with systemd-210 already installed to try this. Ran that command only, then rebooted, then mounted nfs mounts, then tried reboot command. It still takes more than 6 minutes to reboot.
This problem is more or less openSUSE 13.1 specific, because in subsequent releases (and other distros I am aware of) interfaces are started before network.target which is normally always active. May be I had to use network.target instead too in my patch.
b) network@.service lacks dependency on network-online.target. This should have been fixed in bnc#857031. Did you miss some updates?
If it only happened on one installation I might imagine that possible, but this is a problem on all the at least half dozen installations I've installed systemd-210 on as followup to https://bugzilla.opensuse.org/show_bug.cgi?id=924488 and https://bugzilla.opensuse.org/show_bug.cgi?id=832220 . All such installations have had zypper up run on them many times since https://bugzilla.opensuse.org/show_bug.cgi?id=857031 was marked fixed 19 months ago. I guess for the time being until a fix is found for this I can use .bashrc's Reboot[1] instead of system's reboot on the test systems that use the alias to execute manual nfs mounts, if I can remember needing it. Doesn't http://download.opensuse.org/repositories/home:/tsaupe:/branches:/openSUSE:/... include a good enough fix to include in updates? [1] alias Reboot='cd; umount -a; reboot' -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
27.09.2015 10:29, Felix Miata пишет:
Andrei Borzenkov composed on 2015-09-27 09:40 (UTC+0300):
Felix Miata composed:
once 210 is installed, the reboot command, if noauto NFS(4) fstab entries have been manually started, results in intolerable delay between reboot command start and restart success.
Your systemd configuration dump shows two issues
a) network-online.target is not started. The end effect is lack of serialization between NFS unmount and stopping of interfaces on shutdown. When NFS mount is started automatically from fstab, network-online.target is pulled in, but not when NFS is mounted manually. I believe there were some patches related to this but I cannot find anything looking now. The simplest fix is to manually enable network-online.target:
ln -s /usr/lib/systemd/system/network-online.target /etc/systemd/system/default.target.wants.
Booted host hs80e with systemd-210 already installed to try this. Ran that command only, then rebooted, then mounted nfs mounts, then tried reboot command. It still takes more than 6 minutes to reboot.
This problem is more or less openSUSE 13.1 specific, because in subsequent releases (and other distros I am aware of) interfaces are started before network.target which is normally always active. May be I had to use network.target instead too in my patch.
b) network@.service lacks dependency on network-online.target. This should have been fixed in bnc#857031. Did you miss some updates?
If it only happened on one installation I might imagine that possible, but this is a problem on all the at least half dozen installations I've installed systemd-210 on as followup to https://bugzilla.opensuse.org/show_bug.cgi?id=924488 and https://bugzilla.opensuse.org/show_bug.cgi?id=832220 . All such installations have had zypper up run on them many times since https://bugzilla.opensuse.org/show_bug.cgi?id=857031 was marked fixed 19 months ago.
Could you paste /usr/lib/systemd/system/network@.service?
I guess for the time being until a fix is found for this I can use .bashrc's Reboot[1] instead of system's reboot on the test systems that use the alias to execute manual nfs mounts, if I can remember needing it.
Doesn't http://download.opensuse.org/repositories/home:/tsaupe:/branches:/openSUSE:/... include a good enough fix to include in updates?
The problem is not in systemd, but in services used to configure interfaces which are from openSUSE. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov composed on 2015-09-27 12:27 (UTC+0300):
Felix Miata composed
If it only happened on one installation I might imagine that possible, but this is a problem on all the at least half dozen installations I've installed systemd-210 on as followup to https://bugzilla.opensuse.org/show_bug.cgi?id=924488 and https://bugzilla.opensuse.org/show_bug.cgi?id=832220 . All such installations have had zypper up run on them many times since https://bugzilla.opensuse.org/show_bug.cgi?id=857031 was marked fixed 19 months ago.
Could you paste /usr/lib/systemd/system/network@.service?
# ll network@.service -rw-r--r-- 1 root root 280 Oct 29 2013 network@.service # rpm -qf ./network@.service sysconfig-network-0.81.6-1.1.i586 [Unit] Description=ifup managed network interface %i Requisite=network.service PartOf=network.service BindsTo=sys-subsystem-net-devices-%i.device IgnoreOnIsolate=yes [Service] Type=forking RemainAfterExit=yes ExecStart=/sbin/ifup %i ExecStop=/sbin/ifdown %i SuccessExitStatus=12
Doesn't http://download.opensuse.org/repositories/home:/tsaupe:/branches:/openSUSE:/... include a good enough fix to include in updates?
The problem is not in systemd, but in services used to configure interfaces which are from openSUSE. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
27.09.2015 12:47, Felix Miata пишет:
Andrei Borzenkov composed on 2015-09-27 12:27 (UTC+0300):
Felix Miata composed
If it only happened on one installation I might imagine that possible, but this is a problem on all the at least half dozen installations I've installed systemd-210 on as followup to https://bugzilla.opensuse.org/show_bug.cgi?id=924488 and https://bugzilla.opensuse.org/show_bug.cgi?id=832220 . All such installations have had zypper up run on them many times since https://bugzilla.opensuse.org/show_bug.cgi?id=857031 was marked fixed 19 months ago.
Could you paste /usr/lib/systemd/system/network@.service?
# ll network@.service -rw-r--r-- 1 root root 280 Oct 29 2013 network@.service # rpm -qf ./network@.service sysconfig-network-0.81.6-1.1.i586
Where did you get it from? The latest patch for 13.1 is 0.81.5-30.1.
[Unit] Description=ifup managed network interface %i Requisite=network.service PartOf=network.service BindsTo=sys-subsystem-net-devices-%i.device IgnoreOnIsolate=yes
[Service] Type=forking RemainAfterExit=yes ExecStart=/sbin/ifup %i ExecStop=/sbin/ifdown %i SuccessExitStatus=12
Doesn't http://download.opensuse.org/repositories/home:/tsaupe:/branches:/openSUSE:/... include a good enough fix to include in updates?
The problem is not in systemd, but in services used to configure interfaces which are from openSUSE.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov composed on 2015-09-27 12:58 (UTC+0300):
# ll network@.service -rw-r--r-- 1 root root 280 Oct 29 2013 network@.service # rpm -qf ./network@.service sysconfig-network-0.81.6-1.1.i586
Where did you get it from? The latest patch for 13.1 is 0.81.5-30.1.
Are you suggesting to replace 81.6 with 81.5? I don't know how to tell where it came from. Zypper simply says (System Packages). Looking at the dates involved, it could be that I didn't switch the repos until later than when 13.1 was branched from Factory, after a zypper dup or more before switching. Maybe BaseSystem was enabled somewhere along the way, then dropped. I'll have to look at other installations as time permits to see which of these is installed, if it matters. from changelog: * Tue Oct 29 2013 mt@suse.com - version 0.81.6 - Merged changes from $OBS/Base:System/sysconfig * Wed Oct 16 2013 oneukum@suse.com - blacklist udlfb because only udl can be used with xrandr 1.4 (bnc#846218) * Mon Oct 14 2013 vcizek@suse.com - set SELinux label for /dev/.sysconfig after creation (bnc#845792) * sysconfig-0.81.5-restore_selinux_context_on_RUN_FILES_BASE.patch - use systemctl when possible instead of calling init scripts directly * sysconfig-0.81.5-netconfig-use_systemctl.patch * Wed Oct 02 2013 mt@suse.de - /etc/modprobe.d/50-blacklist.conf: cleaned up obsolete/dropped kernel drivers (bnc#843141,bnc#843169). Thanks to Michal Marek! sk98lin: dropped from the kernel in 2.6.26 stradis: dropped in 2.6.38 (39c3d48) eepro100: dropped in 2.6.29 (6b1abba) slamr,slusb: no smartlink-softmodem-kmp since 10.3 ich2rom: rplaced by ichxrom in 2.6.12 (304aa41) eth1394: dropped in 2.6.37 (66fa12c) uhci: dropped in 2.5.27 tsdev: removed in 2.6.24 (7009317) snd_bt87x: duplicate of snd-bt87x clgenfb: replaced by cirrusfb in 2.5.67 cyblafb: replaced by tridentfb in 2.6.30 unikey: not in mainline history, 2.4? encode-{big5,gb,gbk,jis,kscm}: not in mainline history, 2.4? fbcon-{afb,ilbm,iplan2p2,iplan2p4,iplan2p8}: removed in 2.5.51 fbcon-{cfb2,cfb4,hga,mfb,vga-planes},fbgen: removed in 2.5.51 fbcon-{mac,vga}: removed in 2.5.28 vmware: never upstream, no reference in 2.5+ from /var/log/zypp/history: 2013-10-30 02:50:26|install|alsa|1.0.27.2-5.1|i586||OSS|1c7952f20103c3a727c633a362e798817a2499cc446eedca8bfedf49e9bfb09f| 2013-10-30 02:50:27|install|libproxy1-pacrunner-webkit|0.4.11-10.2|i586||OSS|57b0fe14d42f9754e227f5623bf2d9380885807d947885a2513cc3de6f79ae75| 2013-10-30 02:50:27|install|yast2-ruby-bindings|3.1.1-1.1|i586||OSS|8540434eab5739821a69bb4d3e7205a1f48afbaf9c5a4fe3cf6e762256561ff6| # 2013-10-30 02:50:30 sysconfig-network-0.81.6-1.1.i586.rpm installed ok # Additional rpm output: # Updating /etc/sysconfig/network/dhcp... # Updating /etc/sysconfig/network/config... # Removing old autogenerated device configuration files: # 2013-10-30 02:50:30|install|sysconfig-network|0.81.6-1.1|i586||OSS|178461cf645308801a92e184ea3f264d164a951a986abe51a5fe9d4f14a581fb| 2013-10-30 02:50:31|install|tightvnc|1.3.10-16.1|i586||OSS|430d0ae591d88d0f389019dbaf479dec302cd8f63b02e64b822452d5a9690d1e| 0.81.5-1.1 had been installed on 2013-10-13.
[Unit] Description=ifup managed network interface %i Requisite=network.service PartOf=network.service BindsTo=sys-subsystem-net-devices-%i.device IgnoreOnIsolate=yes
[Service] Type=forking RemainAfterExit=yes ExecStart=/sbin/ifup %i ExecStop=/sbin/ifdown %i SuccessExitStatus=12 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
27.09.2015 13:34, Felix Miata пишет:
Andrei Borzenkov composed on 2015-09-27 12:58 (UTC+0300):
# ll network@.service -rw-r--r-- 1 root root 280 Oct 29 2013 network@.service # rpm -qf ./network@.service sysconfig-network-0.81.6-1.1.i586
Where did you get it from? The latest patch for 13.1 is 0.81.5-30.1.
All that I say is that fix for mentioned bug was included in 0.81.5-30.1. I do not know if it is part of your version but it is not listed in changelog. You can also test if fix helps by adding missing line manually before doing anything.
Are you suggesting to replace 81.6 with 81.5?
I don't know how to tell where it came from.
rpm -q --qf '%{vendor} %{distribution}\n' sysconfig-network Zypper simply says (System
Packages). Looking at the dates involved, it could be that I didn't switch the repos until later than when 13.1 was branched from Factory, after a zypper dup or more before switching. Maybe BaseSystem was enabled somewhere along the way, then dropped. I'll have to look at other installations as time permits to see which of these is installed, if it matters.
from changelog: * Tue Oct 29 2013 mt@suse.com - version 0.81.6 - Merged changes from $OBS/Base:System/sysconfig
* Wed Oct 16 2013 oneukum@suse.com - blacklist udlfb because only udl can be used with xrandr 1.4 (bnc#846218)
* Mon Oct 14 2013 vcizek@suse.com - set SELinux label for /dev/.sysconfig after creation (bnc#845792) * sysconfig-0.81.5-restore_selinux_context_on_RUN_FILES_BASE.patch - use systemctl when possible instead of calling init scripts directly * sysconfig-0.81.5-netconfig-use_systemctl.patch
* Wed Oct 02 2013 mt@suse.de - /etc/modprobe.d/50-blacklist.conf: cleaned up obsolete/dropped kernel drivers (bnc#843141,bnc#843169). Thanks to Michal Marek! sk98lin: dropped from the kernel in 2.6.26 stradis: dropped in 2.6.38 (39c3d48) eepro100: dropped in 2.6.29 (6b1abba) slamr,slusb: no smartlink-softmodem-kmp since 10.3 ich2rom: rplaced by ichxrom in 2.6.12 (304aa41) eth1394: dropped in 2.6.37 (66fa12c) uhci: dropped in 2.5.27 tsdev: removed in 2.6.24 (7009317) snd_bt87x: duplicate of snd-bt87x clgenfb: replaced by cirrusfb in 2.5.67 cyblafb: replaced by tridentfb in 2.6.30 unikey: not in mainline history, 2.4? encode-{big5,gb,gbk,jis,kscm}: not in mainline history, 2.4? fbcon-{afb,ilbm,iplan2p2,iplan2p4,iplan2p8}: removed in 2.5.51 fbcon-{cfb2,cfb4,hga,mfb,vga-planes},fbgen: removed in 2.5.51 fbcon-{mac,vga}: removed in 2.5.28 vmware: never upstream, no reference in 2.5+
from /var/log/zypp/history: 2013-10-30 02:50:26|install|alsa|1.0.27.2-5.1|i586||OSS|1c7952f20103c3a727c633a362e798817a2499cc446eedca8bfedf49e9bfb09f| 2013-10-30 02:50:27|install|libproxy1-pacrunner-webkit|0.4.11-10.2|i586||OSS|57b0fe14d42f9754e227f5623bf2d9380885807d947885a2513cc3de6f79ae75| 2013-10-30 02:50:27|install|yast2-ruby-bindings|3.1.1-1.1|i586||OSS|8540434eab5739821a69bb4d3e7205a1f48afbaf9c5a4fe3cf6e762256561ff6| # 2013-10-30 02:50:30 sysconfig-network-0.81.6-1.1.i586.rpm installed ok # Additional rpm output: # Updating /etc/sysconfig/network/dhcp... # Updating /etc/sysconfig/network/config... # Removing old autogenerated device configuration files: # 2013-10-30 02:50:30|install|sysconfig-network|0.81.6-1.1|i586||OSS|178461cf645308801a92e184ea3f264d164a951a986abe51a5fe9d4f14a581fb| 2013-10-30 02:50:31|install|tightvnc|1.3.10-16.1|i586||OSS|430d0ae591d88d0f389019dbaf479dec302cd8f63b02e64b822452d5a9690d1e|
0.81.5-1.1 had been installed on 2013-10-13.
[Unit] Description=ifup managed network interface %i Requisite=network.service PartOf=network.service BindsTo=sys-subsystem-net-devices-%i.device IgnoreOnIsolate=yes
Try to add Before=network.target or Before=network-online.target
[Service] Type=forking RemainAfterExit=yes ExecStart=/sbin/ifup %i ExecStop=/sbin/ifdown %i SuccessExitStatus=12
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov composed on 2015-09-27 17:54 (UTC+0300):
Felix Miata composed:
Andrei Borzenkov composed on 2015-09-27 12:58 (UTC+0300):
# ll network@.service -rw-r--r-- 1 root root 280 Oct 29 2013 network@.service # rpm -qf ./network@.service sysconfig-network-0.81.6-1.1.i586
Where did you get it from? The latest patch for 13.1 is 0.81.5-30.1.
All that I say is that fix for mentioned bug was included in 0.81.5-30.1. I do not know if it is part of your version but it is not listed in changelog. You can also test if fix helps by adding missing line manually before doing anything.
Are you suggesting to replace 81.6 with 81.5?
I don't know how to tell where it came from.
rpm -q --qf '%{vendor} %{distribution}\n' sysconfig-network
openSUSE openSUSE Factory
Zypper simply says (System
Packages). Looking at the dates involved, it could be that I didn't switch the repos until later than when 13.1 was branched from Factory, after a zypper dup or more before switching. Maybe BaseSystem was enabled somewhere along the way, then dropped. I'll have to look at other installations as time permits to see which of these is installed, if it matters.
from changelog: * Tue Oct 29 2013 mt@suse.com - version 0.81.6 - Merged changes from $OBS/Base:System/sysconfig
* Wed Oct 16 2013 oneukum@suse.com - blacklist udlfb because only udl can be used with xrandr 1.4 (bnc#846218) ... # 2013-10-30 02:50:30 sysconfig-network-0.81.6-1.1.i586.rpm installed ok ... 0.81.5-1.1 had been installed on 2013-10-13.
[Unit] Description=ifup managed network interface %i Requisite=network.service PartOf=network.service BindsTo=sys-subsystem-net-devices-%i.device IgnoreOnIsolate=yes
Try to add
Before=network.target
or
Before=network-online.target
Tried each once. Success with both. Then I backleveled to sysconfig-network-0.81.5-30.1, which required/pulled matching versions of sysconfig, udevmountd and sysconfig-netconfig. Then I rebooted, started the nfs mounts, accessed then and executed reboot, without experiencing any delay as what triggered this thread. However, I rebooted again, and this second time produced a 6+ minute delay. I tried again, and again the 6+ minute delay. I restored to the Before=network.target version, and was able to reboot more than three times without delays. The 0.81.5-30.1 file timestamp is 10 Apr 2014. It's content matches the old as modified by the inclusion of Before=network-online.target. Does zypper and/or yast have an equivalent to yum/dnf's distro-sync?
[Service] Type=forking RemainAfterExit=yes ExecStart=/sbin/ifup %i ExecStop=/sbin/ifdown %i SuccessExitStatus=12 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (2)
-
Andrei Borzenkov
-
Felix Miata