Slackware 14.0, fully patched.

I can't run nm-applet as non-root. I receive the same error message as seen here.

The responses contain the standard useless comments of "solving" the problem by not using NetworkManager, etc. The OP tagged the thread as solved after moving to wicd.

As the thread was started just before 14.0 was officially released, I presume nm-applet is working for others?

I have gnome-keyring installed but even if I didn't I would expect a related failure message rather than a segmentation fault.

I'm presuming the problem is some kind of permissions or policy error as I can run nm-applet as root.

Please note the problem is nm-applet and not NetworkManager.

Any ideas?

Thanks.

Try rebuilding it from source and see if it fixes it.

chmod u+x /etc/rc.d/rc.networkmanager?

I doubt Pat would have released 14.0 with a broken nm-applet. Besides, I wrote that I can't run nm-applet as non-root and wrote than I can run nm-applet as root.

Well, um, yeah. I wrote that this is an nm-applet problem, not NM.

When running nm-applet as non-root, I see the following in /var/log/messages:

nm-applet[26268]: segfault at ffff3ff0 ip b638f6ae sp bf86afb0 error 5 in libc-2.15.so[b6349000+17e000]

Same as the OP in the other thread.

I rebuilt anyway and same result.

I'm having a similar issue, I tried to install newer version of NetworkManager (0.9.8) but I can not get run it. I will try to recompile NetworManager, else I might try a newer version of NetworkManager applet.

Yeahh! Recompiling NetworkManager solved all nm-applet issues I had, I hope you can solve your issue concerning the applet.

By the way my output of error was (maybe someone with the same problem needs find it)

@Woodsman
Are you not running Consolekit/Polkit?

I don't start either of them, and get the same segfault message. I assumed it was a permissions issue, and use a script to run nm-applet via sudo on the (rare) occasions I need to add or edit a connection. Otherwise I never start nm-applet.

(Actually, the same thinking and same solution in the case of `suspend' too, as in your other thread - I assumed I couldn't do it out-of-the-box due to lack of Consolekit/Polkit, so use sudo with NOPASSWD)

It's a valid suggestion in fact, because nm-applet does segfault if you try to start it without starting the networkmanager init script.

+1

I run fluxbox, and this *has* to go in .xinitrc (or similar in .fluxbox/startup)
There is also a similar line to start d-bus:
As you're running Trinity, I'll hazard a guess that either or both don't get started when your wm runs.

cheers,

1 members found this post helpful.

I'm using Slackware 14.0. With respect to this thread, last night I rebuilt NetworkManager using the sources from Current. Then I started rebuilding nm-applet from Current, but that version has an additional dependency of libsecret or something like that. I could have built the dependency package but then decided to hell with that.

I don't have rc.consolekit enabled. On the laptop only there is a polkit process running (/usr/libexec/polkitd --no-debug). I presume that is caused by running NetworkManager because I don't see that process on any of my other systems.

I enabled rc.consolekit and rebooted. No change in the results.

I noticed when the files in /etc/NetworkManager/system-connections are not chmod 600 that NM will not initialize at all. More Redhat stupidity?

I have been presuming a permissions or policy problem all along, as I noted in my original post that I can run nm-applet as root. As I can run nm-applet as root then sudo would work, but that is not the correct solution.

That's fine. I just presumed anybody reading this thread would understand that I am already running NetworkManager.

I'm not running fluxbox and am not sure how that applies to Trinity.

I don't see a $DBUS_SESSION_BUS_ADDRESS environment variable on the laptop.

Regardless, I modified my Trinity xinitrc with the same if/then test used in the stock Slackware xinitrc scripts, which is similar to the previous suggestion for fluxbox.

Damn. nm-applet now starts without the failure. I don't need chmod +x rc.consolekit. I do see that most (all?) of the xinitrc scripts have something like that. I also now see a $DBUS_SESSION_BUS_ADDRESS environment variable.

Where is this all explained or described?

Seems then this was a permissions/policy problem. I don't know what ck-launch-session does but the file does something related to permissions/policies. The ck-launch-session is installed from the consolekit package. My question now is when is ck-launch-session needed? I have been running without using that file for a long time. The only time I seem to need ck-launch-session is to run nm-applet.

Does ck-launch-session also affect the behavior of NetworkManager?

Questions, questions, questions!

The documentation for ConsoleKit is a bit sparse (and it is also now deprecated in favor of systemd...)
Here's a link from the Arch forums which is relevant: https://bbs.archlinux.org/viewtopic.php?pid=637913
tl;dr - Old Way=sudo
New Way=ck-launch-session

If you are not using a full DE and want those things that require privileges to "Just Work".
Otherwise you need to set them up manually (with sudo or d-bus or whatever)

With that in mind, maybe you will find suspend now works?

I haven't yet investigated fully. With the changes to my xinitrc, I discovered the Trinity version of nm-applet, tdenetworkmanager, suddenly now works as non-root.

On a single user laptop, which for laptops probably is 99%, the fact that these applets need super user permissions is asanine. The fact that NetworkManager won't run unless the system-connections scripts are chmod 600 is asanine. I "get" security, but often the concept is pushed too damn far on Linux based systems. More reminders why Linux based systems are not popular on the desktop.

I'll tag this thread as solved.