Jonathan Lalou's Blog

Archive for the ‘en-US’ Category

Firebase evolves as Google’s app development platform, now deeply integrated with generative AI. Frank van Puffelen, Rich Hyndman, and Marina Coelho presented updates that streamline building, deploying, and optimizing AI-enhanced applications across platforms.

Branding Refresh and AI Accessibility

Frank introduced Firebase’s rebranding, reflecting its AI focus. The new logo symbolizes transformation, aligning with tools that make AI accessible for millions of developers.

Rich emphasized gen AI’s flexibility, enabling dynamic experiences like personalized travel suggestions. Vertex AI, Google Cloud’s enterprise platform, offers global access to models like Gemini 1.5 Pro, with SDKs for Firebase simplifying integration.

Marina showcased Vertex AI’s SDKs for Android, iOS, and web, supporting languages like Kotlin, Swift, and JavaScript. These, available since May 2024, facilitate on-device and cloud-based AI, with features like content moderation.

Frameworks for Production-Ready AI Apps

Genkit, an open-source framework, aids in developing, deploying, and monitoring AI features. It supports RAG patterns, integrating with vector databases like Pinecone.

Data Connect introduces PostgreSQL-backed databases with GraphQL APIs, ensuring type-safe queries and offline support via Firestore. In preview as of May 2024, it enhances data management for AI apps.

App Check’s integration with reCAPTCHA Enterprise prevents unauthorized AI access, bolstering security.

Optimization and Monitoring Tools

Crashlytics leverages Gemini for crash analysis, providing actionable insights. Remote Config’s personalization, powered by Vertex AI, tailors experiences based on user data.

Release Monitoring automates post-release checks, integrating with analytics for safe rollouts. These 2024 features ensure reliable AI deployments.

Platform-Specific Enhancements

iOS updates include Swift-first SDKs and Vision OS support. Android gains automated testing and device streaming. Web improvements ease SSR framework hosting on Google Cloud.

These advancements position Firebase as a comprehensive AI app platform.

Links:

• Frank van Puffelen on LinkedIn
• Rich Hyndman on LinkedIn
• Marina Coelho on LinkedIn

Olivier Poncet captivated the Riviera DEV 2025 audience with a detailed dissection of the XZ Utils attack, a sophisticated supply chain assault revealed on March 29, 2024. Through a forensic analysis, Olivier explored the attack’s two-year timeline, its blend of social and technical engineering, and its near-catastrophic implications for global server security. His presentation underscored the fragility of open-source software supply chains, urging developers to adopt rigorous practices to safeguard their systems.

The XZ Utils Attack: A Coordinated Threat

Olivier introduced the XZ Utils attack, centered on the CVE-2024-3094 vulnerability, which scored a critical 10/10 severity. XZ Utils, a widely used compression library integral to Linux distributions and kernel boot processes, was compromised with malicious code embedded in its upstream tarballs. Discovered fortuitously by Andres Freund, a PostgreSQL engineer at Microsoft, the attack aimed to weaken the SSH daemon, potentially granting attackers access to countless exposed servers. Olivier highlighted the serendipitous nature of the discovery, as Andres stumbled upon the issue during routine benchmarking, revealing suspicious behavior that led to a deeper investigation.

The attack’s objectives were threefold: corrupt the software supply chain, undermine SSH security, and achieve widespread system compromise. Olivier emphasized that this was not a mere flaw but a meticulously planned operation, exploiting the trust inherent in open-source ecosystems.

Social and Technical Engineering Tactics

The XZ Utils attack leveraged a blend of social and technical manipulation. Olivier detailed how the attacker, over two years, used social engineering to infiltrate the project’s community, likely posing as a trusted contributor to introduce malicious code. This included pressuring maintainers and exploiting the project’s reliance on a small, often unpaid, team. Technically, the attack involved injecting backdoors into the tarballs, which were then distributed to Linux distributions, bypassing standard security checks.

Olivier’s analysis, conducted through extensive virtual machine testing post-discovery, revealed the attack’s complexity, including obfuscated code designed to evade detection. He stressed that the human element—overworked maintainers and community trust—was the weakest link, highlighting the need for robust governance in open-source projects.

Supply Chain Vulnerabilities in Open Source

A key focus of Olivier’s talk was the broader vulnerability of open-source supply chains. He cited examples like the npm package “is-odd,” unnecessarily downloaded millions of times, and the “colors” package, whose maintainer intentionally broke builds worldwide by introducing malicious code. These incidents illustrate how transitive dependencies and unverified packages can introduce risks. Olivier also referenced a recent Hacker News report about over 200 malicious GitHub repositories targeting developers, underscoring the growing threat of supply chain attacks.

He warned that modern infrastructures, heavily reliant on open-source software, are only as strong as their weakest link—often a single maintainer. Tools like Docker Hub, npm, and pip, while convenient, can introduce unvetted dependencies, amplifying risks. Olivier advocated for heightened scrutiny of external repositories and dependencies to mitigate these threats.

Mitigating Risks Through Best Practices

To counter supply chain vulnerabilities, Olivier proposed practical measures. He recommended using artifact repositories like Artifactory to locally store and verify dependencies, ensuring cryptographic integrity through hash checks. While acknowledging the additional effort required, he argued that such practices significantly enhance security by reducing reliance on external sources. Auditing direct and transitive dependencies, questioning their necessity, and reimplementing simple functions locally were also advised to minimize exposure.

Olivier concluded with a call to action, urging developers to treat supply chain security as a priority. By fostering a culture of vigilance and investing in secure practices, organizations can protect their systems from sophisticated attacks like XZ Utils, preserving the integrity of the open-source ecosystem.

Links:

• Olivier Poncet on GitHub
• Olivier Poncet on Twitter/X

Has this ever happened to you? You’re excited to run a new piece of software—maybe it’s your first time executing an image manipulation with Image Magick, or perhaps launching a new video game—and instead of success, you get a cryptic pop-up: “The program can’t start because vcomp140.dll is missing from your computer.”

Panic sets in. While this issue popped up for us specifically when running Image Magick, it’s a common problem for almost any application built using Microsoft’s development tools. Fortunately, the fix is straightforward and highly reliable.

What is vcomp140.dll, Anyway?

This file is a core component of the Microsoft Visual C++ Redistributable for Visual Studio 2015-2022. Think of it as a crucial library of instructions that certain programs need to run. If this specific file is missing, corrupted, or not properly registered, the program (like Image Magick) simply cannot initialize.

Here are the three definitive steps to get your software running again.

The 3-Step Solution: Bring Back Your Missing DLL

1. Install or Repair the Official Visual C++ Redistributable (The Best Fix)

This is the most effective solution and the one that works almost every time. We need to install the official package that contains this missing file.

1. Navigate to the Microsoft Download Center: Search online for the “Visual C++ Redistributable latest supported downloads” on the official Microsoft website.
2. Download BOTH Versions: This is the critical step. Even if you have a 64-bit operating system, the problematic application (like Image Magick) might be a 32-bit program. You need to install both:
   • vc_redist.x86.exe (32-bit)
   • vc_redist.x64.exe (64-bit)
3. Install and Reboot: Run both installation files. If the package is already partially installed, the installer may offer a “Repair” option—take it! Once both installations are complete, reboot your computer. This allows the operating system to fully register the new or repaired files.

2. Run the System File Checker (SFC)

If the DLL error persists after Step 1, other related system files might be corrupted. The Windows System File Checker (SFC) tool can fix these deep-rooted issues.

1. Open Command Prompt as Administrator: Search for CMD in the Start Menu, right-click, and choose “Run as administrator.”
2. Execute the Command: Type the following command and press Enter:sfc /scannow
3. Wait for the Scan: The process takes several minutes. It will scan all protected system files and replace any corrupted files with cached copies.

3. Reinstall the Problematic Application

If the error specifically occurs with one program (like Image Magick), the problem might be with that application’s installer, not Windows itself.

1. Uninstall: Go to Windows Settings > Apps and uninstall the application completely.
2. Reinstall: Download and run the latest installer for the application. Many installers check for and include the necessary Visual C++ Redistributable package, ensuring the dependencies are handled correctly this time.

🛑 A Crucial Warning: Avoid Third-Party DLL Sites

Please, never download vcomp140.dll (or any other DLL) from non-official “DLL download” websites.

These files are often:

• Outdated and won’t solve the problem.
• Corrupted or bundled with malware, posing a security risk.
• Simply copying the file into a system folder rarely works, as the files need proper registration by the Microsoft installer.

Stick to the official Microsoft download source in Step 1 for a clean and secure fix!

I hope this guide gets you back to manipulating images with Image Magick (or whatever application was giving you trouble) in no time! Let me know in the comments if this worked for you.

Lecturer

Cameron Jenkins acts as a Managing Director in the Mainframe Modernization group at Accenture, overseeing sales, marketing, and technology products with decades of experience in legacy system transformations. Shri Kai occupies a senior role at T. Rowe Price, serving as the executive sponsor for modernization initiatives, with prior successes at Experian and CoreLogic. Joel Rosenberger functions as the AWS Mainframe Modernization Lead and Chief Architect at Accenture, strengthening partnerships and architecting programs like Go Big for large-scale migrations.

Abstract

This in-depth analysis scrutinizes the strategic value of mainframe modernization in financial services, focusing on T. Rowe Price’s migration to Amazon Web Services facilitated by Accenture’s refactoring and generative artificial intelligence tools. It dissects the methodologies for automating legacy code analysis, generating artifacts, and enhancing decision-making, while considering contextual drivers like agility and cost savings. The article evaluates implications for business users, risk mitigation, and future patterns, advocating a hybrid approach combining deterministic tools with emerging AI capabilities.

Strategic Drivers and Organizational Support

Mainframe modernization in finance yields enhanced flexibility, superior client interactions, and reduced expenses. At T. Rowe Price, the decision to decommission the mainframe and relocate core applications stems from these benefits, supported by executive buy-in from the CEO, CTO, COO, and CDO. This high-level endorsement mitigates risks associated with legacy systems, aligning technology with business objectives.

The initiative transcends cost reduction, positioning technology as a competitive advantage. Historical projects lacking such support often faltered, emphasizing the need for strategic alignment. AWS was selected due to its leadership in cloud services and proximity advantages, facilitating seamless integration.

Methodological Approaches to Code Transformation

Accenture’s tools automate analysis of legacy languages like COBOL, Assembler, and PL/1, producing technical and business documentation. Generative AI augments this by creating artifacts valuable to IT architects and business stakeholders, fostering collaboration and informed decisions.

Patterns include refactoring for twelve applications, with some sunsetting pre-migration. Post-migration flexibility allows microservices development, end-of-life planning, or incremental enhancements, tailored to business needs.

Testing remains pivotal for confidence-building, with AI generating test suites to address outdated data, reducing risks.

Code sample for basic COBOL to Java refactoring simulation in Python:

“`

Steve Flanders, a veteran in observability, delivered a 13-minute talk at Devoxx Greece 2025, outlining five reasons why OpenTelemetry (OTel) is poised to dominate observability.

Unified Data Collection

Flanders began by addressing a common pain point: managing multiple libraries for traces, metrics, and logs. OpenTelemetry, a CNCF project second only to Kubernetes in activity, offers a single, open-standard library for all telemetry signals, including profiling and real user monitoring. Supporting standards like W3C Trace Context, Zipkin, and Prometheus, OTel allows developers to instrument applications once, regardless of backend. This eliminates the need for proprietary libraries, simplifying integration and reducing rework when switching vendors.

Flexible Data Control

The OpenTelemetry Collector, deployable as an agent or gateway, provides robust data processing. Flanders highlighted its ability to filter sensitive data, like personally identifiable information, before export. Developers can send full datasets to internal data lakes while sharing subsets with vendors, offering unmatched flexibility. OTel’s modularity means you can use its instrumentation, collector, or neither, integrating with existing systems. This vendor-agnostic approach ensures data portability, as switching backends requires only configuration changes, not re-instrumentation.

Enhanced Problem Resolution

OTel’s context and correlation features link traces, metrics, and logs, accelerating issue resolution. Flanders showcased a service map visualizing errors and latency, enriched with resource metadata (e.g., Kubernetes pod, cloud provider). This allows pinpointing issues, like a faulty pod causing currency service errors, reducing mean-time-to-resolution. With broad adoption by vendors, users, and projects, and stable support for core signals, OTel is a production-ready standard reshaping observability.

Links

• OpenTelemetry
• Devoxx Greece

For many developers and DevOps engineers, creating and managing Dockerfiles can feel like a tedious chore. Ensuring best practices, optimizing image layers, and keeping up with security standards often add friction to the containerization process. Thomas DA ROCHA from Lenra, in his presentation, introduced Dofigen as an open-source command-line tool designed to simplify this. He demonstrated how Dofigen allows users to generate optimized and secure Dockerfiles from a simple YAML or JSON description, making containerization quicker, easier, and less error-prone, even without deep Dockerfile expertise.

The Pain Points of Dockerfiles

Thomas began by highlighting the common frustrations associated with writing and maintaining Dockerfiles. These include:
– Complexity: Writing effective Dockerfiles requires understanding various instructions, their order, and how they impact caching and layer size.
– Time Consumption: Manually writing and optimizing Dockerfiles for different projects can be time-consuming.
– Security Concerns: Ensuring that images are built securely, minimizing attack surface, and adhering to security standards can be challenging without expert knowledge.
– Lack of Reproducibility: Small changes or inconsistencies in the build environment can sometimes lead to non-reproducible images.

These challenges can slow down development cycles and increase the risk of deploying insecure or inefficient containers.

Introducing Dofigen: Dockerfile Generation Simplified

Dofigen aims to abstract away the complexities of Dockerfile creation. Thomas explained that instead of writing a Dockerfile directly, users provide a simplified description of their application and its requirements in a YAML or JSON file. This description includes information such as the base image, application files, dependencies, ports, and desired security configurations. Dofigen then takes this description and automatically generates an optimized and standards-compliant Dockerfile. This approach allows developers to focus on defining their application’s needs rather than the intricacies of Dockerfile syntax and best practices. Thomas showed a live coding demo, transforming a simple application description into a functional Dockerfile using Dofigen.

Built-in Best Practices and Security Standards

A key advantage of Dofigen is its ability to embed best practices and security standards into the generated Dockerfiles automatically. Thomas highlighted that Dofigen incorporates knowledge about efficient layering, reducing image size, and minimizing the attack surface by following recommended guidelines. This means users don’t need to be experts in Dockerfile optimization or security to create robust images. The tool handles these aspects automatically based on the provided high-level description. Thomas might have demonstrated how Dofigen helps in creating multi-stage builds or incorporating user and permission best practices, which are crucial for building secure production-ready images. By simplifying the process and baking in expertise, Dofigen empowers developers to containerize their applications quickly and confidently, ensuring that the resulting images are not only functional but also optimized and secure. The open-source nature of Dofigen also allows the community to contribute to improving its capabilities and keeping up with evolving best practices and security recommendations.

Links:

• Thomas DA ROCHA: https://www.linkedin.com/in/thomasdarocha/
• Lenra: https://www.lenra.io/
• Dofigen on GitHub: https://github.com/lenra-io/dofigen
• Devoxx France LinkedIn: https://www.linkedin.com/company/devoxx-france/
• Devoxx France Bluesky: https://bsky.app/profile/devoxx.fr
• Devoxx France Website: https://www.devoxx.fr/

Orchestrating Complex Systems with Rust

In the realm of industrial automation, managing fleets of autonomous mobile robots (AMRs) demands precision and reliability. At OxidizeConf2024, Andy Brinkmeyer from Arculus shared his experience developing a deterministic fleet management system using Rust, orchestrating over 100 robots in warehouse and manufacturing environments. Andy’s presentation highlighted how Rust’s performance, safety, and expressive type system enabled Arculus to tackle order coordination, route planning, and traffic management with a robust, maintainable codebase.

Arculus’s fleet management system handles the intricate task of transporting goods in confined spaces like distribution centers. Andy explained how Rust’s ecosystem facilitated a re-simulation framework, allowing developers to replay recorded logs to debug and validate system behavior. By combining synchronous deterministic components with an async I/O runtime, Arculus created a mockable system design that ensures consistent outcomes, critical for mission-critical applications where predictability is non-negotiable.

Leveraging Rust’s Concurrency Primitives

Rust’s concurrency model played a pivotal role in Arculus’s system. Andy detailed the use of synchronous components for core logic, processing fixed-size input messages to advance the system state. This deterministic approach eliminates the need for async within the main event loop, simplifying the architecture. However, async I/O was employed for external communication, using Rust’s tokio runtime to handle network interactions efficiently. This hybrid design balances performance with flexibility, enabling re-simulation without altering core logic.

When questioned about intra-task async operations, Andy noted that Arculus found no need for such complexity, as the deterministic state machine sufficed for their use case. The system’s ability to mock I/O components during re-simulation allows developers to isolate issues, though Andy acknowledged challenges in replaying new messages due to state dependencies. This approach underscores Rust’s ability to support complex industrial systems with clear, maintainable code.

Enhancing Maintainability with Procedural Macros

Procedural macros were a cornerstone of Arculus’s development process, enhancing code readability and maintainability. Andy described how macros derived state representations for complex types, reducing boilerplate and ensuring consistency across the fleet manager’s modules. This approach streamlined debugging and integration testing, with a Rust-based test framework enabling developers to recreate issues efficiently. By stepping into problematic states with a debugger, Arculus could pinpoint errors without simulating the entire system.

The talk also addressed limitations, such as the inability to fully replay new messages due to circular dependencies with robot communications. Andy suggested that future work could explore vehicle simulation to address this, though current methods—leveraging integration tests and deterministic logs—prove effective. Rust’s ecosystem, including tools like cargo, empowered Arculus to build a scalable, reliable system, setting a benchmark for industrial automation.

Links:

• Arculus company website

The journey of an object within a computer’s memory is a topic that is often obscured from the everyday developer. In a highly insightful session, Troels Lund, a leader on the Kotlin/Native team at Google, delves into the intricacies of what transpires behind the scenes when an object is instantiated and subsequently discarded within the Kotlin/Native runtime. This detailed examination provides a compelling look at a subject that is usually managed automatically, demonstrating the sophisticated mechanisms at play to ensure efficient memory management and robust application performance.

The Inner Workings of the Runtime

Lund begins by exploring the foundational elements of the Kotlin/Native runtime, highlighting its role in bridging the gap between high-level Kotlin code and the native environment. The runtime is responsible for a variety of critical tasks, including memory layout, garbage collection, and managing object lifecycles. One of the central tenets of this system is its ability to handle memory allocation and deallocation with minimal developer intervention. The talk illustrates how an object’s structure is precisely defined in memory, a crucial step for both performance and predictability. This low-level perspective offered a new appreciation for the seamless operation that developers have come to expect.

A Deep Dive into Garbage Collection

The talk then progresses to the sophisticated mechanisms of garbage collection. A deep dive into the Kotlin/Native memory model reveals a system designed for both performance and concurrency. Lund describes the dual approach of a parallel mark and concurrent sweep and a concurrent mark and sweep. The parallel mark and concurrent sweep is designed to maximize throughput by parallelizing the marking phase, while the concurrent mark and sweep aims to minimize pause times by allowing the sweeping phase to happen alongside application execution. The session details how these processes identify and reclaim memory from objects that are no longer in use, preventing memory leaks and maintaining system stability. The discussion also touches upon weak references and their role in memory management. Lund explains how these references are cleared out in a timely manner, ensuring that objects that should be garbage-collected are not resurrected.

Final Thoughts on the Runtime

In his concluding remarks, Lund offers a final summary of the Kotlin/Native runtime. He reiterates that this is a snapshot of what is happening now, and that the details are subject to change over time as new features are added and existing ones are optimized. He emphasizes that the goal of the team is to ensure that the developer experience is as smooth and effortless as possible, with the intricate details of memory management handled transparently by the runtime. The session serves as a powerful reminder of the complex engineering that underpins the simplicity and elegance of the Kotlin language, particularly in its native context.

Links:

• Google company website

Pioneering Rust in Automotive Middleware

The automotive industry demands robust, reliable software to manage complex communication protocols, particularly for software-defined vehicles. At OxidizeConf2024, Sebastian Rietzscher from CARIAD, alongside Simon Gasse and Morgen Mey from Accenture, delivered an insightful exploration of SommR, a Rust-based implementation of the Scalable Service-Oriented Middleware over IP (SOME/IP) protocol. This trio from Volkswagen’s software arm and Accenture’s consulting expertise showcased how Rust’s safety and performance features enable a modern approach to automotive communication, addressing challenges in serialization, testing, and documentation.

SOME/IP, a standard for remote procedure calls and service discovery in automotive electronic control units (ECUs), is typically implemented in closed-source stacks. Sebastian, Simon, and Morgen presented SommR as a fully Rust-based alternative, focusing on its daemon—the central hub for communication. The daemon facilitates publish-subscribe patterns and service discovery over TCP or UDP, critical for rich OS ECUs running Linux or real-time embedded systems. By leveraging Rust, SommR ensures type safety and memory guarantees, vital for meeting ISO 26262 safety standards.

Simplifying Communication with Serde

A key challenge in SOME/IP is its flexible serialization, which allows varied string encodings and tag-length-value formats, complicating deserialization. Simon detailed SommR’s use of a specialized serde data format to handle this complexity. Unlike eager deserialization, which loads entire payloads into memory, SommR explores limited borrowing to optimize performance, though Sebastian noted constraints due to SOME/IP’s inconsistent struct layouts. This approach enhances efficiency in resource-constrained ECUs, ensuring robust communication between applications and the daemon.

The team also introduced cloneable connections, enabling multiple applications to share communication channels without compromising safety. This design simplifies app-to-app interactions across the network, a critical feature for automotive systems where scalability is paramount. By integrating serde with Rust’s type system, SommR provides a clean, safe API that reduces errors and enhances maintainability, aligning with the industry’s push for reliable software in safety-critical environments.

Enhancing Testing with Custom Macros

Testing in automotive software requires rigorous coverage to meet quality standards, yet debugging complex macros can be daunting. Morgen shared how SommR extended Rust’s #[test] macro to create a custom testing framework, making it more accessible and engaging. Using tools like cargo-expand, quote, and syn, the team simplified macro development, while trybuild sanitized error messages, improving developer experience. This effort resulted in an impressive 80% test coverage, satisfying quality departments and encouraging broader test adoption among developers.

The custom macro approach streamlined testing for SommR’s daemon and applications, ensuring compliance with automotive standards. However, challenges like macro debugging complexity were acknowledged, with Morgen advising reliance on established tools to avoid manual token stream manipulation. This testing strategy not only enhances code reliability but also fosters a culture of quality within the development team, a critical factor for SommR’s planned transition to mass production.

Addressing Versioning and Observability

Versioning and observability posed significant hurdles for SommR, particularly in maintaining compatibility across frequent updates. Sebastian highlighted the team’s detours in managing versioning, where Rust’s strict type system required careful handling to avoid breaking changes. Observability, crucial for monitoring communication flows in automotive systems, was improved through enhanced logging and tracing, leveraging Rust’s ecosystem tools to provide actionable insights.

Documentation emerged as a final theme, with the team emphasizing its role in ensuring SommR’s usability and maintainability. By prioritizing clear, comprehensive documentation, they aim to support developers integrating SommR into production systems. While currently a demonstrator, Sebastian expressed confidence in SommR’s path to series production, driven by Rust’s safety guarantees and the team’s collaborative efforts with CARIAD and Accenture.

Links:

• CARIAD company website
• Accenture company website

This comprehensive tutorial addresses the complex and persistent issue of the Docker daemon failing to start with a "Device or resource busy" error when running a native Docker Engine inside a WSL 2 (Windows Subsystem for Linux 2) distribution, ultimately leading to the necessity of switching to Docker Rootless Mode.

1. The Problem Overview

The core issue is the native system-wide Docker daemon (dockerd) failing to initialize upon startup inside the WSL 2 environment. This failure manifests as a persistent loop of errors:

1. High-Level Status: Active: failed (Result: exit-code) or Start request repeated too quickly.
2. Access Block: Attempts to clear corrupted storage often fail with mv: cannot move '/var/lib/docker': Device or resource busy.
3. Root Cause: The failures stem from a combination of stale lock files (docker.pid), corrupted storage metadata (metadata.db), and fundamental conflicts with the WSL 2 kernel's implementation of features like Cgroups or network socket activation.

To resolve this reliably, the solution is to bypass the system-level conflicts by switching from the problematic rootful daemon to the more stable Docker Rootless mode.

---

2. Step-by-Step Resolution

The resolution involves three phases: diagnosing the specific low-level crash, performing an aggressive cleanup to free the lock, and finally, installing the stable rootless solution.

Phase 1: Aggressive Cleanup and File Lock Removal

The persistent "Device or resource busy" error is the primary block. Even a full Windows reboot or wsl --shutdown often fails to clear the lock held on /var/lib/docker.

A. Forcefully Shut Down WSL 2

1. Close all WSL terminals.
2. Open Windows PowerShell (or CMD).
3. Execute the global shutdown command: This ensures the Linux kernel and all running processes are terminated, releasing file locks.

   wsl --shutdown
   

B. Identify and Rename the Corrupted Directory

1. Relaunch your WSL terminal.
2. Rename the Corrupted Docker Storage: This creates a fresh start for the storage driver. If this fails with Device or resource busy (which is highly likely), proceed to step C.

   sudo mv /var/lib/docker /var/lib/docker.bak
   

3. [If Rename Fails] Terminate and Delete the Lock File: The daemon failed because it was locked by a rogue PID, which often leaves behind a stale PID file.

   # Stop the failing service (just in case it auto-started)
   sudo systemctl stop docker.service
   
   # Delete the stale PID file that falsely signals the daemon is running
   sudo rm /var/run/docker.pid
   

Phase 2: Switch to Docker Rootless Mode

Rootless mode installs the daemon under your standard user account, isolating it from the system-level issues that caused the failure.

A. Install Prerequisites

Install the uidmap package, which is necessary for managing user namespaces in the rootless environment.

1. Check and clear any package locks (if necessary):
   If sudo apt install hangs, check for and kill the conflicting process (e.g., unattended-upgr using sudo kill -9 <PID>), and then delete the lock files:

   sudo rm /var/lib/dpkg/lock-frontend
   sudo rm /var/lib/dpkg/lock
   sudo dpkg --configure -a
   

2. Install uidmap:

   sudo apt update
   sudo apt install uidmap
   

B. Install the Rootless Daemon

1. Ensure the system-wide daemon is stopped and disabled to prevent conflicts:

   sudo systemctl stop docker.service
   sudo systemctl disable docker.service
   sudo rm /var/run/docker.sock # Clean up the system socket
   

2. Run the Rootless setup script:

   dockerd-rootless-setuptool.sh install
   

Phase 3: Configure and Launch

The setup script completes the installation but requires manual configuration to launch the daemon and set the necessary environment variables.

A. Configure Shell Environment

1. Edit your bash profile (~/.bashrc):

   vi ~/.bashrc
   

2. Add the necessary environment variables (these lines are typically provided by the setup script and redirect the client to the rootless socket):

   # Docker Rootless configuration for user <your_username>
   export XDG_RUNTIME_DIR=/home/<your_username>/.docker/run
   export PATH=/usr/bin:$PATH
   export DOCKER_HOST=unix:///home/<your_username>/.docker/run/docker.sock
   

3. Save the file and exit the editor.

B. Startup Sequence (Required on Every WSL Launch)

Because your WSL environment is not using a fully managed systemd to start the rootless daemon automatically, you must execute the following two commands every time you open a new terminal:

1. Source the configuration: Activates the DOCKER_HOST environment variable in the current session.

   source ~/.bashrc
   

2. Start the Rootless Daemon: Launches the user-level daemon in the background.

   dockerd-rootless.sh &
   

C. Final Verification

Wait a few seconds after launching the daemon, then verify connectivity:

docker ps

The client will now connect to the stable, user-level daemon, resolving the persistent startup failures.