# How to Manage Container Naming and Prevent Conflicts in InternetIncome

> Learn how to manage container naming and prevent conflicts in InternetIncome. Discover unique identifiers, service prefixes, and runtime checks for seamless Docker operations.

- Repository: [engageub/internetincome](https://github.com/engageub/internetincome)
- Tags: how-to-guide
- Published: 2026-03-01

---

**InternetIncome prevents Docker container name collisions by generating a cryptographically unique 32-character identifier per script execution, combining it with service-specific prefixes, and enforcing a strict runtime check that aborts if any name already exists.**

The `engageub/internetincome` repository orchestrates dozens of micro-services—Honeygain, Mysterium, ProxyRack, and others—each running in isolated Docker containers. To manage container naming and prevent conflicts in InternetIncome, the codebase implements a deterministic naming scheme coupled with a runtime guard that ensures no two containers share the same identity, even during parallel script executions.

## The Unique Device Identifier Foundation

Every execution of [`internetIncome.sh`](https://github.com/engageub/internetincome/blob/main/internetIncome.sh) begins by generating a **UNIQUE_ID** that serves as the root of all container identities for that session.

### Generating the 32-Character Hex String

At line 73 of [`internetIncome.sh`](https://github.com/engageub/internetincome/blob/main/internetIncome.sh), the script creates a non-repeating identifier using entropy from the kernel:

```bash
UNIQUE_ID=`cat /dev/urandom | LC_ALL=C tr -dc 'a-f0-9' | dd bs=1 count=32 2>/dev/null`

```

This 32-character hexadecimal string is generated once per script run and reused for every subsequent container. Because the value is derived from `/dev/urandom`, two independent executions on the same host will produce different IDs, eliminating the risk of cross-session collisions.

### Per-Service Prefix Structure

Each container name follows a deterministic pattern that combines the session ID with a service-specific prefix and an index variable:

```

<prefix><UNIQUE_ID><i>

```

- **`<prefix>`** is a short, service-specific string defined in the script (e.g., `tun` for Tune, `myst` for Mysterium, `earnapp` for EarnApp).
- **`<i>`** is the loop index, typically set to `1`, allowing the script to spawn multiple proxy instances when needed.

For example, Honeygain containers are named using the pattern shown at line 828 of [`internetIncome.sh`](https://github.com/engageub/internetincome/blob/main/internetIncome.sh):

```bash
sudo docker run -d --name honey$UNIQUE_ID$i …

```

## The Conflict Prevention Mechanism

Before any `docker run` command executes, the script validates name availability through a centralized guard function.

### How check_container_exists Works

The `check_container_exists` function, defined at lines 126–131 of [`internetIncome.sh`](https://github.com/engageub/internetincome/blob/main/internetIncome.sh), implements the primary safety check:

```bash
check_container_exists() {
  local container_name="$1"
  if [ -z "$container_name" ]; then
    echo -e "${RED}Error: container_name is required.Exiting..${NOCOLOUR}"
    exit 1
  fi
  if sudo docker inspect "$container_name" >/dev/null 2>&1; then
    echo -e "${RED}A container with name $container_name already exists.Exiting..${NOCOLOUR}"
    exit 1
  else
    echo "$container_name" | tee -a "$container_names_file"
  fi
}

```

The function performs three critical operations:
1. **Validation**: Ensures a name parameter was provided.
2. **Collision Detection**: Uses `docker inspect` to verify the name is not already in use; if the command succeeds (container exists), the script terminates immediately.
3. **Registry Recording**: Appends the approved name to [`containernames.txt`](https://github.com/engageub/internetincome/blob/main/containernames.txt) for lifecycle management by helper scripts.

### The Centralized Registry (containernames.txt)

All container names are stored in a plain-text manifest defined at the top of [`internetIncome.sh`](https://github.com/engageub/internetincome/blob/main/internetIncome.sh):

```bash
container_names_file="containernames.txt"

```

This file is regenerated on each fresh execution—the script removes it during cleanup around line 1273—ensuring stale names cannot persist between runs. Because `check_container_exists` appends only validated names to this list, the registry always reflects the exact set of containers owned by the current script instance.

## Helper Script Integration

The naming registry enables precise lifecycle management across the InternetIncome toolkit without affecting foreign containers.

### restart.sh Operations

The [`restart.sh`](https://github.com/engageub/internetincome/blob/main/restart.sh) helper script iterates over [`containernames.txt`](https://github.com/engageub/internetincome/blob/main/containernames.txt) to target only script-owned containers. At line 114, it reads the file to perform stop/start operations:

```bash
for container in `cat containernames.txt`; do
    sudo docker restart "$container"
done

```

### updateProxies.sh Operations

Similarly, [`updateProxies.sh`](https://github.com/engageub/internetincome/blob/main/updateProxies.sh) references the same registry at line 4 to identify which containers require proxy reconfiguration. By reading [`containernames.txt`](https://github.com/engageub/internetincome/blob/main/containernames.txt), the script avoids applying network changes to containers that belong to other applications or previous failed runs.

## Practical Implementation Examples

When extending InternetIncome with new services, adhere to the established naming contract to maintain conflict protection.

### Adding a New Service Container

To launch a hypothetical "FooBar" service safely:

```bash

# Define prefix and validate uniqueness

FOOBAR_PREFIX="foobar"
check_container_exists ${FOOBAR_PREFIX}$UNIQUE_ID$i

# Launch with deterministic naming

sudo docker run -d \
  --name ${FOOBAR_PREFIX}$UNIQUE_ID$i \
  --restart=always \
  -e SOME_VAR=example \
  myrepo/foobar:latest

```

Calling `check_container_exists` before `docker run` guarantees uniqueness and records the name in [`containernames.txt`](https://github.com/engageub/internetincome/blob/main/containernames.txt) for automatic inclusion in restart and update workflows.

### Manual Cleanup of Stale Containers

If the script terminates unexpectedly before cleanup, remove all script-owned containers without affecting foreign ones:

```bash
while read -r name; do
  sudo docker rm -f "$name"
done < containernames.txt
rm -f containernames.txt

```

Because the list contains only names generated by the current execution, this operation is safe and surgical.

## Summary

- **InternetIncome** generates a 32-character hex `UNIQUE_ID` per execution at line 73 of [`internetIncome.sh`](https://github.com/engageub/internetincome/blob/main/internetIncome.sh) to ensure session isolation.
- Container names follow the pattern `<prefix><UNIQUE_ID><index>`, making them deterministic yet unique across runs.
- The `check_container_exists` function prevents collisions by inspecting Docker before launch and aborting if names exist (lines 126–131).
- Validated names are appended to [`containernames.txt`](https://github.com/engageub/internetincome/blob/main/containernames.txt), creating a runtime manifest used by [`restart.sh`](https://github.com/engageub/internetincome/blob/main/restart.sh) (line 114) and [`updateProxies.sh`](https://github.com/engageub/internetincome/blob/main/updateProxies.sh) (line 4).
- Parallel script executions are safe because each instance generates a distinct `UNIQUE_ID`, and the collision guard blocks manual overwrites.

## Frequently Asked Questions

### What happens if I run InternetIncome twice at the same time?

Each execution generates a different `UNIQUE_ID` from `/dev/urandom`, so container names will not overlap. Even if external factors cause a name collision, the `check_container_exists` function detects the conflict and aborts the second instance before it can overwrite existing containers.

### Where is the container name registry stored?

The file [`containernames.txt`](https://github.com/engageub/internetincome/blob/main/containernames.txt) in the working directory stores all names. It is defined at line 29 of [`internetIncome.sh`](https://github.com/engageub/internetincome/blob/main/internetIncome.sh) and is regenerated on each fresh start (removed during cleanup at line 1273). Helper scripts like [`restart.sh`](https://github.com/engageub/internetincome/blob/main/restart.sh) and [`updateProxies.sh`](https://github.com/engageub/internetincome/blob/main/updateProxies.sh) read this file to identify which containers to manage.

### How does the script prevent duplicate container names across different services?

The naming pattern combines a service-specific prefix (e.g., `honey`, `myst`) with the session-wide `UNIQUE_ID`. Because `check_container_exists` validates every name against Docker's internal state before creation, any attempt to reuse a name—even across different service types—triggers an immediate exit.

### Can I manually edit containernames.txt to add or remove containers?

Manual editing is not recommended. The file is an append-only registry managed exclusively by `check_container_exists` during the script's execution lifecycle. Altering it may cause [`restart.sh`](https://github.com/engageub/internetincome/blob/main/restart.sh) to target non-existent containers or skip valid ones during proxy updates.