*** Bug 904868 has been marked as a duplicate of this bug. ***

Can confirm autofs bug. I also use autofs on my systems and every system hangs during first start and user isn't registered right on d-bus.

Use this workaround if you do not mind users logging in before the autofs mounts are available: disable autofs.service, copy /usr/lib/systemd/system/autofs.service to /etc/systemd/system/autofs.service, remove the line "Before=systemd-logind.service" from /etc/systemd/system/autofs.service, enable autofs.service.

I am no expert, so if I understand the problem correctly, NetworkManager depends implicitly on systemd-logind.service:
Nov 16 12:08:56 linux-ykuq NetworkManager[732]: <info> Loaded plugin ifcfg-suse: (C) 2008 Novell, Inc.  To report bugs please use the NetworkMa
nager mailing list.
Nov 16 12:08:56 linux-ykuq NetworkManager[732]: <info> Loaded plugin keyfile: (c) 2007 - 2013 Red Hat, Inc.  To report bugs please use the Netw
orkManager mailing list.
Nov 16 12:08:56 linux-ykuq dbus[641]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.
service'
And this implicit dependency yields to a ordering cycle! If you model this explicitly in NetworkManager.service by adding "After=systemd-logind.service" to it, systemd will notice the cycle and disable autofs.service:
Nov 16 12:12:50 linux-ykuq.site systemd[1]: Breaking ordering cycle by deleting job autofs.service/stop
Nov 16 12:12:50 linux-ykuq.site systemd[1]: Job autofs.service/stop deleted to break ordering cycle starting with systemd-logind.service/stop

There are no implicitly dependencies ... if NetworkManager depends on systemd-logind.service than it has to requires this. But IMHO it should *NOT* depend on remote informations like NIS and/or NFS shares.  This because without network there are not NIS and/or NFS shares.  If a part of NetworkManager systemd-logind.service, then it has to be split into *two* services, one which provides the basic network used for NIS and/or NFS shares and an further service which then uses the NIS and/or NFS shares them selfs.

Beside this:

osc maintainer NetworkManager --email
Defined in project:  GNOME:Factory
  bugowner of NetworkManager : 
   os.gnome.maintainers@gmail.com

  maintainer of NetworkManager : 
   sbrabec@suse.com, dimstar@opensuse.org, sreeves@suse.com, hpj@suse.com, federico@suse.com, RBrownCCB@opensuse.org, zaitor@opensuse.org

(In reply to Werner Fink from comment #4)
> There are no implicitly dependencies ... if NetworkManager depends on
> systemd-logind.service than it has to requires this.

I am not sure whether NetworkManager really depends on it. Maybe it just uses polkit and this depends on systemd-logind. I have no clue what happens exactly. That a dependency on systemd-logind was just a wild guess. 

> But IMHO it should
> *NOT* depend on remote informations like NIS and/or NFS shares. This
> because without network there are not NIS and/or NFS shares.

I am a little bit confused. I mentioned neither NIS nor NFS shares in my bug report. Or do you mean that systemd-logind.service depends on remote information? And if so, that if NetworkManager.service depends on systemd-logind.service (my wild guess!), NetworkManager.service will depend on remote information transitively?

> If a part of
> NetworkManager systemd-logind.service, then it has to be split into *two*
> services, one which provides the basic network used for NIS and/or NFS
> shares and an further service which then uses the NIS and/or NFS shares them
> selfs.

Okay, you lost me. However, you think the dependency in autofs.service is not the problem?

> Beside this:
> 
> osc maintainer NetworkManager --email
> Defined in project:  GNOME:Factory
>   bugowner of NetworkManager : 
>    os.gnome.maintainers@gmail.com
> 
>   maintainer of NetworkManager : 
>    sbrabec@suse.com, dimstar@opensuse.org, sreeves@suse.com, hpj@suse.com,
> federico@suse.com, RBrownCCB@opensuse.org, zaitor@opensuse.org

What should I do with this information?

(In reply to Jan Ritzerfeld from comment #5)

The last part was for Bernhard ...

Beside this autofs.service is mostly used to (auto)mount NFS shares and normally it uses NIS informations, that is e.g. the automount daemon import remote auto mounter maps via NIS for the remoe HOME diretories of the users.  Normally the users login and account information are received via NIS/YP from the NIS server.

And exactly for this autofs.service has to depend on systemd-logind.service.  If NetworkManager destroys this dependency chain it has to be fixed.

Compare with man:ypbind(8) and man:auto.master(5) and with

     rpm -ql autofs | grep /usr/lib

where you find mount_nfs.so and mount_nfs4.so

(In reply to Werner Fink from comment #6)
> [...]
> And exactly for this autofs.service has to depend on systemd-logind.service.
> If NetworkManager destroys this dependency chain it has to be fixed.
> [...]

Okay, I understand. But the solution to break NetworkManager.service into two services "feels" to be wrong for me.

Actually, I have a laptop. And I only use WiFi. The credentials for accessing the WiFi are stored in KWallet, i.e., in my home. Now, autofs.service waits for the network connection and blocks systemd-logind.service. At the same time, NetworkManager.service waits until I can login via systemd-logind.service and access my home in order to get the credentials for connecting to the network. And this deadlock will happen regardless of whether NetworkManager is split into two services or not---because I still need both NetworkManager services to be started.

And in the situation above, it is just not possible to fix NetworkManager.service. The the deadlock is inevitable as long as autofs.service blocks logins until it can load its maps just because there *might* be map on a NIS server.

(In reply to Jan Ritzerfeld from comment #7)

> And in the situation above, it is just not possible to fix
> NetworkManager.service. The the deadlock is inevitable as long as
> autofs.service blocks logins until it can load its maps just because there
> *might* be map on a NIS server.

Nothing *might* ... this is the widespread use case for autofs.  E.g. my home directory as well as my login credentials are spreaded via NIS.  It makes no sense if my home directory is not mountable at login.

IMHO NetworkManager.service has to be fixed for this use case.

Q: Why there is no comment from the NetworkManager people?

(In reply to Werner Fink from comment #8)
> Nothing *might* ... this is the widespread use case for autofs.  E.g. my
> home directory as well as my login credentials are spreaded via NIS.  It
> makes no sense if my home directory is not mountable at login.

Neither the ubuntuusers.de Wiki nor the Official Ubuntu Documentation Wiki even mention this exotic use case. That is because no average (laptop) user will put their home on a NFS that is not available if they have no WiFi, e.g., when travelling! 

So the change in autofs.service breaks openSUSE for many users. Does the benefit for NIS/YP users outweigh that?

> IMHO NetworkManager.service has to be fixed for this use case.

Maybe. You could open another bug report for use case. Or I will for mine.

In my "usecase" I'm not using NIS. I use autofs on my systems only for mount internal public nfs shares as needed.

(In reply to Manuel Bernhardt from comment #11)

And my "usecase" is automounted home directory and NIS/LDAP ... as the most developers do here as well as many customers I'm know about.

I'm aware that there is a problem, but solving by breaking other setups is a nogo.  Suppose we would add this ``workaround'' as fix and would do an update of autofs package with this.  Then other users will install this ``update'' and then they will not have any automouted home anymore.

IMHO the NetworkManager should provide a basic network as well as a network enabled by user credentials.  Clearly the last service may require systemd-logind but not the first one.

Well, I am listed as NetworkManager developer, but I never did any change to it.

In my understanding, use of user-activated NetworkManager connection and NIS/LDAP based NSS service are in conflict.

Use of both user-activated NetworkMananger connection and NIS/YP/LDAP NSS service causes a real deadlock, not only a systemd dependency loop, at least in the case where network credentials are stored in the user's login keyring.


But it is possible to apply some limitations, and make this possible:

1. Limit NIS/YP/LDAP:

- the login user must be stored locally

- NIS/YP/LDAP lookup must cleanly fail and skip lookup if the network is not available.

2. Limit NetworkManager:

If NIS/YP/LDAP will be activated, then NetworkManager will not support network credentials are stored in the user's login keyring (i. e. secure WiFi).

1. seems to be acceptable, 2. generates unacceptable limitations.

There is no way to combine NetworkManager with network credentials stored in the user's login keyring and autofs with remote home. There is a hard unfixable deadlock.


I can imagine that one of these systemd services will have two instances:

- one "full" supporting all features but causing a deadlock with NetworkManager.

- second "light" supporting login only for locally stored users.

NetworkManager will conflict with the full version of the service.

I am not sure, whether there should be systemd-logind-localusers.service or nss-localuser-lookup.target or a special instance of autofs.service.


It's sad that systemd is not able to detect the deadlock in advance, and offer "light" service instead. It would require implementing of some type of solver in systemd, but it is probably an overkill.

(In reply to Werner Fink from comment #12)

> I'm aware that there is a problem, but solving by breaking other setups is a
> nogo.  

Sorry, but 13.2 did exactly that. It broke "my" setup by adding  "Before=systemd-logind.service" to /etc/systemd/system/autofs.service. That is indeed a nogo! Because 13.1 did not have this line and it worked for me. Did 13.1 work for you? If so, we can simply remove this line and everybody is happy again.
AFAIK the line will only prevent logins if autofs.service cannot start fast enough. 
How often does this really happen?

(In reply to Jan Ritzerfeld from comment #15)

Removing the line

  Before=systemd-logind.service

means that a user with remote user credentials and home is not able to do

  sudo shutdown -r now

or use the shutdown menu from the display environment.  This also breaks some setups. Indeed this happens here not only with NetworkManager but also with wicked.  I had run myself several times into this trap.

(In reply to Dr. Werner Fink from comment #16)
> (In reply to Jan Ritzerfeld from comment #15)
> 
> Removing the line
> 
>   Before=systemd-logind.service
> 
> means that a user with remote user credentials and home is not able to do
> 
>   sudo shutdown -r now
> 
> or use the shutdown menu from the display environment.  This also breaks
> some setups. Indeed this happens here not only with NetworkManager but also
> with wicked.  I had run myself several times into this trap.

And this worked with 13.1? If not, I still think this is a nogo. If so, I wonder what else has changed.

(In reply to Jan Ritzerfeld from comment #17)
> 
> And this worked with 13.1? If not, I still think this is a nogo. If so, I
> wonder what else has changed.

This is also the point that surprise me! With 13.2 something was changed which results in this bug report, but previously was for the most probably all right.
I think, the status quo from 13.1 should be restored and at the same time it should be discussed, how other use cases can also handled.

(In reply to Manuel Bernhardt from comment #18)
(In reply to Jan Ritzerfeld from comment #17)

There had been a hug numbers of reports with 13.1!  For this I
had added especially for the 13.1 and systemd-210 the file

  /usr/lib/systemd/system/fix.service

with

  [Unit]
  Description=Fix against deadlock at shutdown
  Wants=remote-fs.target remote-fs-pre.target
  Before=remote-fs.target systemd-logind.service
  After=remote-fs-pre.target network.target rpcbind.target nss-lookup.target nss-user-lookup.target
  ConditionPathExists=|/etc/init.d/autofs
  ConditionPathExists=|/etc/init.d/nfs

  [Service]
  Type=oneshot
  RemainAfterExit=true
  ExecStart=/bin/true
  ExecStop=-/etc/init.d/autofs stop
  ExecStop=-/etc/init.d/nfs stop

  [Install]
  WantedBy=remote-fs.target

This broke my system too and I had to take some time to figure it out.
It worked in 13.1 but didn't in 13.2.

Just tried to replace in autofs.service the line

     Before=systemd-logind.service

with 

     Conflicts=shutdown.target umount.target
     Before=shutdown.target umount.target

but this leads to

     [  373.252289] systemd-shutdown[1]: Cannot finalize remaining file systems and devices, giving up.

which is not what I want (this means that remote shares had locked local mounts).  A synchronization point/target only for shutdown is required which a) ensures the the remote mount shares are gone *before* network is down and b) works with both NetworkManager (if possible) and ifconfig based solutions like wicked.

http://www.engardelinux.org/modules/index/list_archives.cgi?list=fedora-users&page=1202.html&month=2014-01

https://bugs.archlinux.org/task/40200

http://lists.freedesktop.org/archives/systemd-devel/2014-February/016647.html

Caused by busy file system as automounted shares can not removed,
that isn't funny even for a virtual test system

[   40.200838] piix4_smbus 0000:00:07.0: SMBus base address uninitialized - upgrade BIOS or use force_addr=0xaddr
[   50.661646] XFS (dm-1): Metadata CRC error detected at xfs_agf_read_verify+0x5a/0x100 [xfs], block 0x867001
[   50.664443] XFS (dm-1): Unmount and run xfs_repair
[   50.666011] XFS (dm-1): First 64 bytes of corrupted metadata buffer:
[   50.668225] ffff880036b50000: 58 41 47 46 00 00 00 01 00 00 00 03 00 05 9a 00  XAGF............
[   50.670009] ffff880036b50010: 00 00 00 01 00 00 00 02 00 00 00 00 00 00 00 01  ................
[   50.671589] ffff880036b50020: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 03  ................
[   50.672960] ffff880036b50030: 00 00 00 04 00 03 c3 8d 00 03 ba 26 00 00 00 00  ...........&....
[   50.674877] XFS (dm-1): metadata I/O error: block 0x867001 ("xfs_trans_read_buf_map") error 74 numblks 1
[   50.733060] XFS (dm-1): Corruption of in-memory data detected.  Shutting down filesystem
[   50.734862] XFS (dm-1): Please umount the filesystem and rectify the problem(s)
[   50.738789] Buffer I/O error on device dm-1, logical block 199793
[   50.741306] Buffer I/O error on device dm-1, logical block 199794
[   50.742377] Buffer I/O error on device dm-1, logical block 199795
[   50.742387] Buffer I/O error on device dm-1, logical block 199796
[   50.742407] Buffer I/O error on device dm-1, logical block 199800
[   50.742417] Buffer I/O error on device dm-1, logical block 199801

(In reply to Dr. Werner Fink from comment #25)

OK, after booting the rescue mode, fiddeling with cryptsetup, lvm tools and xfs_repair the virtual system is up again. Reverting the autofs.service changes.

After rethinking I have somethin which indeed does unmount the NFS share before autofs goes down, at least the XFS file system remains clean.

The dirty target is /usr/lib/systemd/system/remote-umount.target with

    #  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=Unmount remote shares before network goes down at shutdown
    DefaultDependencies=no
    RefuseManualStart=yes
    Wants=umount.target
    Conflicts=remote-fs-pre.target remote-fs.target network.target network-online.target
    After=remote-fs-pre.target
    Before=network.target network-online.target remote-fs.target umount.target
    
    [Install]
    WantedBy=shutdown.target

and in /usr/lib/systemd/system/autofs.service (or /etc/systemd/system/autofs.service) the lines

    After=network.target remote-fs.target nss-lookup.target nss-user-lookup.target
    Before=systemd-logind.service

become

    After=network.target remote-fs.target nss-lookup.target nss-user-lookup.target
    Conflicts=remote-umount.target
    After=remote-umount.target

ugly and also the question rises if this dirty hack works with NetworkManager?

Created attachment 614569 [details]
/usr/lib/systemd/system/remote-umount.target

remote-umount.target

Created attachment 614570 [details]
/usr/lib/systemd/system/autofs.service

autofs.service

(In reply to Werner Fink from comment #27)
> [...]
> ugly and also the question rises if this dirty hack works with
> NetworkManager?

It works for me using NetworkManager. Many thanks for your help, Werner!

Most likely unrelated, a shutdown or reboot hangs for a few seconds and often there is a WiFi Firmware error displayed. To be sure, I would recommend Manuel or Isaque to test it, too.

Updated autofs.service and insert remote-umount.target but without success. First boot hangs and loginctl shows that user isn't registered

Graphic cards

Crashing system 1 -> NVIDIA Corporation GF116 [GeForce GTS 450 Rev. 2] (rev a1)
Working system 1 -> Intel Corporation 3rd Gen Core processor Graphics Controller
Working system 2 -> Advanced Micro Devices, Inc. [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250]

RAM

Crashing system 1 -> 8GB 
Working system 1 -> 4GB
Working system 2 -> 4GB

(In reply to Manuel Bernhardt from comment #32)

Why the autofs.service should cause a hang only on NVIDIA GPU based system? This smell more like a driver problem for the NVIDIA GPU.

i'm sorry. Comment 32 was for another bug I also filled out and I hit the wrong window. Please ignore!

Ok, the problem is already known now for a month and there is no acceptable final solution. Is there at least a workaround that allows you autofs can use again as it has functioned in the past?

(In reply to Jan Ritzerfeld from comment #5)
> 
> I am not sure whether NetworkManager really depends on it. Maybe it just
> uses polkit and this depends on systemd-logind.

NM obtains suspend inhibitor lock so it can complete "prepare to sleep" processing:

     Who: NetworkManager (UID 0/root, PID 998/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

This is done in src/nm-sleep-monitor-systemd.c. Currently it simply tries to unconditionally connect to logind.

I think that this /could/ be changed to listen to name owner events on D-Bus and only try to connect to logind when it is started.

(In reply to Werner Fink from comment #4)
> There are no implicitly dependencies ...

there are as I have shown above.

> if NetworkManager depends on
> systemd-logind.service than it has to requires this.

I agree. This would make this problem immediately obvious long ago.

> But IMHO it should
> *NOT* depend on remote informations like NIS and/or NFS shares.

The reason for requiring logind has nothing to do with NIS or NFS. But it does put NM in a loop with logind when NSS lookup requires networking.

Note that I do not claim it is NM bug. It can be considered logind bug as much - why logind needs networking for managing local system suspend/resume?

(In reply to Andrei Borzenkov from comment #36)

> Note that I do not claim it is NM bug. It can be considered logind bug as much 
> - why logind needs networking for managing local system suspend/resume?

Hmmm ... indeed systemd-logind.service shows

 Wants=user.slice
 After=nss-user-lookup.target user.slice

... the question rises if systemd-logind is able to handle nss lookups even if started *before* network in up or even online?

On the other hand we migth also add a special service autofs-shutdown.service to use the SIGUSR2 feature, a forced shutdown of  automount(8) *with* lazy umounting all autofs shares done by automount(8) ...

 [Unit]
 Description=Stop autofs service in case of a shutdown or reboot
 DefaultDependencies=no
 RefuseManualStart=yes
 Wants=umount.target
 Conflicts=remote-fs-pre.target remote-fs.target network.target network-online.target
 After=remote-fs-pre.target
 Before=systemd-logind.service network.target network-online.target remote-fs.target umount.target

 [Service]
 Type=oneshot
 ExecStart=/usr/bin/systemctl kill --signal=SIGUSR2 autofs.service
 
 [Install]
 WantedBy=shutdown.target

this because a ExecReload=/usr/bin/kill -USR2 $MAINPID would lead with systemctl to a desaster on a simple systemctl restart autofs.service.

Clearly in this case the Before=systemd-logind.service in autofs.service can be removed but a

 Also=autofs-shutdown.service

in the [Install] section as well as a

 SuccessExitStatus=SIGUSR2

in the [Service] section.

(In reply to Werner Fink from comment #6)
> Beside this autofs.service is mostly used to (auto)mount NFS shares and
> normally it uses NIS informations, that is e.g. the automount daemon import
> remote auto mounter maps via NIS for the remoe HOME diretories of the users.
> Normally the users login and account information are received via NIS/YP
> from the NIS server.
> 
> And exactly for this autofs.service has to depend on systemd-logind.service.

I do not see relation between first and second paragraph. Logind does not provide NIS/YP information, nor does it provide remote user account information. It is *consumer* of remote user lookup service in the same way as autofs. And logind already has After=nss-user-lookup.target. May be autofs needs the same? After=nss-lookup.target nss-user-lookup.target?

(In reply to Werner Fink from comment #16)
> (In reply to Jan Ritzerfeld from comment #15)
> 
> Removing the line
> 
>   Before=systemd-logind.service
> 
> means that a user with remote user credentials and home is not able to do
> 
>   sudo shutdown -r now
> 
> or use the shutdown menu from the display environment.  This also breaks
> some setups.

Bugzilla reference, please?

(In reply to Werner Fink from comment #21)
> A synchronization point/target only for shutdown is required which
> a) ensures the the remote mount shares are gone *before* network is down and
> b) works with both NetworkManager (if possible) and ifconfig based solutions
> like wicked.

Every remote mount implicitly has (should have ...) After=network.target (actually SPECIAL_NETWORK_TARGET). network.target must be ordered after service that provides network. So on shutdown remote mount must be stopped before network is stopped. If you say that network is teared down before network.target on shutdown, then *THIS* is the real bug that must be fixed. And yes, 13.1 has this bug - individual interfaces do not have any ordering dependency on network.target. But that should be different in 13.2 with wicked.

(In reply to Andrei Borzenkov from comment #36)
> 
> I think that this /could/ be changed to listen to name owner events on D-Bus
> and only try to connect to logind when it is started.
> 

Which is now included in NM upstream, see https://bugzilla.gnome.org/show_bug.cgi?id=741572.

Could people who have this problem test updated NM:

zypper ar obs://home:arvidjaar:bnc:905639/standard bnc905639
zypper refresh bnc905639
zypper dup -r bnc905639

This should avoid launching logind early during system boot.

Update seems to be working. But loginctl shows two sessions after reboot and login:

   SESSION        UID USER             SEAT            
        c1          0 root                             
         1       1001 manuel           seat0           

2 sessions listed.

Is it right, that user root is listed here?

(In reply to Manuel Bernhardt from comment #40)
> Update seems to be working. But loginctl shows two sessions after reboot and
> login:
> 
>    SESSION        UID USER             SEAT            
>         c1          0 root                             
>          1       1001 manuel           seat0           
> 
> 2 sessions listed.
> 
> Is it right, that user root is listed here?

No idea. What "loginctl show-session c1" and "loginctl session-status c1" show?

Updated second pc. Success too here. Currently I don't notice any side effects. Thumbs up!

The root session on the first pc is a process, created by virtualbox:

loginctl show-session c1
Id=c1
Name=root
Timestamp=Mi 2014-12-17 18:48:17 CET
TimestampMonotonic=8661177
VTNr=0
Remote=no
RemoteUser=root
Service=su-l
Scope=session-c1.scope
Leader=1064
Audit=0
Type=unspecified
Class=background
Active=yes
State=closing
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0

loginctl session-status c1
c1 - root (0)
           Since: Mi 2014-12-17 18:48:17 CET; 1h 34min ago
          Leader: 1064
          Remote: user root
         Service: su-l; type unspecified; class background
           State: closing
            Unit: session-c1.scope
                  ├─1122 /usr/lib/virtualbox/vboxwebsrv --background
                  ├─1125 /usr/lib/virtualbox/VBoxXPCOMIPCD
                  └─1131 /usr/lib/virtualbox/VBoxSVC --auto-shutdown

(In reply to Manuel Bernhardt from comment #42)
> Updated second pc. Success too here. Currently I don't notice any side
> effects. Thumbs up!
> 
> The root session on the first pc is a process, created by virtualbox:
[...]
>         Service: su-l; type unspecified; class background

su creates a login session.
There could be problems with this for the init script stop functionality.
For details, see bug 906900 comment#34.

(In reply to Thomas Blume from comment #43)

Indeed there should be a possiblity to disable pam/login control in su for the usage within SysV boot scripts.  The only question is: how to avoid that this feature can be misused in normal usage.

This is an autogenerated message for OBS integration:
This bug (905639) was mentioned in
https://build.opensuse.org/request/show/265910 Factory / NetworkManager

(In reply to Andrei Borzenkov from comment #39)
> (In reply to Andrei Borzenkov from comment #36)
> > 
> > I think that this /could/ be changed to listen to name owner events on D-Bus
> > and only try to connect to logind when it is started.
> > 
> 
> Which is now included in NM upstream, see
> https://bugzilla.gnome.org/show_bug.cgi?id=741572.
> 
> Could people who have this problem test updated NM:
> 
> zypper ar obs://home:arvidjaar:bnc:905639/standard bnc905639
> zypper refresh bnc905639
> zypper dup -r bnc905639
> 
> This should avoid launching logind early during system boot.

Look good to me. Many Thanks, Andrei!

@Andrei: Hmm, I might have found a problem. If I log out and log in again, the login takes a pretty long time. Then, there is no WiFi connection, NetworkManager is asking me for the WPA key instead. The log says something like that:
Jan 04 16:23:04 karl.site NetworkManager[942]: <info> Activation (wlp3s0/wireless): access point 'XXX' has security, but secrets are required.
Jan 04 16:23:04 karl.site NetworkManager[942]: <info> (wlp3s0): device state change: config -> need-auth (reason 'none') [50 60 0]
Jan 04 16:23:04 karl.site NetworkManager[942]: <info> Activation (wlp3s0) Stage 2 of 5 (Device Configure) complete.
Jan 04 16:23:04 karl.site NetworkManager[942]: <warn> No agents were available for this request.
Jan 04 16:23:04 karl.site NetworkManager[942]: <info> (wlp3s0): device state change: need-auth -> failed (reason 'no-secrets') [60 120 7]
Jan 04 16:23:04 karl.site NetworkManager[942]: <info> NetworkManager state is now DISCONNECTED
Jan 04 16:23:04 karl.site NetworkManager[942]: <warn> Activation (wlp3s0) failed for connection 'XXX'
Jan 04 16:23:04 karl.site NetworkManager[942]: <info> (wlp3s0): device state change: failed -> disconnected (reason 'none') [120 30 0]
Jan 04 16:23:04 karl.site NetworkManager[942]: <info> (wlp3s0): deactivating device (reason 'none') [0]
Jan 04 16:23:04 karl.site NetworkManager[942]: <warn> Could not get scan request result: Scan request rejected

If I use the original 13.2 NetworkManager, it works fine. Could anyone reproduce this problem?

(In reply to Jan Ritzerfeld from comment #47)
> @Andrei: Hmm, I might have found a problem. If I log out and log in again,
> the login takes a pretty long time. Then, there is no WiFi connection,
> NetworkManager is asking me for the WPA key instead.

I do not observe it. I can logout and login and connection is there. I have system connection which stays allive all the time.

(In reply to Andrei Borzenkov from comment #48)
> (In reply to Jan Ritzerfeld from comment #47)
> > @Andrei: Hmm, I might have found a problem. If I log out and log in again,
> > the login takes a pretty long time. Then, there is no WiFi connection,
> > NetworkManager is asking me for the WPA key instead.
> 
> I do not observe it. I can logout and login and connection is there. I have
> system connection which stays allive all the time.

Thanks for testing, Andrei. I am using a user connection that disconnects when I log out. However, log out and in works again today! Strange.

Any new? Updated today my system, got a new networkmanager version and fall back to this bug. Please overtake the fix to distribution!

Reference https://bugzilla.novell.com/show_bug.cgi?id=905639#c19

In openSUSE 13.1, with systemd-210 from Baseystem repository, fix.service creates a boot conflict with named so that bind will not start on boot.

2015-02-28T19:54:05.551911+08:00 jmorris systemd[1]: Found dependency on named.service/stop
2015-02-28T19:54:05.552938+08:00 jmorris systemd[1]: Found dependency on fix.service/stop
2015-02-28T19:54:05.553528+08:00 jmorris systemd[1]: Found dependency on nss-lookup.target/stop
2015-02-28T19:54:05.554081+08:00 jmorris systemd[1]: Breaking ordering cycle by deleting job named.service/stop
2015-02-28T19:54:05.554659+08:00 jmorris systemd[1]: Job named.service/stop deleted to break ordering cycle starting with nss-lookup.target/stop

Disabling fix.service doesn't fix it. Only renaming fix.service (or deleting) allows bind to start on boot. I don't use autofs or nfs anyway. I installed systemd-210 after the problematic patches for systemd-208 were causing daily crashes. systemd-210 works well, except for this one problem with fix.service.

I did more checking, and bind will work if nss-lookup.target is removed from the After= line of fix.service. So, if nss-lookup.target is in the After= line of fix.service, it creates a boot problem for bind because of an order problem, and named will not start on boot. It starts fine afterwards. Since named is still an LSB script, it seems much easier to tweak fix.service. HTH.

Boo#905639 depends on this bug.

Funny enough, in boo#905639 the problem is that autofs does not get restarted after a standby/resume. It turns out, that the NetworkManager-dispatcher is completely not working until a restart of NetworkManager after boot.

The reason seems to be that NetworkManager-dispatcher is not registered correctly with DBUS, which seems to be due to this bug here.

I am not an expert on DBUS, NetworkManager or AutoFS, but installing the patched package from 
http://download.opensuse.org/repositories/home:/arvidjaar:/bnc:/905639/standard/
makes this bug and boo#905639 go away for me.

I would be happy if there would be progress with this issue!

(Re)adding all maintainers of NetworkManager due to comment #53

After reading this bugzilla, it looks there were a lot of detours taken...

Quoting from 
https://bugzilla.gnome.org/show_bug.cgi?id=741572:
'NM also doesn't need to auto-launch it (logind)'
So the patch provided in above links seems to be the simple solution to this bug.

Any news on this front? The fix is working for me too, after tne problem caught me in the cold. 

Enabling NM and autofs was enough to lock me out of any wlan connections on my notebook.. Really no fun - and no, fixing the problem by logging in a second time is not exactly an obvious solution.

Sorry for the wrong reference to the other bug boo#916737 that depends on this bug:

(Correction to Joschi Brauchle from comment #53)
> Boo#916737 depends on this bug.
> 
> Funny enough, in boo#916737 the problem is that autofs does not get
> restarted after a standby/resume. It turns out, that the
> NetworkManager-dispatcher is completely not working until a restart of
> NetworkManager after boot.
> 
> The reason seems to be that NetworkManager-dispatcher is not registered
> correctly with DBUS, which seems to be due to this bug here.
> 
> I am not an expert on DBUS, NetworkManager or AutoFS, but installing the
> patched package from 
> https://build.opensuse.org/project/show/home:endzone:boo905639
> makes this bug and boo#916737 go away for me.

I have packaged the currently latest NetworkManager from openSUSE 13.2 plus this patch here: https://build.opensuse.org/project/show/home:endzone:boo905639

(In reply to Joschi Brauchle from comment #57)

Many thanks for your efforts!  Is this patch 0001-core-don-t-auto-launch-logind-bgo-741572.patch already part of NM used in Factory?

> Many thanks for your efforts!  Is this patch
> 0001-core-don-t-auto-launch-logind-bgo-741572.patch already part of NM used
> in Factory?

For Fatory, NetworkManager 1.0.2 is in the pipeline, which contains that fix.

Is there anything planned for us poor 13.2 users?

@Atri: I think you were working on an update for NM for 13.2, as part of the next GNOME Update - can you please ensure the fix for this issue is being shipped too?

Please test the packages from

 https://bugzilla.opensuse.org/show_bug.cgi?id=922370

This versionbump should contain the above patch too.

(In reply to Bjørn Lie from comment #62)
> Please test the packages from
> 
>  https://bugzilla.opensuse.org/show_bug.cgi?id=922370
> 
> This versionbump should contain the above patch too.

Correct- I verified git log and it's there http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-0-9-10&id=9458d8151ceb67287deec9f0405c86642777853e (in the corresponding branch nm-0-9-10)

(In reply to Joschi Brauchle from comment #57)

> I have packaged the currently latest NetworkManager from openSUSE 13.2 plus
> this patch here:
> https://build.opensuse.org/project/show/home:endzone:boo905639

Joschi, does your patch still work? Because when I surf to https://build.opensuse.org/package/show/home:endzone:boo905639/NetworkManager it says "Files could not be expanded: conflict in file NetworkManager.spec"

build seems broken

(In reply to matthias sweertvaegher from comment #64)
> build seems broken

Hi, yes the build is broken because official 13.2 NetworkManager packages integrated two more fixes. Still, the already existing RPMs in my projects repo are working, but do not include the two fixes that went into the official package. You can use them if you are somewhat sure that you dont need the other two patches.


An official solution to this bug has unfortunately stalled. The proposed route to upgrade to NM 0.9.10.2 has not been taken, thus leaving this bug unfixed.

It certainly would help if the patch mentioned in comment 55 would find its way into the official package for 0.9.10.0, if no upgrade to 0.9.10.2 will happen anytime soon!

@Dominique: Can we hope for this before 13.2 EOL...? :-)

@Atri

as we stopped the version updates for too many issues: can you please add the explicit patch for this issue in the the NM stack for 13.2

I am trying to urge nm upstream to release a 0.9.10.3, if there isn't much of a response within a day or two, I will submit the fix with just this patch included. 0.9.10.2 is too broken and we shouldn't go there, imo.

This is an autogenerated message for OBS integration:
This bug (905639) was mentioned in
https://build.opensuse.org/request/show/346067 13.2 / radiotray+NetworkManager

From talking to the nm-devs, 0.9.10.4 might get released eventually, but not rightaway. Until then, there is
https://build.opensuse.org/request/show/346072

openSUSE-RU-2015:2211-1: An update that has one recommended fix can now be installed.

Category: recommended (moderate)
Bug References: 905639
CVE References: 
Sources used:
openSUSE 13.2 (src):    NetworkManager-0.9.10.0-3.17.1

Update released. Removed dependency on bug 922370, the NM update to 0.9.10.2 (or .4) might happen or not, but this bug is fixed independently.