Thanks, but should there not be an if statement also? Or is it not needed? Like:
err := http.ListenAndServe(":5050", nil)
if err != nil {
fmt.Println("%v", err)
}
As I said, http.ListenAndServe will never return nil.
I have read at several Places that it’s a good idea do place the ListenAndSave in a log.Fatal like
log.Fatal(http.ListenAndServe( “:8080” , nil))
like noted here
As I said, whatever OP uses for logging
The Terminal does not receive any message from this. The server just shuts down silently.
There are other Go Web servers on this server that runs without any problem. Any Javascript that can cause this?
Any further tip?
I’m not sure how you manage your services. But I really don’t believe that it silently exits. And if it does, you need to check for its exit code, perhaps it gets killed by the system via a signal?
Have you checked systems log if OOM killer strikes?
Try one of the top answers “Finding which process was killed by Linux OOM killer - Stack Overflow” https://stackoverflow.com/questions/624857/finding-which-process-was-killed-by-linux-oom-killer
Debian 10 managed by Webmin. The var/log/message contained nothing but normal messages: rsyslogd was HUPed and var/log/stderr is empty.
There is no other process but http.Server running and it is terminated repeatedly by some reason. Either fmt.Println(err) or log.Fatal is reporting any issues. The memory used does not exceed 30 percent.
HTML, CSS and Javascript is validated. And other Go servers on the same server runs perfect on other ports.
I have activated the Firewall, but so far no difference.
Any clue how to find the cause?
I don’t know webmin, but fmt.Println prints to stdout. Not sure what webmin does with what happens on stdout.
Make sure to use whatever logging mechanism usually works for you.
Also make sure that all your endpoints properly log.
Extensive logging is probably the only thing that can help you debugging this.
Also, your service manager should be either able to recognize failure and restart your service, or if it can’t, then it should be replaced. Systemd is pretty good at just doing the right thing.
And again, when your service exits, what exit code does it have?
Terminated
Command failed with exit status 36608
How do I get this log to print to var/log/stderr ?
log.Fatal(http.ListenAndServe( *“:8080”* , nil))
That is a garbage value. Exit codes on linux are only 8 bit…
If though I look at its individual bytes, then we have 143 0.
If we assume that we can assume the 0 byte, we have an exitcode of 143, which on linux usually means “shut down by SIGTERM”.
The default that happens when you use kill $pid on a terminal. Now you need to find out what sends the SIGTERM and why.
Not sure what exactly you mean by that. But if its a file, then open it and write your logs to it. How to do that exactly depends on the logging library you use.
log.Fatal will always log to the processes stderr/fd:2 and then exit the program.
Systemd as well as docker usually take stdout and stderr of a program and write them into their logs, which you can then browse by service/container.
I have no clue how your webmin deals with such stuff.
And how do I read this log? var/log/stderr is empty
Again, I have no clue what webmin does. You need to figure out on your own, if it does persist the processes stdout and stderr somewhere.
It is a Debian thing.
-
First I created a main.exe
Go Playground - The Go Programming Language -
Then redirected to the var/log/messages in the terminal
./main 2>> /var/log/messages -
Last I executed the main
cd /logtest ./main
Aug 18 00:00:05 …rsyslogd was HUPed
Message
The question is how to do #2 (redirect to var/log/messages) from within Go?
Or even better redirect to stderr?
You could try something like this:
package main
import (
"log"
"os"
)
func main() {
// Create a new logger l for output to stderr.
// If you don't want the log date, change the flag from 1 to 0.
l := log.New(os.Stderr, "", 1)
// Some code to force an error.
file, err := os.Open("file.go") // For read access.
if err != nil {
// Output the error do stderr
l.Println(err)
}
_ = file // just to avoid errors at compile time
}
1 Like
Isn’t .exe a windows thing? I think the main program should be named main.go.
the main executable on Linux does not have a suffix AFAIK.
./main
Does dmesg show anything?
var/log/dmesg is empty…
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.