`tail` command fails with certain program names

[jeff-minard-ck]

I experienced this problem:

==> Press Ctrl-C to exit <==
http://127.0.0.1:9001/logtail/mbus0:0/stdout Cannot read, status code 410

When I removed the process_name=%(process_num)s directive for that program, the process name became simpler and the tail command now works. I am guessing that it's failing due to the : character. URL encoding at some point in the chain has been left out perhaps?

[jeff-minard-ck]

Possibly related: while this bug was in occurring, I also wasn't getting any output in the log files I'd setup using the stdout_logfile and stderr_logfile directives.

[hidde-jan]

I ran into the same issue. However, my name was simply match_production. Changing the name had no influence.

[WuTheFWasThat]

I am having this issue as well, and the name contains no colons

[NoUsername]

same issue, any hints on what causes this and/or how this can be solved?

[fsboehme]

same issue. i'm doing the same thing as the poster of this (from 2009!): http://plope.com/software/collector/277

I was thinking of invoking supervisord every hour from cron, since something kills it on my system.
If supervisord is running, and you run supervisord again, it correctly fails to start. However supervisorctl sessions to the existing one no longer work:

$ supervisorctl tail -f squeaktrunkbot
unix:///tmp/supervisor.sock/logtail/squeaktrunkbot/stdout Cannot read, status code 410

any suggestions?

[DSoftwareArtist]

I also got same issue.

[mnaberez]

From the original report:

When I removed the process_name=%(process_num)s directive for that program, the process name became simpler and the tail command now works. I am guessing that it's failing due to the : character. URL encoding at some point in the chain has been left out perhaps?

The character : was disallowed in 3335519 for a different reason a few months after this report. Supervisor 3.0 won't let you have this character in the process name.

For other users seeing Cannot read, status code 410: this can also occur if the log file for the process doesn't exist on disk, which is the intended behavior.