Unix socket not accessible when using --detached mode

[schickling]

Unix socket not accessible when using --detached mode

Description

When starting process-compose with Unix socket mode (-U) and detached mode (--detached), the socket file appears to be created but is not accessible for client commands like process list.

Environment

• Process Compose Version: v1.64.1
• OS: Linux 6.1.35
• Platform: linux

Steps to Reproduce

1. Start process-compose with Unix socket and detached mode:

process-compose -U -u .process-compose.sock up -t=false --detached

2. Verify the socket file exists:

ls -la .process-compose.sock
# Output: srwxr-xr-x 1 user users 0 Jul  5 15:22 .process-compose.sock

3. Try to list processes:

process-compose -u .process-compose.sock process list

Expected Behavior

The process list command should connect to the Unix socket and return the list of running processes.

Actual Behavior

The command fails with:

FTL failed to list processes error="Get \"http://unix/processes\": dial unix .process-compose.sock: connect: no such file or directory"

Even though:

• The socket file exists on the filesystem
• The process-compose process is running
• lsof shows the process has the socket open

Additional Information

• The same issue occurs whether using -U alone or -U -u <path>
• When running without --detached (just backgrounded with &), the socket still has the same issue
• All managed processes (defined in process-compose.yaml) are running correctly
• This happens consistently across multiple attempts

Workarounds Attempted

1. Using explicit socket path with -u
2. Running without --detached flag
3. Setting PC_SOCKET_PATH environment variable

None of these resolved the socket communication issue.

Question

Is this a known limitation, a bug, or are we using the Unix socket feature incorrectly? The documentation suggests Unix sockets should work as a drop-in replacement for TCP mode, but we're unable to get client commands working with it.

Any guidance would be appreciated!

[schickling]

Update: Attach command causes panic

When trying to use process-compose attach, the program crashes with a nil pointer dereference:

panic: runtime error: invalid memory address or nil pointer dereference [recovered]
        panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0xb88f4a]

goroutine 1 [running]:
github.com/rivo/tview.(*Application).Run.func1()
        github.com/rivo/tview@v0.0.0-20250330220935-949945f8d922/application.go:297 +0x45
panic({0xd431a0?, 0x1e2b6a0?})
        runtime/panic.go:792 +0x132
github.com/gorilla/websocket.(*Conn).WriteMessage(0xc0011f8b36?, 0x0?, {0xc00114705a, 0x2, 0x2})
        github.com/gorilla/websocket@v1.5.3/conn.go:760 +0x2a
github.com/f1bonacc1/process-compose/src/client.(*LogClient).CloseChannel(0xc000800460)
        github.com/f1bonacc1/process-compose/src/client/logs.go:64 +0x56

The crash occurs in the WebSocket connection handling, suggesting the connection pointer is nil when trying to write a message.

This happens consistently when:

1. Starting process-compose with TCP mode: process-compose -p 8377 up -t=false
2. Trying to attach: process-compose -p 8377 attach

The processes are running fine, but the attach functionality is broken.

[schickling]

Resolution: Using --no-server flag

After further investigation, we found that the root cause of our issues was port conflicts between process-compose's HTTP server (default port 8080) and our application.

The simplest solution is to use the --no-server flag:

process-compose --no-server up -t=false

This eliminates:

• Port conflict issues
• The WebSocket crash when using attach
• Complex port allocation logic
• Unix socket issues

While it would still be nice to have working Unix sockets for management, the --no-server approach is much simpler and works reliably. The processes run fine and can be monitored through log files.

Perhaps the documentation could highlight this option for users who don't need the HTTP/WebSocket management interface.

[schickling]

Update: Closing issue

After further investigation, we've decided to work with the current limitations rather than trying to fix them. Our approach:

1. Simple pc-socket wrapper that starts process-compose with -U flag
2. Documented known issues in our README and internal docs
3. Workarounds for common problems (checking processes directly, using log files instead of attach)

While it would be nice to have reliable Unix socket communication and a working attach command, we can work around these issues for now. The processes run fine, which is what matters most.

Feel free to close this issue or keep it open for tracking. We'll revisit if these become blocking issues in the future.

[liaowang11]

I'm getting the same SIGSEGV error when trying to attach to process compose, and i don't think it's a port conflicts as 8080 is not used by any other applications on my machine. It would be nice to have a fix for this.
Version: v1.64.1

❯ process-compose attach
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
        panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x10 pc=0x104aba654]

goroutine 1 [running]:
github.com/rivo/tview.(*Application).Run.func1()
        github.com/rivo/tview@v0.0.0-20250330220935-949945f8d922/application.go:297 +0x4c
panic({0x104dbbe80?, 0x105cd38b0?})
        runtime/panic.go:792 +0x124
github.com/gorilla/websocket.(*Conn).WriteMessage(0x140000ef2c0?, 0x140000ef2c0?, {0x1400113992a, 0x2, 0x2})
        github.com/gorilla/websocket@v1.5.3/conn.go:760 +0x24
github.com/f1bonacc1/process-compose/src/client.(*LogClient).CloseChannel(0x14000274500)
        github.com/f1bonacc1/process-compose/src/client/logs.go:64 +0x60
github.com/f1bonacc1/process-compose/src/client.(*PcClient).UnSubscribeLogger(0x7?, {0x140002d07f7?, 0x7?}, {0x140002d0980?, 0x7?})
        github.com/f1bonacc1/process-compose/src/client/client.go:87 +0x20
github.com/f1bonacc1/process-compose/src/tui.(*pcView).unFollowLog(0x140000f7d40)
        github.com/f1bonacc1/process-compose/src/tui/log-operations.go:73 +0x48
github.com/f1bonacc1/process-compose/src/tui.(*pcView).onTableSelectionChange(0x140000f7d40, 0x10447f848?, 0x104485330?)
        github.com/f1bonacc1/process-compose/src/tui/proc-table.go:161 +0x94
github.com/rivo/tview.(*Table).InputHandler.func1(0x14001102da0, 0x104af5140?)
        github.com/rivo/tview@v0.0.0-20250330220935-949945f8d922/table.go:1684 +0x890
github.com/rivo/tview.(*Table).InputHandler.(*Box).WrapInputHandler.func2(0x14000666000?, 0x1400111d880?)
        github.com/rivo/tview@v0.0.0-20250330220935-949945f8d922/box.go:167 +0x54
github.com/rivo/tview.(*Grid).InputHandler.func1(0x14001102da0, 0x1400111d880)
        github.com/rivo/tview@v0.0.0-20250330220935-949945f8d922/grid.go:664 +0x21c
github.com/rivo/tview.(*Grid).InputHandler.(*Box).WrapInputHandler.func2(0x14000190f30?, 0x1400111d880?)
        github.com/rivo/tview@v0.0.0-20250330220935-949945f8d922/box.go:167 +0x54
github.com/rivo/tview.(*Pages).InputHandler.func1(0x14001102da0, 0x1400111d880)
        github.com/rivo/tview@v0.0.0-20250330220935-949945f8d922/pages.go:323 +0xa8
github.com/rivo/tview.(*Pages).InputHandler.(*Box).WrapInputHandler.func2(0x140006164e0?, 0x14000077938?)
        github.com/rivo/tview@v0.0.0-20250330220935-949945f8d922/box.go:167 +0x54
github.com/rivo/tview.(*Application).Run(0x1400018e2a0)
        github.com/rivo/tview@v0.0.0-20250330220935-949945f8d922/application.go:416 +0x83c
github.com/f1bonacc1/process-compose/src/tui.RunTUI({0x104ec5858?, 0x140002744b0?}, {0x140002caaf0?, 0x0?, 0x104dab420?})
        github.com/f1bonacc1/process-compose/src/tui/view.go:598 +0x38
github.com/f1bonacc1/process-compose/src/cmd.startTui({0x104ec5858, 0x140002744b0}, 0x0)
        github.com/f1bonacc1/process-compose/src/cmd/project_runner.go:140 +0x55c
github.com/f1bonacc1/process-compose/src/cmd.init.func1(0x105ce8f40?, {0x104b8a395?, 0x4?, 0x104b8a3dd?})
        github.com/f1bonacc1/process-compose/src/cmd/attach.go:12 +0x30
github.com/spf13/cobra.(*Command).execute(0x105ce8f40, {0x105d2f460, 0x0, 0x0})
        github.com/spf13/cobra@v1.9.1/command.go:1019 +0x82c
github.com/spf13/cobra.(*Command).ExecuteC(0x105ceb040)
        github.com/spf13/cobra@v1.9.1/command.go:1148 +0x384
github.com/spf13/cobra.(*Command).Execute(...)
        github.com/spf13/cobra@v1.9.1/command.go:1071
github.com/f1bonacc1/process-compose/src/cmd.Execute()
        github.com/f1bonacc1/process-compose/src/cmd/root.go:71 +0x24
main.main()
        github.com/f1bonacc1/process-compose/src/main.go:8 +0x1c

[F1bonacc1]

Hey @schickling, @liaowang11,

Thanks for filing thin issue.
I tried to reproduce it following the steps you provided, but after many tried it works as expected for me:

Does it happen all the time?
Is there anything else you recommend trying to reproduce it?

[liaowang11]

Yes, it happens all the time. Here this way to reproduce under version 1.64.1:

❯ /nix/store/1f768ii5k8l0w31g4xijjpiwn86jxymf-process-compose-1.64.1/bin/process-compose version
Process Compose
Version:        v1.64.1
Commit:         d1fd7c3
Date (UTC):     2025-05-10T16:18:23Z
License:        Apache-2.0
Discord:        https://discord.gg/S4xgmRSHdC

Written by Eugene Berger

The process compose file used:

❯ cat process-compose.yaml
is_strict: true
processes:
  sleep1:
    availability:
      restart: on_failure
    command: exec sleep 100
  sleep2:
    availability:
      restart: on_failure
    command: exec sleep 100
version: '0.5'

❯ /nix/store/1f768ii5k8l0w31g4xijjpiwn86jxymf-process-compose-1.64.1/bin/process-compose --config process-compose.yaml --unix-socket pc.sock up -D
Starting Process Compose in detached mode. Use 'process-compose attach' to connect to it or 'process-compose down' to stop it
❯ /nix/store/1f768ii5k8l0w31g4xijjpiwn86jxymf-process-compose-1.64.1/bin/process-compose --unix-socket pc.sock attach
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
        panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x10 pc=0x102b36804]

I have noticed that if I don't press any key the crash will not be triggered. Happy to supply any more information if needed.
Thanks for your work.

[F1bonacc1]

Hi @liaowang11,

Thank you for your quick response and the detailed repro steps.
I tried them, but the result is the same for me:

Please try with v1.73.0 and let me know if it fixes the issue for you.

[liaowang11]

I think I find the culprit. If I configure http proxy in my shell, there will be the crash, while turning off fix the issue.
But I don't understand why it's related.

[F1bonacc1]

Thank you for this lead @liaowang11
I managed to reproduce it with a dummy proxy in my shell:

export HTTP_PROXY=http://localhost:3128

I fixed the crash, but of course there are no logs in this case.
Can you please define:

export NO_PROXY="$NO_PROXY,unix"

And let me know if it works?

[liaowang11]

Thank you for this lead @liaowang11 I managed to reproduce it with a dummy proxy in my shell:

export HTTP_PROXY=http://localhost:3128
I fixed the crash, but of course there are no logs in this case. Can you please define:

export NO_PROXY="$NO_PROXY,unix"
And let me know if it works?

Am I supposed to build the latest version and try this?

[F1bonacc1]

Am I supposed to build the latest version and try this?

No, no. Just define this variable, and it should work:

export NO_PROXY="$NO_PROXY,unix"

The crash fix will be part of the next release. But with the above env the PC shouldn't crash for you anymore.

[liaowang11]

Am I supposed to build the latest version and try this?

No, no. Just define this variable, and it should work:

export NO_PROXY="$NO_PROXY,unix"
The crash fix will be part of the next release. But with the above env the PC shouldn't crash for you anymore.

Oh sure. I tested and it works. Thanks for your help.

[schickling]

I can confirm this issue is still reproducible in v1.64.1. Here are detailed reproduction steps:

Environment

• OS: Linux 6.1.35 Bridge from docker-compose #1-NixOS SMP PREEMPT_DYNAMIC (x86_64)
• Terminal: xterm-256color
• Go version: go1.24.5 linux/amd64
• Process Compose version: v1.64.1 (commit: d1fd7c3, built: 2025-05-10T16:18:23Z)

Minimal Reproduction

1. Configuration file (process-compose.yaml)

version: "0.5"
http_server:
  port: 8081
processes:
  test-process:
    command: "sleep 30"
    restart: always
    
  another-process:
    command: "echo 'Hello from process 2' && sleep 60"
    restart: always

2. Start process-compose

process-compose up --tui=false -p 8082

(Note: Using --tui=false to avoid TUI startup issues, and custom port to avoid conflicts)

3. Attempt to attach (in another terminal)

process-compose attach test-process -p 8082

4. Result - Consistent Panic

panic: close of nil channel

goroutine 1 [running]:
github.com/gdamore/tcell/v2.(*tScreen).finish(...)
	github.com/gdamore/tcell/v2@v2.8.1/tscreen.go:683
sync.(*Once).doSlow(0xc0002232e8?, 0xc000013680?)
	sync/once.go:78 +0xab
sync.(*Once).Do(...)
	sync/once.go:69
github.com/gdamore/tcell/v2.(*tScreen).Fini(0x5?)
	github.com/gdamore/tcell/v2@v2.8.1/tscreen.go:679 +0x3b
github.com/rivo/tview.(*Application).Stop(0xc0001bc2a0)
	github.com/rivo/tview@v0.0.0-20250330220935-949945f8d922/application.go:607 +0x8a
github.com/f1bonacc1/process-compose/src/tui.(*pcView).handleShutDown(0xc000229a00)
	github.com/f1bonacc1/process-compose/src/tui/view.go:408 +0x9a
github.com/f1bonacc1/process-compose/src/tui.RunTUI({0xfbdf38?, 0xc0000344b0?}, {0xc000222fc0?, 0x1e55d60?, 0xd32680?})
	github.com/f1bonacc1/process-compose/src/tui/view.go:600 +0x91
github.com/f1bonacc1/process-compose/src/cmd.startTui({0xfbdf38, 0xc0000344b0}, 0x0)
	github.com/f1bonacc1/process-compose/src/cmd/project_runner.go:140 +0x63d
github.com/f1bonacc1/process-compose/src/cmd.init.func1(0x1e41040?, {0xe3a4c9?, 0x4?, 0xe3a511?})
	github.com/f1bonacc1/process-compose/src/cmd/attach.go:12 +0x25
github.com/spf13/cobra.(*Command).execute(0x1e41040, {0xc0002b2a80, 0x3, 0x3})
	github.com/spf13/cobra@v1.9.1/command.go:1019 +0xa91
github.com/spf13/cobra.(*Command).ExecuteC(0x1e43140)
	github.com/spf13/cobra@v1.9.1/command.go:1148 +0x46f
github.com/spf13/cobra.(*Command).Execute(...)
	github.com/spf13/cobra@v1.9.1/command.go:1071
github.com/f1bonacc1/process-compose/src/cmd.Execute()
	github.com/f1bonacc1/process-compose/src/cmd/root.go:71 +0x1a
main.main()
	github.com/f1bonacc1/process-compose/src/main.go:8 +0xf

Key Observations

1. 100% reproducible: Every attempt to use attach command results in this panic
2. Affects all processes: Both test-process and another-process cause the same panic
3. TUI-related: The panic occurs in the TUI shutdown code path (tScreen.finish())
4. Race condition: Appears to be a nil channel being closed during TUI cleanup

Analysis

The issue is in the TUI cleanup sequence. Looking at the stack trace:

• attach.go:12 calls startTui()
• project_runner.go:140 calls RunTUI()
• view.go:600 calls handleShutDown()
• view.go:408 calls tview.Application.Stop()
• application.go:607 calls tScreen.Fini()
• tscreen.go:679 calls tScreen.finish()
• PANIC at tscreen.go:683 trying to close a nil channel

The root cause seems to be that the TUI is being torn down before it's fully initialized, or there's improper synchronization in the channel lifecycle management.

Workaround

Currently, there's no workaround for the attach command. Users must rely on:

• Log file monitoring (tail -f process-compose.log)
• Direct process inspection (ps aux | grep <process>)
• HTTP API endpoints (if accessible)

This significantly impacts the debugging experience for process-compose users.

@eugene-berger Would you like me to provide any additional debugging information or test specific scenarios?