temporary build folder in /tmp not deleted

[dhax]

After a normal "go run ." the temporary linux folder in /tmp/go-build123123 gets deleted again when the program stops. But the way "htmgo run" exits by killing the process seems to prevent the deletion of this temporary folder and in "htmgo watch" mode this happens on every save, leaving an orphaned build folder back... totally filled up my /tmp over a day ;)

As a quick fix replacing SIGKILL with SIGINT in pid_unix.go restores folder deletion.

[maddalax]

Thanks, I'll take a look tomorrow. I am a little worried that SIGINT will affect hot reload speed since it has to wait for the process to fully stop, which generally I don't care that much about in dev. I'll speed test that or maybe try something else like have htmgo run use a specific out dir that just keeps overwritten instead of temp

[maddalax]

Should be fixed in this release.

https://github.com/maddalax/htmgo/releases/tag/cli%2Fhtmgo%2F1.0.6

to update your CLI, run:

GOPROXY=direct go install github.com/maddalax/htmgo/cli/htmgo@latest

I ended up just making it so the output dir is consistent and it gets cleaned up each time.

[dhax]

Thanks, that should work fine.
Also wanted to mention that sometimes on reload I experience a complete firefox browser crash and think it might be triggered by the restart logic for ListenAndServe

htmgo/framework/h/app.go

Line 260 in d555e53

cmd := exec.Command("bash", "-c", fmt.Sprintf("kill -9 $(lsof -ti%s)", port))

Maybe the app shouldn't try to kill processes itself and leave that to the runner and watcher.

[maddalax]

When you experience the crash, are you manually doing the reload or are you waiting for the live reload to refresh the page automatically?

[dhax]

I only save the file and wait for the auto  reload to happen. I see the log from the above mentioned code line so this only seems to happen when the process gets killed that way, but that is just a guess, I can try to reproduce maybe. 27.01.2025 14:18:39 maddalax ***@***.***>:

…

When you experience the crash, are you manually doing the reload or are you waiting for the live reload to refresh the page automatically? — Reply to this email directly, view it on GitHub[#95 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AANIQCEI6TN7JUEUTB2OOML2MYW2LAVCNFSM6AAAAABVV7KP2OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJVG42DCOBRGY]. You are receiving this because you authored the thread. [Verfolgungsbild][https://github.com/notifications/beacon/AANIQCDK4XMSQWNEEHKQDD32MYW2LA5CNFSM6AAAAABVV7KP2OWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTU35EGXQ.gif]

[dhax]

so it's basically reproducible by having 'htmgo run' in a terminal, open browser (here firefox) to connect to the livereloading endpoint and start 'htmgo watch' in another terminal. That's about the same situation when the process sometimes could not be killed/restarted properly. It happens only randomly, maybe every 30 to 50 saves though...

[maddalax]

Oh you are running htmgo run and htmgo watch at the same time? You should only need to run one or the other.

htmgo watch is just htmgo run but auto restarts it when you make a change

or were you just running it that way to try to reproduce just now?

[dhax]

No no, only running htmgo watch. But that way you can reproduce the browser crash. 27.01.2025 19:33:24 maddalax ***@***.***>:

…

Oh you are running htmgo run and htmgo watch at the same time? You should only need to run one or the other. htmgo watch is just htmgo run but auto restarts it when you make a change — Reply to this email directly, view it on GitHub[#95 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AANIQCDFZISCLEDCA3EZ5OD2MZ3WVAVCNFSM6AAAAABVV7KP2OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJWGU4TGOBVGI]. You are receiving this because you authored the thread. [Verfolgungsbild][https://github.com/notifications/beacon/AANIQCDRGBXH2RZ3SBMTYDD2MZ3WVA5CNFSM6AAAAABVV7KP2OWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTU36YG3Y.gif]

[maddalax]

Got it, I'll see if I can figure out what is going on.

The main reason I have the app restarting itself is sometimes the port taken even after killing the old app process and all its children (likely due to the force kill), and the only way I could ensure I open the port back up is to kill the app if it fails to startup on the specified port

since the port can really be anything, the watcher doesn't know what port the server runs on, therefore the server has to handle the reload