You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

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.

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)

Quote:

nm_client_get_devices: error getting devices: The name org.freedesktop.NetworkManager was not provided by any .service files

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)

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

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.

Quote:

Are you running not running Consolekit/Polkit?

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?

Quote:

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.

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.

Quote:

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

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

Quote:

I run fluxbox, and this *has* to go in .xinitrc (or similar in .fluxbox/startup)

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

Quote:

There is also a similar line to start d-bus:

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.

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

Quote:

Originally Posted by Woodsman

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?

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)

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.