Bug 652761
| Summary: | NetworkManager[1145]: <error> [1289582167.783197] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Minnikhanov <minnikhanov> |
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 14 | CC: | dcbw, jklimes, minnikhanov, willdeed |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-04-20 22:39:55 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Minnikhanov
2010-11-12 17:43:26 UTC
(In reply to comment #0) > Description of problem: > There are error messages in message.log after boot. > Nov 12 20:16:07 lhost NetworkManager[1145]: <error> [1289582167.783197] > [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) > Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no > such name > Nov 12 20:16:07 lhost NetworkManager[1145]: <error> [1289582167.783858] > [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) > Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no > such name > Nov 12 20:16:07 lhost NetworkManager[1145]: <error> [1289582167.784253] > [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) > Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no > such name It should not appear as there is a test that the name has an owner before initializing proxy to user settings. However, I can reproduce the messages. They appear on logging on and out from gdm. (tested on Fedora 14 Live) Hmm, it needs more debugging. > <<< > > here I start internet connection by PPPoE. > > >>> > > Why it does want to open at /root/... ??? > >>> > Nov 12 20:16:52 lhost pppd[2384]: Warning: can't open options file > /root/.ppprc: Permission denied > <<< pppd reads its configuration file .ppprc in home directory (man pppd). pppd is run by NM as root, so it searches the file in /root. > <<< > > here also error. Why Invalid? > <<< > Nov 12 20:16:53 lhost nm-dispatcher.action: nm_dispatcher_action: Invalid > connection: '(null)' / 'connection setting not found' invalid: 1 > <<< The error is fixed upstream - bug 627649. (In reply to comment #1) > > >>> > > Nov 12 20:16:52 lhost pppd[2384]: Warning: can't open options file > > /root/.ppprc: Permission denied > > <<< > > pppd reads its configuration file .ppprc in home directory (man pppd). > pppd is run by NM as root, so it searches the file in /root. > > I check: [root@lhost ~]# find / -mount -name .ppprc -print [root@lhost ~]# This file not found anywhere. This file /root/.ppprc not found also on my box. uname -r -> 2.6.35.6-48.fc14.x86_64 (In reply to comment #1) > here I start internet connection by PPPoE. > > > > >>> > > > > Why it does want to open at /root/... ??? > > >>> > > Nov 12 20:16:52 lhost pppd[2384]: Warning: can't open options file > > /root/.ppprc: Permission denied > > <<< > > pppd reads its configuration file .ppprc in home directory (man pppd). > pppd is run by NM as root, so it searches the file in /root. > man pppd: >>> OPTIONS FILES Options can be taken from files as well as the command line. Pppd reads options from the files /etc/ppp/options, ~/.ppprc and /etc/ppp/options.ttyname (in that order) before processing the options on the command line. <<< ls -al /etc/ppp >>> @lhost ~]$ ls -al /etc/ppp total 84 drwxr-xr-x. 3 root root 4096 Nov 18 22:13 . drwxr-xr-x. 127 root root 12288 Nov 19 20:18 .. -rw-------. 1 root root 232 Oct 23 09:53 chap-secrets -rw-------. 1 root root 349 Nov 16 12:25 eaptls-client -rw-------. 1 root root 405 Nov 16 12:25 eaptls-server -rw-r--r--. 1 root root 2276 Sep 9 2009 firewall-masq -rw-r--r--. 1 root root 978 Sep 9 2009 firewall-standalone -rwxr-xr-x. 1 root root 386 Sep 27 23:45 ip-down -rwxr-xr-x. 1 root root 3262 Sep 27 23:45 ip-down.ipv6to4 -rwxr-xr-x. 1 root root 430 Sep 27 23:45 ip-up -rwxr-xr-x. 1 root root 6481 Sep 27 23:45 ip-up.ipv6to4 -rwxr-xr-x. 1 root root 1687 Sep 27 23:45 ipv6-down -rwxr-xr-x. 1 root root 3200 Sep 27 23:45 ipv6-up -rw-r--r--. 1 root root 5 Nov 16 12:25 options ------ >>> ------- >>> -------- >>> ******** -rw-r--r--. 1 root root 1759 Jun 16 19:06 options.pptp ------ >>> ------- >>> -------- >>> ******** -rw-------. 1 root root 231 Oct 23 09:53 pap-secrets drwxr-xr-x. 2 root root 4096 Sep 27 23:58 peers -rw-r--r--. 1 root root 104 Sep 9 2009 pppoe-server-options [@lhost ~]$ cat /etc/ppp/options lock [@lhost ~]$ <<< There is the file '/etc/ppp/options'. May be this will be enough by 'man pppd'. Or pppd looks for '/etc/ppp/options.ppp'? Is it right the attempt access to ' ~/.ppprc' (in my case '/root/.ppprc'), when there is the file '/etc/ppp/options'? The referenced bug should be long-since fixed in F13 & F14 updates. |