starred/ntfy

Fork 0

mirror of https://github.com/binwiederhier/ntfy.git synced 2026-05-09 16:35:53 +02:00

internal server error #781

New issue

Closed

opened 2026-05-07 00:27:27 +02:00 by BreizhHardware · 7 comments

BreizhHardware commented

2026-05-07 00:27:27 +02:00

Owner

Originally created by @usbrpa on GitHub (May 17, 2024).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1110

Sorry if this is due to my ignorance, but I can't be sorting out a small issue:

I set up everything and ntfy is listening on ports 80 http and 444 https (have another server running using port 443 on same machine).

I can connect to both servers from the android app, no issue. Systemctl shows all correctly, running and listening to the right ports.

When I send a message from cli, form wherever, I get a message:

"{"code":50001,"http":500,"error":"internal server error"}"

If I disable http and only let https run, I get a message that I am trying to send a message to a https server.

Nevertheless, the notifications do work. I receive them in the app in both groups, the one connected to http as well as the one connected to https.

When only using http. I get a feedback after sending the command containing the sent message, which is kind of nice to have.

So everything works, but I can't get {"code":50001,"http":500,"error":"internal server error"} away.

Anyone would happen to have some hints?

Thank you !!!!

Originally created by @usbrpa on GitHub (May 17, 2024). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1110 Sorry if this is due to my ignorance, but I can't be sorting out a small issue: I set up everything and ntfy is listening on ports 80 http and 444 https (have another server running using port 443 on same machine). I can connect to both servers from the android app, no issue. Systemctl shows all correctly, running and listening to the right ports. When I send a message from cli, form wherever, I get a message: "{"code":50001,"http":500,"error":"internal server error"}" If I disable http and only let https run, I get a message that I am trying to send a message to a https server. Nevertheless, the notifications do work. I receive them in the app in both groups, the one connected to http as well as the one connected to https. When only using http. I get a feedback after sending the command containing the sent message, which is kind of nice to have. So everything works, but I can't get {"code":50001,"http":500,"error":"internal server error"} away. Anyone would happen to have some hints? Thank you !!!!

BreizhHardware

2026-05-07 00:27:27 +02:00

closed this issue
added the
question
label

BreizhHardware commented

2026-05-07 00:27:28 +02:00

Author

Owner

@wunter8 commented on GitHub (May 17, 2024):

Turn on logging in your server.yml file to see what's going on. "debug" is probably enough, but you could also do "trace"

@wunter8 commented on GitHub (May 17, 2024): Turn on logging in your server.yml file to see what's going on. "debug" is probably enough, but you could also do "trace"

BreizhHardware commented

2026-05-07 00:27:28 +02:00

Author

Owner

@usbrpa commented on GitHub (May 18, 2024):

Hi Wunter,

have done so. I see an error about writing permissions to a DB:

INFO Connection closed with HTTP 500 (ntfy error 50001) (error=attempt to write a readonly database, http_method=POST

ntfy.log

ntfyhttps.log

I also tried the same now only enabling https, commented out http. See log attached.

At the beginning I used to get a message that I was trying to send a message to a https server using http (with curl). This though disappeared.

Thanks.

@usbrpa commented on GitHub (May 18, 2024): Hi Wunter, have done so. I see an error about writing permissions to a DB: INFO Connection closed with HTTP 500 (ntfy error 50001) (error=attempt to write a readonly database, http_method=POST [ntfy.log](https://github.com/binwiederhier/ntfy/files/15360978/ntfy.log) [ntfyhttps.log](https://github.com/binwiederhier/ntfy/files/15361583/ntfyhttps.log) I also tried the same now only enabling https, commented out http. See log attached. At the beginning I used to get a message that I was trying to send a message to a https server using http (with curl). This though disappeared. Thanks.

BreizhHardware commented

2026-05-07 00:27:28 +02:00

Author

Owner

@usbrpa commented on GitHub (May 18, 2024):

Sorry, update:

I did comment out http, which was wrong. After putting http to "" instead of commenting it out, I get the following:

root@vps2432639:/var# curl -d "test" x.x.x.x/alerts
Client sent an HTTP request to an HTTPS server.

I also changed server.yml cache db entry to a different file name hoping it would be recreated, maybe with right permissions. Didn't work.

Thanks.

@usbrpa commented on GitHub (May 18, 2024): Sorry, update: I did comment out http, which was wrong. After putting http to "" instead of commenting it out, I get the following: root@vps2432639:/var# curl -d "test" x.x.x.x/alerts Client sent an HTTP request to an HTTPS server. I also changed server.yml cache db entry to a different file name hoping it would be recreated, maybe with right permissions. Didn't work. Thanks.

BreizhHardware commented

2026-05-07 00:27:28 +02:00

Author

Owner

@usbrpa commented on GitHub (May 18, 2024):

I guess I solved it doing a chown ntfy on the cache db file... is that a good thing?

:-)

@usbrpa commented on GitHub (May 18, 2024): I guess I solved it doing a chown ntfy on the cache db file... is that a good thing? :-)

BreizhHardware commented

2026-05-07 00:27:28 +02:00

Author

Owner

@wunter8 commented on GitHub (May 18, 2024):

It makes sense that chown on the cache.db file fixed things. You could still send and receive messages (as you saw) without a working cache.

Did you get the http and https stuff figured out? If so, I think we can probably close this!

@wunter8 commented on GitHub (May 18, 2024): It makes sense that chown on the cache.db file fixed things. You could still send and receive messages (as you saw) without a working cache. Did you get the http and https stuff figured out? If so, I think we can probably close this!

BreizhHardware commented

2026-05-07 00:27:28 +02:00

Author

Owner

@usbrpa commented on GitHub (May 18, 2024):

Yes, it can all be closed. I figured pretty much everything out, it really works like a charm. To be honest, one of the most useful discoveries I've made in years. In my case (home lab / hobby guy) I extremely appreciate being able to get notification from Cron when a job did run etc. I truthfully am delighted by this solution, and havn't explored even 1% of its capabilites. A big THANKS.

@usbrpa commented on GitHub (May 18, 2024): Yes, it can all be closed. I figured pretty much everything out, it really works like a charm. To be honest, one of the most useful discoveries I've made in years. In my case (home lab / hobby guy) I extremely appreciate being able to get notification from Cron when a job did run etc. I truthfully am delighted by this solution, and havn't explored even 1% of its capabilites. A big THANKS.

BreizhHardware commented

2026-05-07 00:27:29 +02:00

Author

Owner

@japharl commented on GitHub (Aug 29, 2024):

FWIW, I noticed the same error message. In my case, the server flipped the bit from read / write file system to read only. (Close ticket, but for others who search for the ticket, it could be another debugging technique to check.)

@japharl commented on GitHub (Aug 29, 2024): FWIW, I noticed the same error message. In my case, the server flipped the bit from read / write file system to read only. (Close ticket, but for others who search for the ticket, it could be another debugging technique to check.)

BreizhHardware referenced this issue

2026-05-07 01:02:01 +02:00

[PR #781] [MERGED] Correctly handle standalone (PWA) mode changes #1418