20.05.2016 17:06, Per Jessen пишет:

Per Jessen wrote:

...

This morning I patched/upgraded a 13.2 box and rebooted. Normally I have no problems starting openvpn, but this time the 'tun' module wasn't autoloaded. Nor when I manually tried starting openvpn later.

Can anyone suggest a reason why 'tun' was not automatically loaded?? I have never had this issue before.

It wasn't just a fluke on the first boot-up, have just rebooted twice, had to load 'tun' manually. Surely it should be autoloaded when openvpn tries to access /dev/net/tun?

It is autoloaded if I do "true < /dev/net/tun". Are you sure openvpn actually tries to access this device? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

27.05.2016 19:59, Per Jessen пишет:

Andrei Borzenkov wrote:

...

20.05.2016 17:06, Per Jessen пишет:

...

Per Jessen wrote:

...

This morning I patched/upgraded a 13.2 box and rebooted. Normally I have no problems starting openvpn, but this time the 'tun' module wasn't autoloaded. Nor when I manually tried starting openvpn later.

Can anyone suggest a reason why 'tun' was not automatically loaded?? I have never had this issue before.

It wasn't just a fluke on the first boot-up, have just rebooted twice, had to load 'tun' manually. Surely it should be autoloaded when openvpn tries to access /dev/net/tun?

It is autoloaded if I do "true < /dev/net/tun". Are you sure openvpn actually tries to access this device?

That's what it says, $SUBJ is from the log.

Normally this file should have been created by kmod-static-nodes.service. Does it exist? What "systemctl status kmod-static-nodes.service" says? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

boeing:~ # systemctl status kmod-static-nodes.service kmod-static-nodes.service - Create list of required static device nodes for the current kernel Loaded: loaded (/usr/lib/systemd/system/kmod-static-nodes.service; static) Active: active (exited) since Fri 2016-05-20 14:31:17 CEST; 1 weeks 0 days ago Main PID: 76 (code=exited, status=0/SUCCESS) CGroup: /system.slice/kmod-static-nodes.service

Looks good, I would say.

That service unit runs this: /usr/bin/kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf Looking at /run/tmpfiles.d/kmod.conf on the system where it doesnt work: boeing:~ # cat /run/tmpfiles.d/kmod.conf d /dev/mapper 0755 - - - c /dev/mapper/control 0600 - - - 10:236

From an older backlevel system:

sogo:/var/log # cat /run/tmpfiles.d/kmod.conf c /dev/fuse 0600 - - - 10:229 c /dev/cuse 0600 - - - 10:203 c /dev/btrfs-control 0600 - - - 10:234 c /dev/loop-control 0600 - - - 10:237 d /dev/net 0755 - - - c /dev/net/tun 0600 - - - 10:200 c /dev/ppp 0600 - - - 108:0 c /dev/uinput 0600 - - - 10:223 d /dev/mapper 0755 - - - c /dev/mapper/control 0600 - - - 10:236 c /dev/uhid 0600 - - - 10:239 d /dev/vfio 0755 - - - c /dev/vfio/vfio 0600 - - - 10:196 c /dev/vhci 0600 - - - 10:137 c /dev/vhost-net 0600 - - - 10:238 d /dev/snd 0755 - - - c /dev/snd/timer 0600 - - - 116:33 d /dev/snd 0755 - - - c /dev/snd/seq 0600 - - - 116:1 -- Per Jessen, Zürich (18.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov wrote:

27.05.2016 22:09, Per Jessen пишет:

...

Per Jessen wrote:

...

boeing:~ # systemctl status kmod-static-nodes.service kmod-static-nodes.service - Create list of required static device nodes for the current kernel Loaded: loaded (/usr/lib/systemd/system/kmod-static-nodes.service; static) Active: active (exited) since Fri 2016-05-20 14:31:17 CEST; 1 weeks 0 days ago Main PID: 76 (code=exited, status=0/SUCCESS) CGroup: /system.slice/kmod-static-nodes.service

Looks good, I would say.

That service unit runs this:

/usr/bin/kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf

Looking at /run/tmpfiles.d/kmod.conf on the system where it doesnt work:

boeing:~ # cat /run/tmpfiles.d/kmod.conf d /dev/mapper 0755 - - - c /dev/mapper/control 0600 - - - 10:236

...

From an older backlevel system:

sogo:/var/log # cat /run/tmpfiles.d/kmod.conf c /dev/fuse 0600 - - - 10:229 c /dev/cuse 0600 - - - 10:203 c /dev/btrfs-control 0600 - - - 10:234 c /dev/loop-control 0600 - - - 10:237 d /dev/net 0755 - - - c /dev/net/tun 0600 - - - 10:200 c /dev/ppp 0600 - - - 108:0 c /dev/uinput 0600 - - - 10:223 d /dev/mapper 0755 - - - c /dev/mapper/control 0600 - - - 10:236 c /dev/uhid 0600 - - - 10:239 d /dev/vfio 0755 - - - c /dev/vfio/vfio 0600 - - - 10:196 c /dev/vhci 0600 - - - 10:137 c /dev/vhost-net 0600 - - - 10:238 d /dev/snd 0755 - - - c /dev/snd/timer 0600 - - - 116:33 d /dev/snd 0755 - - - c /dev/snd/seq 0600 - - - 116:1

Something went rather wrong; I have fully up to date 13.2 VM and this file has full content (including /dev/net/tun).

I'll have to patch/upgrade again, but what could have gone wrong here? Where does kmod-static-nodes.service get its information from? The two systems above are hardware-wise virtually identical they only differ by CPU and memory. -- Per Jessen, Zürich (19.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov wrote:

27.05.2016 22:59, Per Jessen пишет:

...

Andrei Borzenkov wrote:

...

27.05.2016 22:09, Per Jessen пишет:

...

Per Jessen wrote:

...

boeing:~ # systemctl status kmod-static-nodes.service kmod-static-nodes.service - Create list of required static device nodes for the current kernel Loaded: loaded (/usr/lib/systemd/system/kmod-static-nodes.service; static) Active: active (exited) since Fri 2016-05-20 14:31:17 CEST; 1 weeks 0 days ago Main PID: 76 (code=exited, status=0/SUCCESS) CGroup: /system.slice/kmod-static-nodes.service

Looks good, I would say.

That service unit runs this:

/usr/bin/kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf

Looking at /run/tmpfiles.d/kmod.conf on the system where it doesnt work:

boeing:~ # cat /run/tmpfiles.d/kmod.conf d /dev/mapper 0755 - - - c /dev/mapper/control 0600 - - - 10:236

...

From an older backlevel system:

sogo:/var/log # cat /run/tmpfiles.d/kmod.conf c /dev/fuse 0600 - - - 10:229 c /dev/cuse 0600 - - - 10:203 c /dev/btrfs-control 0600 - - - 10:234 c /dev/loop-control 0600 - - - 10:237 d /dev/net 0755 - - - c /dev/net/tun 0600 - - - 10:200 c /dev/ppp 0600 - - - 108:0 c /dev/uinput 0600 - - - 10:223 d /dev/mapper 0755 - - - c /dev/mapper/control 0600 - - - 10:236 c /dev/uhid 0600 - - - 10:239 d /dev/vfio 0755 - - - c /dev/vfio/vfio 0600 - - - 10:196 c /dev/vhci 0600 - - - 10:137 c /dev/vhost-net 0600 - - - 10:238 d /dev/snd 0755 - - - c /dev/snd/timer 0600 - - - 116:33 d /dev/snd 0755 - - - c /dev/snd/seq 0600 - - - 116:1

Something went rather wrong; I have fully up to date 13.2 VM and this file has full content (including /dev/net/tun).

I'll have to patch/upgrade again, but what could have gone wrong here? Where does kmod-static-nodes.service get its information from?

The two systems above are hardware-wise virtually identical they only differ by CPU and memory.

This is probably fallout of http://bugzilla.suse.com/show_bug.cgi?id=980324. This service creates file (sorry, I was confused as well) based on content of /lib/modules/$(uname -r); first time it runs in initrd when only small number of modules is present. Due to above bug service is not run second time after root is mounted.

Ah, I see. Yes, that makes sense. (I think).

On system where it works you should see Starting/Stopping/Starting for this service is journalctl. On system where it does not work - only Starting once.

I'll have to reboot "boeing" (where it doesn't work) and "sogo" (where it works). Have just rebooted "sogo" where it works: sogo:~ # journalctl -b -o short-precise --no-pager | grep Create\ list May 28 19:56:09.646432 sogo systemd[1]: Starting Create list of required static device nodes for the current kernel... May 28 19:56:09.647020 sogo systemd[1]: Started Create list of required static device nodes for the current kernel. May 28 19:56:10.860910 sogo systemd[1]: Stopping Create list of required static device nodes for the current kernel... May 28 19:56:10.861339 sogo systemd[1]: Stopped Create list of required static device nodes for the current kernel. "boeing" is rebooting now.

What is surprising that so far you are the only one who experiences this bug (at least who complains about it).

Yeah, I don't get that either - I don't think my systems are in any way special. a) "temp78" - xen guest (the one from bug#980324). Just for testing. (was patched according to that bugreport). b) "boeing" - COTS hardware, runs mysql, openvpn, rbldnsd, named. c) "sogo" - same hardware, runs squid, samba, apache, opensuse mirror. b and c have not been fixed wrt bug#980324. -- Per Jessen, Zürich (22.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Per Jessen wrote:

...

Andrei Borzenkov wrote:

...

This is probably fallout of http://bugzilla.suse.com/show_bug.cgi?id=980324. This service creates file (sorry, I was confused as well) based on content of /lib/modules/$(uname -r); first time it runs in initrd when only small number of modules is present. Due to above bug service is not run second time after root is mounted.

Ah, I see. Yes, that makes sense. (I think).

Well, this weekend I tried the same fix - add After=initrd.target to initrd-switch-root.target rebuild initrd, reboot which didn't fix the problem. Did I miss something? -- Per Jessen, Zürich (17.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

06.06.2016 11:21, Per Jessen пишет:

Per Jessen wrote:

...

Per Jessen wrote:

...

Andrei Borzenkov wrote:

...

This is probably fallout of http://bugzilla.suse.com/show_bug.cgi?id=980324. This service creates file (sorry, I was confused as well) based on content of /lib/modules/$(uname -r); first time it runs in initrd when only small number of modules is present. Due to above bug service is not run second time after root is mounted.

Ah, I see. Yes, that makes sense. (I think).

Well, this weekend I tried the same fix -

add After=initrd.target to initrd-switch-root.target rebuild initrd, reboot

which didn't fix the problem. Did I miss something?

I missed something. I commented on bug report. To summarize - this is fundamental problem of how systemd orders unit start/stop that cannot really be solved without systemd change; but as upstream refuses to admit the problem exists, it does not look like it can be fixed. When missing service is added back, it will again hide this issue by adding - hopefully, sufficient - delay. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Отправлено с iPhone

6 июня 2016 г., в 20:57, Per Jessen написал(а):

Andrei Borzenkov wrote:

...

06.06.2016 11:21, Per Jessen пишет:

...

Per Jessen wrote:

...

Per Jessen wrote:

...

Andrei Borzenkov wrote:

...

This is probably fallout of http://bugzilla.suse.com/show_bug.cgi?id=980324. This service creates file (sorry, I was confused as well) based on content of /lib/modules/$(uname -r); first time it runs in initrd when only small number of modules is present. Due to above bug service is not run second time after root is mounted.

Ah, I see. Yes, that makes sense. (I think).

Well, this weekend I tried the same fix -

add After=initrd.target to initrd-switch-root.target rebuild initrd, reboot

which didn't fix the problem. Did I miss something?

I missed something. I commented on bug report.

Thanks for your effort, Andrei.

...

To summarize - this is fundamental problem of how systemd orders unit start/stop that cannot really be solved without systemd change; but as upstream refuses to admit the problem exists, it does not look like it can be fixed.

upstream can actually ignore fact or has Poettering just not understood the issue?

Poettering doesn't not understand this specific issue. May be my explanation was unclear. I tried second time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org