I was experimenting with running a Bash script with fcgiwrap. After booting the server, the very first request to my script (gemini://localhost/testscript.sh) succeeds, and outputs as expected. Any subsequent requests, however, fail. Restarting twins resets it; the first CGI request after restarting will succeed, and then every subsequent request fails.
This happens when reloading the same script and when trying to access a different script. It also occurs regardless of the language used for the script (I tried a Python script as well).
I have also confirmed that this is not a problem with fcgiwrap by testing with the nginx configuration from this website. Everything worked as expected with nginx.
I was experimenting with running a Bash script with fcgiwrap. After booting the server, the very first request to my script (`gemini://localhost/testscript.sh`) succeeds, and outputs as expected. Any subsequent requests, however, fail. Restarting twins resets it; the first CGI request after restarting will succeed, and then every subsequent request fails.
This happens when reloading the same script and when trying to access a different script. It also occurs regardless of the language used for the script (I tried a Python script as well).
I have also confirmed that this is not a problem with fcgiwrap by testing with the nginx configuration from [this website](https://nassif-haynes.com/3/). Everything worked as expected with nginx.
My twins test configuration:
```
listen: localhost:1965
hosts:
localhost:
cert: /home/skylar/software/twins/localhost.crt
key: /home/skylar/software/twins/localhost.key
paths:
-
path: /
root: /home/skylar/software/cgi-test
fastcgi: unix:/var/run/fcgiwrap.socket
```
And the script `testscript.sh`:
```
#!/bin/bash
echo 'Content-type: text/plain'
echo ''
echo "$(printenv)"
```
The second request never prints a log. Any subsequent request never prints a log. But the process is still running and has to be killed with ^C. No extra debug information is printed either (I tried both --debug and -debug)
There's not much to show
```
$ ./twins -debug -config ./config.yaml
localhost:1965 - - - [2022-05-25 00:42:25] "GET /testscript2.sh Gemini" 20 - 0.0309
^C
```
The second request never prints a log. *Any* subsequent request never prints a log. But the process is still running and has to be killed with `^C`. No extra debug information is printed either (I tried both `--debug` and `-debug`)
I'm still looking into this, but if you dont mind the content type being Gemini instead of plain text, you can simply use the command directive instead, and point it directly to the bash script.
I'm still looking into this, but if you dont mind the content type being Gemini instead of plain text, you can simply use the `command` directive instead, and point it directly to the bash script.
I was experimenting with running a Bash script with fcgiwrap. After booting the server, the very first request to my script (
gemini://localhost/testscript.sh
) succeeds, and outputs as expected. Any subsequent requests, however, fail. Restarting twins resets it; the first CGI request after restarting will succeed, and then every subsequent request fails.This happens when reloading the same script and when trying to access a different script. It also occurs regardless of the language used for the script (I tried a Python script as well).
I have also confirmed that this is not a problem with fcgiwrap by testing with the nginx configuration from this website. Everything worked as expected with nginx.
My twins test configuration:
And the script
testscript.sh
:Please run twins with --debug and share the output (including both requests).
There's not much to show
The second request never prints a log. Any subsequent request never prints a log. But the process is still running and has to be killed with
^C
. No extra debug information is printed either (I tried both--debug
and-debug
)Thanks. Seems like a deadlock. I will look into this and get back to you.
I'm still looking into this, but if you dont mind the content type being Gemini instead of plain text, you can simply use the
command
directive instead, and point it directly to the bash script.