`--log-file` is overwritten by default

[9999years]

I have $PC_LOG_FILE set to write process-compose logs to a file.

This works well, except that process-compose truncates the file when opening it by default.

I'll usually run process-compose --detached, which logs to the file correctly, but then if I run process-compose list --output wide, it will overwrite the log file, which often contains useful data!

E.g. here's the whole log file, missing previous data:

$ command cat .pc/logs/process-compose.log
25-04-02 11:51:41.514 INF Process Compose v1.46.0

[9999years]

Workaround:

When starting process-compose, use process-compose --detached --log-file .pc/logs/process-compose.log.

Set PC_LOG_FILE=.pc/logs/process-compose-client.log.

Then, process-compose logs will go to process-compose.log, and not be reset unless you re-up process-compose (not sure if this causes logs to be lost after a no-op startup), and other process-compose commands will log to process-compose-client.log.

[joeblew999]

Good tip . Found this to be a problem too

[F1bonacc1]

Hey @9999years,

Thanks for letting me know. That sounds like a bug, but I double-checked in the code, and it looks like list and ls are correctly markerd as client commands here:

process-compose/src/config/config.go

Line 46 in f87744d

"list",

I also tried reconstructing that with list, and the log wasn't truncated. Maybe it is truncated with a different command than list?

[9999years]

@F1bonacc1 Ah, interesting! I want to keep the logs within the repository, so I have the PC_LOG_FILE environment variable set in my shell to point to a path within the repository. Therefore, it always uses the same path regardless of whether or not I'm running a client command.

Maybe we could add a PC_CLIENT_LOG_FILE variable? Seems a little clumsy though...

Here, if the PC_LOG_FILE variable is set, the function returns and doesn't get to the bit where it checks if it's running a client command:

process-compose/src/config/config.go

Lines 53 to 56 in f87744d

	val, found := os.LookupEnv(LogPathEnvVarName)
	if found {
	return val
	}

[F1bonacc1]

Yes, that's the issue!
If it runs in the same shell, it will affect both the client and the server.
I don't feel comfortable overriding something that was set by the user by adding the -client suffix.
On one hand, it creates confusion, so it sounds like an issue; on the other it works as expected.
All the solutions I can think of feel off:

1. Another env variable for the client (thanks for the suggestion).
2. --add-pid-to-log flag that will suffix the log file with the process PID (or time).
3. Document the issue
4. If the env variable is used for the client, add a warning to the log that if it runs from the same shell, the server log will be overwritten.

I am, of course, open to more suggestions and will think more about other options.

[9999years]

Sounds good. This issue isn't very urgent (the workaround posted above works well), so I'd be fine just documenting it.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs.