Dbus-org.freedesktop
Hermila Farquhar
Aside of that, maybe is a bit noisy throwing errors in such scenarios, when something not enabled by the user will not make any difference in the actual result of the authentication process. It's a misleading message that can potentially make a user think that there's something wrong. But probably this is not the place for a discussion like this hehe.
No the messages you see are because the service is off. Removing support is returning to the old pambase which did not support pam-systemd-home by default. So you have already tested the pam stack without pam-systemd-home.
Yes, that stopped the incessant spamming of the logs with the message "Failed to query user record: Unit dbus-org.freedesktop.home1.service not found."
It is still triggered whenever there's a authentication problem, like when you type the password wrong when using sudo or in the Mate lock-screen.
That's is not a problem though, as it's not happening that often. However, as I am never going to enable systemd-homed.service the message is completely unneeded, but there you go....
Still seeing this as well, on several "standard" installations not using systemd-homed (and not intending to).
I've seen several proposed solutions/workarounds here and in FS#65819, which one is recommended now?
Given the large amounts of unnecessary noise this service creates, and the limited benefit for typical systems, it would perhaps be interesting to not enable pam_systemd_home.so by default (in pambase package).
I second not enabling pam_systemd_home.so by default in any of the pambase packages. I cannot envision every needing or wanting the enabled, and I suspect that is true for a large majority of Arch installs. Just because upstream dreams something up to fit some corner-case doesn't mean that Arch needs to enable the functionality. We just split postfix into multiple packages containing non-default backends, so why not split this functionality out into a separate package and those few that will ever want it can install that package and enable the service. Far better choice than cluttering the logs on a majority of the systems that will never use it.
After having tried the differing solutions, I concur that having pam_unix checked first as shown in the edit to post #8 above about as simple as it gets. Simply modify the two pairs of lines shown (e.g. just move the pam_unix check before the pam_systemd_home check for 'account' and `password' sections of the file -- done. No more heinous homed message needlessly filling the journal.
Hello everyone,
I am trying to use wireguard on Solus.
As I understood, there is no need to install the module since the Solus is currently on Linux56.
I manually installed wireguard-tools from the sources but when I run wg-quick up plop I get a Failed to set DNS configuration: Unit dbus-org.freedesktop.resolve1.service not found.
How can I fix this?
pretty vague. Nonetheless there is this in solus:
snap find wireguard
Name Version Publisher Notes Summary
wireguard-ammp 0.0.20181218 ammp - WireGuard VPN (userspace)
if you do snap I'd rip out all the stuff you tried to install, first.
but
if you did install the snap package, and getting these errors, then I don't know.
bertaga If you have a DNS entry in your client conf file, remove it. I had the same problem as you and that seemed to be the consensus solution. After that wg-quick seemed to set up everything (including firewall changes).
Of course I haven't actually got wireguard to work with my OpenBSD VPS quite yet, so take my advice with a grain of salt...
appmath Doesn't this open up security issues, such as DNS leaks? I have the same problem and do not want to use systemd-resolved; does Solus use their default 8.8.8.8 for DNS queries? That is my concern with enabling systemd-resolved.
trulyclaw74 8.8.8.8 is a fallback not the default. It will only get used if your NIC can't negotiate for a nameserver over DHCP or if the negotiated nameserver can't be contacted. This should never happen if the network you are connected to is configured correctly and operating normally.
I enabled systemd-resolved with:
systemctl start systemd-resolved.service
and wireguard started, but the DNS did not work. I was able to ping 8.8.8.8 but could not reach google, amazon or any other website by name.
I guess that "fallback" = "default" to me; that means it's hard coded into systemd-resolved at compile and goes there when systemd-resolved figures that it needs to do so; I may run a wireshark to see if it ever contacts 8.8.8.8 with and without just for comfort level
The recent switch to dbus-broker introduced some new warnings. After digging further I found that none of them are cause for immediate concern but they do indicate that Arch and Manjaro use dbus activation in a way that depends on legacy support. In particular
After Fedora 30 switched to dbus-broker they removed dbus activation of DE-specific org.freedesktop.* session services in Fedora 31. Arch will need do the same IMHO (or continue shipping a distro that outputs warnings indicating use of a dbus legacy support feature).
Because systemd-homed service is disabled/masked. Can be silenced by commenting out 4 lines referring to pam_systemd_home.so in /etc/pam.d/system-auth. See [solved] pam fails to find unit dbus-org.freedesktop.home1.service / Newbie Corner / Arch Linux Forums
Functionally dbus-broker and dbus-daemon do exactly the same thing, the only difference is that dbus-broker outputs warnings when it finds multiple providers or incorrectly named service files. Which is good and hopefully will result in this all being cleaned up in the future as it was in Fedora.
Right. Using different service file names for conflicting D-Bus services only prevents the file conflict when installing both packages, but not the runtime conflict when the service is actually to be activated. D-Bus never got that right, and after almost 15 years (!) of nobody caring, I do not expect that to change any time soon, neither in the legacy dbus-daemon nor in dbus-broker. D-Bus activation is not a suitable solution for desktop-environment-specific implementations of a standardized D-Bus API.
May 16 20:39:43 nethserver dbus[721]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' May 16 20:39:43 nethserver dbus-daemon: dbus[721]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' May 16 20:39:43 nethserver systemd: Starting Time & Date Service... May 16 20:39:43 nethserver dbus[721]: [system] Successfully activated service 'org.freedesktop.timedate1' May 16 20:39:43 nethserver dbus-daemon: dbus[721]: [system] Successfully activated service 'org.freedesktop.timedate1' May 16 20:39:43 nethserver systemd: Started Time & Date Service.
You can trigger the message with signal-event nethserver-ntp-save or signal-event nethserver-ntp-update. So reboots/updates/config changes/service restarts may be responsible for the entries too. Did you change NTP settings?
My system shows similar behaviour. Updates on the 15th of May and then the dbus messages start every 5mins. HOWEVER, there was a period on 13th May when the dbus messages appeared every 5mins, but it has become a regular occurrence since 15th of May.
NMS is a python daemon which monitor the status of all services registered inside the configuration db. Each service is checked every 300 seconds, if the status of a service changes, NMS writes a notification to Collectd socket.
I can confirm what you found out. Great work!
The only solution I see for now is to suppress these messages in the logfile. I found similar issue with sogo here and in the docs and changed it to fit to our needs: