{"id":2798,"date":"2024-09-11T15:30:49","date_gmt":"2024-09-11T15:30:49","guid":{"rendered":"https:\/\/blog.samarthya.me\/wps\/?p=2798"},"modified":"2024-09-11T15:30:51","modified_gmt":"2024-09-11T15:30:51","slug":"failed-to-connect-to-bus-no-medium-found","status":"publish","type":"post","link":"https:\/\/blog.samarthya.me\/wps\/2024\/09\/11\/failed-to-connect-to-bus-no-medium-found\/","title":{"rendered":"Failed to connect to bus: No medium found"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

If you have ever seen this error, you know the pain of a fellow linux user.<\/p>\n\n\n\n

Failed to connect to bus: No medium found<\/code><\/pre>\n\n\n\n
This is message I get when I was trying to install podman.socket<\/code><\/p>\n\n\n\n
systemctl enable --now podman.socket --user -M saurabh@<\/code><\/pre>\n\n\n\n
Why do we need Podman.socket?<\/strong><\/p>\n\n\n\n
    \n
  • Communication with other applications:<\/strong> podman.socket<\/code> enables other applications, such as container orchestration tools or custom scripts, to interact with Podman without requiring direct access to the Podman binary. This provides a more secure and flexible way to manage containers.<\/li>\n\n\n\n
  • Integration with other tools:<\/strong> podman.socket<\/code> can be used by tools like Docker Compose or Kubernetes to communicate with Podman and manage containers.<\/li>\n\n\n\n
  • Custom scripts and automation:<\/strong> Podman.socket can be used to create custom scripts or automation workflows that interact with Podman’s functionality.<\/li>\n<\/ul>\n\n\n\n
    In all googling I did I was able to see the problem boiling from XDG_RUNTIME_DIR<\/code> which was empty on my host OS.<\/p>\n\n\n\n
    > echo $XDG_RUNTIME_DIR\n\n<\/code><\/pre>\n\n\n\n
    XDG_RUNTIME_DIR<\/code> is an environment variable in Linux systems that specifies a directory for storing user-specific non-essential runtime files and other file objects. Its primary purposes include:<\/p>\n\n\n\n
      \n
    1. Providing a secure location for temporary runtime files.<\/li>\n\n\n\n
    2. Ensuring user-specific runtime data is cleaned up when the user logs out.<\/li>\n\n\n\n
    3. Offering a standardized location for applications to store runtime data.<\/li>\n<\/ol>\n\n\n\n
      The XDG_RUNTIME_DIR variable is part of the XDG Base Directory Specification, which was introduced by the freedesktop.org<\/code> project (formerly X Desktop Group, hence XDG) in the early 2000s. This specification aimed to standardize file locations across different Linux distributions and desktop environments.<\/p>\n\n\n\n
      Key points in its history and development:<\/p>\n\n\n\n
        \n
      1. Early 2000s: The XDG Base Directory Specification was first proposed to address the lack of standardization in file locations across Linux systems.<\/li>\n\n\n\n
      2. 2010: XDG_RUNTIME_DIR was added to the specification in version 0.7. This addition was motivated by the need for a secure, user-specific location for runtime files that would be automatically cleaned up.<\/li>\n\n\n\n
      3. 2012: systemd<\/code>, a system and service manager for Linux, began to create and manage XDG_RUNTIME_DIR, further standardizing its use across systems using systemd<\/code>.<\/li>\n\n\n\n
      4. Over time: Various applications and services began relying on XDG_RUNTIME_DIR<\/code> for storing temporary data, sockets, and other runtime objects.<\/li>\n<\/ol>\n\n\n\n
        The introduction of XDG_RUNTIME_DIR<\/code> solved several problems:<\/p>\n\n\n\n
          \n
        1. Security<\/code>: It provides a per-user directory with strict permissions, enhancing security for runtime data.<\/li>\n\n\n\n
        2. Cleanup<\/code>: Unlike \/tmp, which can accumulate files, XDG_RUNTIME_DIR is typically cleared when the user logs out.<\/li>\n\n\n\n
        3. Standardization<\/code>: It offers a consistent location for applications to store runtime data across different Linux distributions.<\/li>\n<\/ol>\n\n\n\n
          Today, XDG_RUNTIME_DIR is widely used in modern Linux systems, particularly those using systemd<\/code>. It plays a crucial role in managing user-specific runtime data and is an important part of the Linux filesystem hierarchy.<\/p>\n\n\n\n
          This is how I solved it.<\/p>\n\n\n\n
          $ mkdir -p ~\/.bashrc.d\n\n$ cat << EOF > ~\/.bashrc.d\/systemd\nexport XDG_RUNTIME_DIR=\/run\/user\/\\$(id -u)\nEOF\n$ cat ~\/.bashrc.d\/systemd \nexport XDG_RUNTIME_DIR=\/run\/user\/$(id -u)\n$ source ~\/.bashrc.d\/systemd\n\n$ echo $XDG_RUNTIME_DIR\n\/run\/user\/59388\n\n$ loginctl enable-linger $USER\n$ systemctl --user daemon-reload\n$ systemctl enable --now podman.socket --user -M saurabh@\n$  systemctl status podman.socket --user\n\u25cf podman.socket - Podman API Socket\n     Loaded: loaded (\/usr\/lib\/systemd\/user\/podman.socket; enabled; preset: disabled)\n     Active: active (listening) since Wed 2024-09-11 15:21:32 UTC; 2min 1s ago\n      Until: Wed 2024-09-11 15:21:32 UTC; 2min 1s ago\n   Triggers: \u25cf podman.service\n       Docs: man:podman-system-service(1)\n     Listen: \/run\/user\/59388\/podman\/podman.sock (Stream)\n     CGroup: \/user.slice\/user-59388.slice\/user@59388.service\/app.slice\/podman.socket<\/code><\/pre>\n\n\n\n
          I can see the session is lingering<\/p>\n\n\n\n
          loginctl list-users\n  UID USER    LINGER STATE    \n59388 saurabh yes    lingering\n\n1 users listed.\n<\/code><\/pre>\n\n\n\n
          What is loginctl<\/code>?<\/h2>\n\n\n\n
          loginctl<\/code> was introduced as part of systemd<\/code>, which was first released in 2010. It was developed by Lennart Poettering<\/code> and Kay Sievers<\/code>, initially for Fedora Linux, but has since been adopted by many other distributions.<\/p>\n\n\n\n
          Significance<\/h3>\n\n\n\n
          loginctl<\/code> is a crucial tool in modern Linux systems that use systemd<\/code>. It provides a way to introspect and control the login manager, which is responsible for keeping track of user sessions, seats (hardware setups like keyboards, mice, and monitors), and users.<\/p>\n\n\n\n
          Uses<\/strong><\/h3>\n\n\n\n
            \n
          1. List active sessions, users, and seats<\/li>\n\n\n\n
          2. Show properties of users, sessions, and seats<\/li>\n\n\n\n
          3. Attach or detach devices to seats<\/li>\n\n\n\n
          4. Enable or disable multi-seat support<\/li>\n\n\n\n
          5. Terminate user sessions<\/li>\n\n\n\n
          6. Manage user linger state (more on this below)<\/li>\n<\/ol>\n\n\n\n
            Common commands:<\/p>\n\n\n\n
              \n
            • loginctl list-sessions<\/code>: Lists all active sessions<\/li>\n\n\n\n
            • loginctl list-users<\/code>: Lists all known users<\/li>\n\n\n\n
            • loginctl show-user <username><\/code>: Shows properties of a specific user<\/li>\n\n\n\n
            • loginctl terminate-session <session-id><\/code>: Terminates a specific session<\/li>\n<\/ul>\n\n\n\n
              loginctl enable-linger $USER<\/code><\/h3>\n\n\n\n
              The loginctl enable-linger $USER<\/code> command is particularly interesting and relates to how systemd<\/code> manages user sessions. <\/p>\n\n\n\n
              Let’s break it down:<\/p>\n\n\n\n
              What it does<\/strong>: This command enables “lingering” for the specified user. When lingering is enabled, systemd<\/code> will maintain the user’s session even when they’re not logged in.<\/p>\n\n\n\n
              Why we need it:<\/p>\n\n\n\n
                \n
              1. Persistent User Services: It allows user-specific systemd services to run independently of user logins. This is crucial for users who want to run long-lived processes or services under their own user account.<\/li>\n\n\n\n
              2. Remote Management: It’s particularly useful in server environments where you want user services to continue running after SSH disconnections.<\/li>\n\n\n\n
              3. Scheduled Tasks: It enables user-specific timers (systemd’s version of cron jobs) to run even when the user is not logged in.<\/li>\n\n\n\n
              4. Container Management: For tools like Podman that run containers in user space, lingering allows these containers to keep running after logout.<\/li>\n<\/ol>\n\n\n\n
                How it works<\/strong>:<\/p>\n\n\n\n
                  \n
                1. Without lingering, systemd typically terminates all of a user’s processes when they log out.<\/li>\n\n\n\n
                2. With lingering enabled, systemd<\/code> maintains a user manager for that user even when they’re not logged in.<\/li>\n\n\n\n
                3. This user manager can then keep user services running persistently.<\/li>\n<\/ol>\n\n\n\n
                  <\/p>\n","protected":false},"excerpt":{"rendered":"
                  If you have ever seen this error, you know the pain of a fellow linux user. This is message I get when I was trying to install podman.socket Why do we need Podman.socket? In all googling I did I was able to see the problem boiling from XDG_RUNTIME_DIR which was empty on my host OS. […]<\/p>\n","protected":false},"author":2,"featured_media":2800,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[34],"tags":[112],"class_list":["post-2798","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technical","tag-linux"],"_links":{"self":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts\/2798","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/comments?post=2798"}],"version-history":[{"count":1,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts\/2798\/revisions"}],"predecessor-version":[{"id":2801,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts\/2798\/revisions\/2801"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/media\/2800"}],"wp:attachment":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/media?parent=2798"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/categories?post=2798"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/tags?post=2798"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}