Skip to content

Add port conflict detection during installation #10

@Art4Man

Description

@Art4Man

Problem Description
The PasarGuard installation script currently does not check if port 8000 is already in use before starting the application. This causes installation failures when users have other services running on the default port.
when port 8000 is already in used and occupied by another service installation script downloads .env.example as .env with port 8000 then Docker containers start with 'network_mode: host' aftert that PasarGuard try to bind localhost to :8000. here if another container or application occupiding the 8000 port it will go on infinity loop to restrat the panel to run the PasarGuard.

This is a common issue that affects many users who:

  • Run multiple web services on the same server
  • Use port 8000 for other applications (common for Python dev servers, Node.js apps, etc.)
  • Follow the quick installation guide without anticipating port conflicts

port 8000 is a commonly used port, adding this check would improve the installation experience.

Example Error Log

pasarguard-1   | INFO:     2025-11-25 10:44:43,328 - Started server process [7]
pasarguard-1   | INFO:     2025-11-25 10:44:43,328 - Waiting for application startup.
pasarguard-1   | INFO:     2025-11-25 10:44:43,525 - Application startup complete.
pasarguard-1   | ERROR:    2025-11-25 10:44:43,525 - [Errno 98] error while attempting to bind on address ('127.0.0.1', 8000): address already in use
pasarguard-1   | INFO:     2025-11-25 10:44:43,526 - Waiting for application shutdown.
pasarguard-1 exited with code 1 (restarting)

Expected Behavior
The installation script should:

  1. Check if port 8000 is available before proceeding
  2. Prompt the user to enter a custom port if 8000 is occupied
  3. Validate that the chosen port is also available
  4. Automatically update the .env file with the selected port
  5. Display clear messaging about which port is being used

Contribution
I'm interested in contributing this feature via a Pull Request if the maintainers are open to it; and this approach aligns with the project's design philosophy
i that case let me know of:

  1. Any specific requirements or preferences for the contribution or implementation
  2. Whether you'd prefer this in the scripts repository, panel repository, or both

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions