Explained: Complete Guide to systemd-logind, Power Keys, Laptop Lids, VTs & User Sessions

 If you use Linux on a laptop, desktop, server, or remote-access machine, there is a good chance that systemd-logind is quietly controlling more of your system than you realize.

Why does closing the laptop lid suspend the system?
Why does pressing the power button shut it down?
Why do processes sometimes survive logout?
Why can applications prevent the system from sleeping?
Why does Linux provide multiple virtual terminals?

A large part of the answer is systemd-logind.

Its primary configuration file is:

/etc/systemd/logind.conf

The file controls login sessions, virtual terminals, power and sleep keys, laptop-lid events, idle actions, user-process cleanup, runtime directories, and inhibitor locks. The official systemd documentation describes logind.conf as the configuration file for the systemd login manager.

Important: logind.conf is powerful. A small configuration change can affect how a laptop sleeps, how remote sessions behave, or whether user processes survive logout. Always make a backup before modifying it.

---

1. What Is systemd-logind?

systemd-logind is the systemd component responsible for managing user logins and sessions.

It keeps track of things such as:

• Logged-in users
• User sessions
• Seats
• Virtual terminals
• Graphical and text sessions
• Power-button events
• Suspend/hibernate events
• Laptop-lid events
• Idle state
• User runtime directories
• Session-related cleanup
• Inhibitor locks

It also exposes this information through the systemd login manager interface, which tools such as loginctl can query and control.

Think of it as a bridge between physical hardware events, user sessions and system power management.

                ┌─────────────────────┐
                │      Hardware       │
                │                     │
                │ Power Button        │
                │ Lid Switch          │
                │ Sleep Key           │
                │ Hibernate Key       │
                └──────────┬──────────┘
                           │
                           ▼
                 ┌──────────────────┐
                 │ systemd-logind   │
                 └────────┬─────────┘
                          │
          ┌───────────────┼────────────────┐
          ▼               ▼                ▼
       Sessions       Power State       Virtual TTYs
          │               │                │
          ▼               ▼                ▼
       loginctl        suspend          getty
                      hibernate
                      poweroff

---

2. Where Is logind.conf?

The primary administrator configuration file is:

/etc/systemd/logind.conf

Inspect it with:

sudo cat /etc/systemd/logind.conf

Or:

sudo nano /etc/systemd/logind.conf

You can also inspect the currently running logind service:

systemctl status systemd-logind

And inspect sessions:

loginctl

For more detailed information:

loginctl list-sessions

loginctl session-status

The loginctl utility is specifically intended to inspect and control the systemd login manager.

---

3. Virtual Terminals — NAutoVTs and ReserveVT

Kali Linux Remote Desktop: Access GNOME from Windows Using Native RDP

 Kali Linux + GNOME 50 + GNOME Remote Desktop + Windows Remote Desktop (MSTSC)

Getting a full GNOME desktop remotely on Kali Linux can be confusing because there are several different technologies involved: GNOME, GDM3, Wayland, gnome-remote-desktop, RDP, and the user/system systemd services.

This guide documents a working Kali Linux setup where a Windows machine connects to Kali using the built-in Remote Desktop Connection (mstsc) and receives a full GNOME desktop session.

The important part is that this configuration uses GNOME Remote Login, rather than traditional xrdp.

---

What We Are Building

The final architecture looks like this:

┌─────────────────────────────┐
│       Windows 10/11         │
│                             │
│  Remote Desktop Connection  │
│          mstsc.exe          │
└──────────────┬──────────────┘
               │
               │ RDP / TCP 3389
               │
               ▼
┌─────────────────────────────┐
│          Kali Linux         │
│                             │
│           GDM3              │
│             │               │
│             ▼               │
│      GNOME Remote Desktop  │
│             │               │
│             ▼               │
│       GNOME Desktop         │
│       GNOME Shell 50.x      │
│                             │
│         Wayland             │
└─────────────────────────────┘

GNOME's Remote Login implementation integrates with GDM and provides remote login through RDP. GNOME documents this as the headless multi-user remote login mode.

---

Why GNOME Instead of Xfce?

Kali supports several desktop environments, including GNOME and Xfce. The Kali GNOME desktop is provided by the kali-desktop-gnome metapackage and includes components such as gdm3, gnome-session, and gnome-shell.

For this configuration, the goal was specifically:

Windows
   ↓
RDP
   ↓
Kali
   ↓
GNOME

Rather than:

Windows
   ↓
xrdp
   ↓
Xfce

Both approaches are possible, but they are different architectures.

GNOME Remote Desktop has native support for RDP and can integrate with GDM for remote login.

---

Step 1 — Check the Current Desktop

When connecting to Kali through SSH, these commands may initially show:

echo "Desktop: $XDG_CURRENT_DESKTOP"
echo "Session: $XDG_SESSION_TYPE"

Output:

Desktop:
Session: tty

This does not mean GNOME is missing.

It simply means the current SSH session is a TTY rather than a graphical GNOME session.

For example, GNOME Shell itself can still be installed:

gnome-shell --version

In this setup, the system reported:

GNOME Shell 50.4

So the important distinction is:

SSH session
    ↓
TTY

RDP session
    ↓
GNOME graphical session

Do not use the SSH environment variables alone to determine whether GNOME is installed.

---

Linux Recovery Tools & Options: The Complete Guide to Fixing a Broken Linux System

LINUX TROUBLESHOOTING • RESCUE • RECOVERY

Linux Recovery Tools
The Complete Guide

From GRUB and rescue mode to fsck, chroot, LUKS, LVM, SystemRescue, Rescuezilla, Clonezilla and GParted — learn how to recover a broken Linux system step by step.

Explore Recovery Options Rescue Toolkit

Linux recovery is a layered process. When Linux stops booting, don't immediately reinstall the operating system. First determine whether the problem is related to the bootloader, filesystem, kernel, initramfs, storage, configuration, permissions, encryption, or hardware.

One of the biggest advantages of Linux is that even when the graphical desktop is completely unavailable, you can often boot into a recovery environment and repair the installation from a terminal.

A good Linux administrator should therefore understand both built-in recovery mechanisms and external bootable rescue environments.

📚 Table of Contents

• Linux Recovery Options
• Understanding Linux Boot Problems
• GRUB Bootloader Recovery
• Recovery Mode / Rescue Mode
• systemd Rescue & Emergency Targets
• Filesystem Recovery with fsck
• Disk & SMART Diagnostics
• chroot Recovery
• initramfs Recovery
• LUKS Encryption Recovery
• LVM Recovery
• Live USB Recovery
• Linux Rescue Tools
• Disk Imaging & Cloning
• Partition Recovery
• Network Troubleshooting
• Real-World Recovery Scenarios
• Recovery Decision Tree

1. Linux Recovery Options at a Glance

🛠️

Recovery Mode

Many distributions provide a recovery option through the bootloader that can start a minimal environment.

🚀

GRUB

GRUB controls the boot process and can often be repaired without reinstalling Linux.

💽

fsck

Checks and repairs supported Linux filesystems.

🔧

chroot

Allows you to enter a damaged Linux installation from another boot environment.

🔐

LUKS

Provides tools for unlocking encrypted Linux storage during recovery.

📦

LVM

Allows recovery and management of logical volumes.

Windows Recovery Tools & Options: The Complete Guide to Fixing Windows

WINDOWS TROUBLESHOOTING & RECOVERY

Windows Recovery Tools
The Complete Guide

From built-in Windows Recovery Environment and Safe Mode to DISM, SFC, BCDBoot, installation media and professional WinPE rescue environments.

Explore Recovery Options Technician Toolkit

Quick idea: When Windows refuses to boot, crashes repeatedly, becomes corrupted or suffers from a damaged bootloader, you don't necessarily need to reinstall Windows. Windows provides several layers of recovery tools, ranging from simple graphical options to powerful command-line repair utilities.

Windows recovery is best approached as a layered troubleshooting process. Start with the least destructive option and move toward advanced recovery only when necessary.

📚 Table of Contents

• Windows Recovery Options
• Windows Recovery Environment
• Startup Repair
• Safe Mode
• System Restore
• Uninstall Updates
• Command Prompt Recovery
• SFC
• DISM
• Bootloader Repair
• Windows Installation Media
• Third-Party Recovery Tools
• Professional Technician Toolkit
• Which Recovery Tool Should You Use?

1. Windows Recovery Options at a Glance

🛠️

Startup Repair

Automatically attempts to repair problems preventing Windows from booting.

🧪

Safe Mode

Starts Windows with a minimal set of drivers and services.

↩️

System Restore

Returns system configuration to an earlier restore point.

💻

Command Prompt

Provides advanced offline troubleshooting capabilities.

🔧

DISM

Repairs Windows component-store corruption.

🧹

SFC

Checks and repairs protected Windows system files.

2. Windows Recovery Environment — WinRE

Windows Recovery Environment (WinRE) is Microsoft's built-in recovery environment. It is a lightweight Windows-based environment designed to help diagnose and repair problems when normal Windows cannot start correctly.

Windows

→

Recovery

→

WinRE

→

Repair

Typical WinRE options

• Startup Repair
• System Restore
• System Image Recovery
• Uninstall Updates
• Startup Settings
• Command Prompt
• UEFI Firmware Settings

SCP in Linux: A Comprehensive, Easy-to-Understand Guide










scp — Secure Copy — is one of the simplest ways to transfer files and directories between Linux machines over an SSH connection.

If you work with Linux servers, AWS, Azure, Docker, Kubernetes, Hadoop, DevOps, SRE, or system administration, scp is a command you will use frequently.

For example:

scp backup.tar.gz user@192.168.1.20:/home/user/

This means:

Take backup.tar.gz from my current machine and securely copy it to /home/user/ on 192.168.1.20.

Modern OpenSSH scp uses the SFTP protocol over an SSH connection by default, while retaining the familiar scp command syntax. It uses the same SSH authentication and security model as an SSH login.

---

1. What is SCP?

SCP stands for:

Secure Copy Protocol / Secure Copy

The scp command allows you to copy:

• Local → Remote
• Remote → Local
• Directory → Remote
• Remote → Directory
• Remote → Remote

The important concept is that SSH is used for authentication and encrypted communication.

Think of it this way:

Your Linux Machine
       |
       | SSH encrypted connection
       |
       v
Remote Linux Server

Instead of:

FTP
   |
   +---- username/password
   +---- potentially insecure depending on configuration

you can use:

SCP
 |
 +---- SSH authentication
 +---- encrypted connection
 +---- secure file transfer

---

2. Why Do We Use SCP?

Imagine you have this situation:

Your Laptop
10.10.10.5

and your server is:

Production Server
10.10.10.20

You created:

application.tar.gz

on your laptop and need to put it on the server.

Without SCP, you might need:

• FTP
• SFTP client
• cloud storage
• USB
• web upload
• email
• shared network storage

With SCP:

scp application.tar.gz user@10.10.10.20:/opt/apps/

Done.

---

3. Basic SCP Syntax

Podman: The Complete Guide to Rootless, Daemonless Containers

Podman is an open-source container engine designed to build, run, manage, and deploy OCI containers and pods. It provides a Docker-compatible CLI experience while taking a fundamentally different approach: Podman is daemonless and can run containers rootlessly as a regular Linux user.

For developers, DevOps engineers, SREs, platform engineers, and administrators, Podman is particularly interesting when you want containerization without depending on a permanently running privileged daemon.

---

1. What is Podman?

Podman originally stands for Pod Manager.

It provides commands for:

• Running containers
• Building images
• Managing images
• Managing pods
• Creating networks
• Managing volumes
• Running containers without root
• Integrating containers with systemd
• Running Kubernetes YAML locally
• Working with OCI-compatible images and runtimes

A major design characteristic is that Podman is daemonless. Unlike the traditional Docker architecture, there isn't a central Docker daemon that all local container operations must go through.

Conceptually:

Traditional Docker-style model

User
  |
  v
Docker CLI
  |
  v
Docker Daemon
  |
  +---- Container
  +---- Container
  +---- Image
  +---- Network

Podman:

User
  |
  v
Podman CLI
  |
  +---- Container
  +---- Container
  +---- Pod
  +---- Image
  +---- Network

That architectural difference becomes especially important for rootless containers and systemd-based deployments.

---

2. Podman vs Docker

OpenShift: A Comprehensive Guide to Enterprise Kubernetes

OpenShift is Red Hat's enterprise Kubernetes platform for building, deploying, securing, operating, and scaling containerized applications.

If Kubernetes provides the orchestration foundation, OpenShift adds an integrated platform around it: security controls, Operators, networking and Routes, a web console, image/build workflows, cluster lifecycle management, monitoring, and enterprise-oriented administration. OpenShift Container Platform 4.20 is built on Kubernetes and uses Red Hat Enterprise Linux CoreOS (RHCOS) and CRI-O as core node technologies.

This guide covers OpenShift from fundamentals through architecture, administration, application deployment, networking, storage, security, Operators, CI/CD, troubleshooting, and production design.

---

1. What Is OpenShift?

At its simplest:

Kubernetes
    +
Enterprise platform capabilities
    +
Security
    +
Developer tooling
    +
Operators
    +
Integrated networking
    +
Cluster lifecycle management
    +
Web console
    =
OpenShift

OpenShift is therefore not a completely separate alternative to Kubernetes.

It is a Kubernetes-based platform that adds significant functionality and opinionated operational components around Kubernetes. Red Hat describes OpenShift Container Platform as a Kubernetes platform for building, deploying, and managing enterprise container workloads.

---

2. Kubernetes vs OpenShift

A useful mental model is:

                 OpenShift
┌──────────────────────────────────────────┐
│ Web Console                              │
│ Developer Tools                          │
│ Routes                                   │
│ Operators / OperatorHub                  │
│ Builds / ImageStreams                    │
│ SCC / Security                           │
│ Monitoring                               │
│ Authentication                           │
│ Cluster Lifecycle                        │
├──────────────────────────────────────────┤
│              Kubernetes                  │
│ Pods / Deployments / Services             │
│ Scheduling / Controllers / API            │
├──────────────────────────────────────────┤
│              Container Runtime            │
│                  CRI-O                    │
├──────────────────────────────────────────┤
│                  RHCOS                   │
└──────────────────────────────────────────┘

OpenShift retains Kubernetes concepts such as:

• Pods
• Deployments
• ReplicaSets
• Services
• ConfigMaps
• Secrets
• PersistentVolumeClaims
• StatefulSets
• Jobs
• CronJobs
• RBAC
• NetworkPolicy

while adding OpenShift-specific APIs and platform components.

---

3. OpenShift Architecture

HashiCorp Nomad: A Comprehensive Guide to Workload Orchestration

HashiCorp Nomad is a distributed workload orchestrator designed to deploy and manage containers, batch jobs, long-running services, legacy applications, and other workloads across clusters of machines.

If Docker answers:

“How do I run this container?”

and Kubernetes answers:

“How do I orchestrate containers across a cluster?”

Nomad takes a somewhat broader and simpler approach:

“How do I schedule and operate different kinds of workloads across my infrastructure?”

Nomad can run Docker containers, binaries, Java applications, QEMU workloads, and other task-driver-based workloads. HashiCorp describes it as a highly available, distributed, datacenter-aware scheduler designed for services, batch jobs, and more.

---

1. What Is HashiCorp Nomad?

Nomad is a cluster scheduler and workload orchestrator developed by HashiCorp.

Its core responsibilities include:

• Scheduling workloads
• Allocating CPU and memory
• Placing workloads on appropriate nodes
• Running long-lived services
• Running batch jobs
• Running jobs on every node
• Handling workload failures
• Rolling out updates
• Managing task lifecycle
• Service registration
• Integrating with Consul
• Integrating with Vault
• Supporting multiple datacenters
• Supporting heterogeneous workloads

A simplified architecture is:

                    NOMAD
                      │
             ┌────────┴────────┐
             │                 │
        Nomad Servers      Nomad Clients
             │                 │
        Scheduling         Run workloads
        Cluster State      Containers
        Coordination       Binaries
             │             Batch jobs
             │             Services
             ▼
          Allocations

Nomad's servers handle scheduling and cluster management, while clients execute the workloads assigned to them.

---

2. Why Nomad?

Traditional application deployment might look like:

Server 1 → Application A
Server 2 → Application B
Server 3 → Application C
Server 4 → Application D

As infrastructure grows, you need to answer:

• Where should an application run?
• Does the server have enough CPU?
• Does it have enough memory?
• Does it have the required runtime?
• What happens if the server fails?
• How do we deploy five copies?
• How do we update them?
• How do we run a job every night?
• How do we deploy something to every node?
• How do services discover each other?

Nomad provides a scheduling and reconciliation layer.

Desired State
      │
      ▼
   Nomad Job
      │
      ▼
   Scheduler
      │
      ▼
 Allocation Plan
      │
      ▼
 Nomad Clients
      │
      ▼
 Workloads

---

3. Nomad vs Kubernetes