<div dir="ltr">It appears that I can fix this by editing the unit file and changing:<div><br></div><div>ProtectSystem=strict</div><div><br></div><div>to:</div><div><br></div><div>ProtectSystem=full</div><div><br></div><div>I'm not sure why that is but a resolution is good enough for me. Following up on my own thread in case this helps someone else in the future.</div><div><br></div><div>Best,</div><div><br></div><div>Sean</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 14, 2023 at 12:02 PM Sean Caron <<a href="mailto:scaron@umich.edu">scaron@umich.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Sorry, perhaps apparmor is not completely disabled, but I don't think it's enforcing. I tried shutting it off completely with:<div><br></div><div>systemctl stop apparmor<br></div><div><br></div><div>And that doesn't seem to have made a difference.</div><div><br></div><div>Best,</div><div><br></div><div>Sean</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 14, 2023 at 11:57 AM Sean Caron <<a href="mailto:scaron@umich.edu" target="_blank">scaron@umich.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Mantas,<div><br></div><div>Thanks for the suggestions! I took a look and I'm seeing entries like the following in the logs:</div><div><br></div><div>Starting Hostname Service...<br>systemd-hostnamed.service: Failed to set up mount namespacing: /run/systemd/unit-root/: Invalid argument<br>systemd-hostnamed.service: Failed at step NAMESPACE spawning /lib/systemd/systemd-hostnamed: Invalid argument<br>systemd-hostnamed.service: Main process exited, code=exited, status=226/NAMESPACE<br>systemd-hostnamed.service: Failed with result 'exit-code'.<br>Failed to start Hostname Service.<br></div><div><br></div><div>Starting Time & Date Service...<br>systemd-timedated.service: Failed to set up mount namespacing: /run/systemd/unit-root/: Invalid argument<br>systemd-timedated.service: Failed at step NAMESPACE spawning /lib/systemd/systemd-timedated: Invalid argument<br>systemd-timedated.service: Main process exited, code=exited, status=226/NAMESPACE<br>systemd-timedated.service: Failed with result 'exit-code'.<br>Failed to start Time & Date Service.<br></div><div><br></div><div>Apparmor is disabled on all of our systems. </div><div><br></div><div>The /run/systemd/unit-root directory exists on both working and nonworking systems and the ownership and permissions are identical on working and nonworking systems.</div><div><br></div><div>I'm unfortunately not very conversant with everything that systemd does behind the scenes with this namespacing stuff. Does this raise any obvious flags? Any ideas for how I could further debug and/or resolve this would be so greatly appreciated!</div><div><br></div><div>Best,</div><div><br></div><div>Sean</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 13, 2023 at 1:22 PM Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Activation is not client-side, it's handled automatically by dbus-daemon – which either spawns the service directly or starts it as a systemd service.<div dir="auto"><br></div><div dir="auto">In this case, check whether your logs show systemd-hostnamed.service attempting to start; either it fails to start (missing libraries? Apparmor?) or dbus-daemon fails to contact systemd (pid1 crashed?).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 13, 2023, 19:45 Sean Caron <<a href="mailto:scaron@umich.edu" target="_blank">scaron@umich.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi everyone,<div><br></div><div>I'm on Ubuntu 20.04 LTS, kernel version 5.4.0-163-generic, systemd 245 (245.4-4ubuntu3.22).</div><div><br></div><div>I have some systems where I am receiving the following error messages when people attempt to use timedatectl or hostnamectl:</div><div><br></div><div><br></div><div>Failed to query server: Failed to activate service 'org.freedesktop.timedate1': timed out (service_start_timeout=25000ms)<br></div><div><br></div><div>Failed to query system properties: Failed to activate service 'org.freedesktop.hostname1': timed out (service_start_timeout=25000ms)<br></div><div><br></div><div><br></div><div>I tried setting SYSTEMD_LOG_LEVEL=debug and rerunning the commands and it didn't really give me anything useful for determining the root cause of the issue. Here's an example of that output for timedatectl status:</div><div><br></div><div><br></div><div>Bus n/a: changing state UNSET → OPENING<br>Bus n/a: changing state OPENING → AUTHENTICATING<br>Bus n/a: changing state AUTHENTICATING → HELLO<br>Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a<br>Got message type=method_return sender=org.freedesktop.DBus destination=:1.15318 path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=s error-name=n/a error-message=n/a<br>Bus n/a: changing state HELLO → RUNNING<br>Sent message type=method_call sender=n/a destination=org.freedesktop.timedate1 path=/org/freedesktop/timedate1 interface=org.freedesktop.DBus.Properties member=GetAll cookie=2 reply_cookie=0 signature=s error-name=n/a error-message=n/a<br>Got message type=error sender=org.freedesktop.DBus destination=:1.15318 path=n/a interface=n/a member=n/a cookie=3 reply_cookie=2 signature=s error-name=org.freedesktop.DBus.Error.TimedOut error-message=Failed to activate service 'org.freedesktop.timedate1': timed out (service_start_timeout=25000ms)<br>Failed to query server: Failed to activate service 'org.freedesktop.timedate1': timed out (service_start_timeout=25000ms)<br>Bus n/a: changing state RUNNING → CLOSED<br></div><div><br></div><div><br></div><div>I read that sometimes these issues can be caused by filesystem permissions on subdirectories in /var such as /var/tmp or /var/lib/systemd but I checked these and compared against a working system and I don't see any obvious differences.</div><div><br></div><div>I have tried using strace on timedatectl and hostnamectl to try and see what's hanging things up but that hasn't really provided any fruitful direction, either.</div><div><br></div><div>I didn't really know this was occurring until an end user reported it to me so I don't necessarily know how long the issue has been occurring or have a change in mind that could have broken things. I'm not sure if the upgrade from Ubuntu 18 to Ubuntu 20 broke it, or if some security configuration broke it. Or perhaps there is a missing dependency package on the broken systems?</div><div><br></div><div>Could anyone out there please provide a little bit more guidance on how I might troubleshoot this and determine the root cause of the issue? I really hate to bother folks here but I'm feeling stuck.</div><div><br></div><div>Thank you!</div><div><br></div><div>Sean </div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>