NM: error when initiating a new connection

[marmarek]

Reported by joanna on 14 Jul 2012 12:54 UTC
How to reproduce:

1. DISCONNECT your current connection (
2. Try to connect again to the same wifi network

You will get a popup from netvm:

Failed to add/activate connection
(32) No session found for uid 1000 (unknown)

Probably some problem with dbus, again...

Migrated-From: https://wiki.qubes-os.org/ticket/626

[marmarek]

Comment by marmarek on 14 Jul 2012 21:20 UTC
pam_systemd was actually required...

[marmarek]

Comment by marmarek on 14 Jul 2012 21:20 UTC
pam_systemd was actually required...

[marmarek]

Comment by marmarek on 14 Jul 2012 21:51 UTC
Patch mentioned in #607 actually was backported to FC17 systemd package, but later was reverted because it caused regression (https://bugzilla.redhat.com/show_bug.cgi?id=823485). This bug is harmless for us, as we doesn't use gdm (or any other display manager) in the VM.

First of all we actually need pam_systemd, so previous workaroud isn't acceptable.
The other ways:

1. Just revert workaround and live with "...killed" messages (perhaps adding 2>/dev/null somewhere, ex in qvm-sync-clock).
2. Fork systemd package and apply the patch (actually remove patch which revert the fix).

[marmarek]

Comment by marmarek on 14 Jul 2012 21:51 UTC
Patch mentioned in #607 actually was backported to FC17 systemd package, but later was reverted because it caused regression (https://bugzilla.redhat.com/show_bug.cgi?id=823485). This bug is harmless for us, as we doesn't use gdm (or any other display manager) in the VM.

First of all we actually need pam_systemd, so previous workaroud isn't acceptable.
The other ways:

1. Just revert workaround and live with "...killed" messages (perhaps adding 2>/dev/null somewhere, ex in qvm-sync-clock).
2. Fork systemd package and apply the patch (actually remove patch which revert the fix).

[marmarek]

Comment by joanna on 15 Jul 2012 08:55 UTC
Perhaps we can always pass only stdout, and always ignore stderr for the qvm-run -p?

[marmarek]

Comment by joanna on 15 Jul 2012 08:55 UTC
Perhaps we can always pass only stdout, and always ignore stderr for the qvm-run -p?

[marmarek]

Comment by marmarek on 15 Jul 2012 11:17 UTC
I think this is bad idea, as some programs use stderr for useful diagnostics (ie tar cv). This will also make difficult solving errors like typo in cmdline ("unknown argument", "file not found" etc).

[marmarek]

Comment by marmarek on 15 Jul 2012 11:17 UTC
I think this is bad idea, as some programs use stderr for useful diagnostics (ie tar cv). This will also make difficult solving errors like typo in cmdline ("unknown argument", "file not found" etc).

[marmarek]

Comment by joanna on 15 Jul 2012 11:19 UTC
Then we can perhaps add another switch to ignore stderr? --no-stderr?

[marmarek]

Comment by joanna on 15 Jul 2012 11:19 UTC
Then we can perhaps add another switch to ignore stderr? --no-stderr?

[marmarek]

Comment by marmarek on 15 Jul 2012 11:38 UTC
This is named "2> /dev/null"...

[marmarek]

Comment by marmarek on 15 Jul 2012 11:38 UTC
This is named "2> /dev/null"...

[marmarek]

Comment by marmarek on 16 Jul 2012 11:38 UTC
http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=0f6f445ece0ea05d41a1a20f2c5854ea61440013
When package with workaround was installed on system, pam_systemd must be reenabled manually:

cd /lib64/security; mv pam_systemd.so.disabled pam_systemd.so

[marmarek]

Comment by marmarek on 16 Jul 2012 11:38 UTC
http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=0f6f445ece0ea05d41a1a20f2c5854ea61440013
When package with workaround was installed on system, pam_systemd must be reenabled manually:

cd /lib64/security; mv pam_systemd.so.disabled pam_systemd.so