DEVONthink Server stops responding

In addition to @bluefrog pointing out the location in Help (same as in the “DEVONthink Handbook”) here is a screen shot. Lots more great info in the outstanding “DEVONthink Handbook” (same content in Help). “Right Mouse Click” on the selected sync location.

1 Like

Thanks for the information. I didn’t have any idea that was there, Ctrl + Option clicking sync locations to verify them thoroughly. For what it’s worth, the process ran to completion with the log window containing the message “Location successfully verified.” and nothing else.

Another possible data point. I begin to wonder if maybe the problem has something to do with the speed at which I type (which is prodigious, averaging 160+ WPM) and the fact that my default markdown note editing mode is “Side-by-Side”. I’ve been experiencing a lot more server-stops-responding problems this week, so I’ve been trying to pay more attention to what’s happening, and I’ve noticed a few more things that may be helpful.

First, there are occasional moments when I’ll notice that text entry just pauses. I can be in the middle of typing a sentence and the text going into the edit control (or whatever it is) just stops in mid-word. This can mean that the server has stopped responding, but a good fraction of the time it will continue working if I give it 5 - 10 seconds without typing anything else. Maybe I’m overrunning some kind of local buffer while the browser is hitting the remote server with/for something?

And second, a good indicator that the server is about to stop responding is that the preview portion of the side-by-side view starts flashing/refreshing more slowly. When it just stops refreshing altogether, I know that the server has stopped responding, and I can confirm that by opening a new tab or trying to access it from a different browser/machine. As I take notes today, I’m going to try to remember to set it to the “Source” view and see if that improves matters. If so, I’ll post again.

Thanks for the added information.
So you’re editing the entries in the websharing UI in a browser on a PC, correct?

Yes, probably 95% of the time. That’s exactly what I’ve been doing today, for example. I’ve been using Firefox today so far.

Stopped working again today. I’m at the house, and I can see the computer is on and working just fine. No evidence of network issues. I can connect to it via SSH, via Jump Desktop, and DEVONthink is up and running with seemingly no issues as well. I just can’t connect at all via a web browser from any machine/device I have in the house. Any ideas for me to troubleshoot this while it’s in this state?

Is the web server running? And what does the activity monitor on the server machine tell you about the running (or not) processes? Can you run wireshark on one of the client machines and see what happens when this machine tries to talk to your server via HTTP(S)?

What’s the name of the web server process? Maybe I’m missing it, but it’s not obvious to me. I’m attaching the results of a “ps -ax” command to this reply and will take a look at Wireshark next.

RunningProcesses.txt.zip (15.4 KB)

sudo lsof -nP -i4TCP:80 | grep LISTEN
for HTTP. Use 443 instead of 80 for HTTPS.

I believe 80 should be the port specified or chosen by DEVONthink, e.g., 65531 in my case.

Right. I just assumed that the server would be listening at 80 or 443. But in any case: the process name seems to be DEVONthin … and it should be easily identifiable with the PID just following it (2822 here).

Thanks for that tip. I didn’t know about that on the macOS. When I run the command with the proper port number (55000 in my case), I get:

DEVONthin 32458 john 184u IPv4 0x825315e685b279ed 0t0 TCP *:55000 (LISTEN)

Does that confirm the server is up and running properly?

No. But it does tell you that the server once opened this port and it also tells you the process id (32458). Given that piece of information, you should be able to look it up in the activity monitor and run the diagnostics available there.

You may also run
echo -n "GET / HTTP/1.0\r\n\r\n" | nc <ip address> 55000 from one of your clients. That should return an HTTP 1 header if the server is up and running.

1 Like

Ok, two more pieces of data. First, I’m attaching the zipped logs from WireShark. For the record, I set the filter to monitor all traffic on port 55000, then opened a new tab in Firefox that tries to talk directly to DEVONthink on the local iMac on that port, captured until the Firefox browser showed a timeout, and then saved that data. I’m no expert at WireShark, but it sure looks to me like DEVONthink has simply stopped responding.

2022-10-05 1118 DEVONthink Web Access Failure.pcapng.zip (1.3 KB)

Second, when I try the command you suggested at the terminal from my MacBook Pro (which can successfully ping the machine, connect and control it via Jump Desktop, connect and control it successfully via SSH, etc.), this is what I get:

jwilliston@mbp-jwilliston:~$ echo -n “GET / HTTP/1.0\r\n\r\n” | nc 192.168.26.81 55000
jwilliston@mbp-jwilliston:~$

It sits there showing nothing for maybe half a minute or so and then ends without any output. Again, it sure looks to me like DEVONthink has stopped responding. Any other diagnostics worth running?

Are you able to use a browser on the same machine in case of this issue or does this always fail too?

Exactly. There may be a server sitting there and thinking it’s listening on 50000 but it does not even accept the first call to establish a TCP connection. Which explains why the nc experiment fails, too. So something has gone awry on the server itself.

Bonjour actually handles TCP/IP, the server adds only HTTP(S). Might be just another weird case of Bonjour hiccup.

From what I gathered, Bonjour is running on top of UDP and TCP. I don’t really see how it can “handle” TCP/IP given that it’s limited to the same subnet. As opposed to TCP, of course.

Anyway, in the end it’s not DEVONthink’s server.

I find that difficult to ascertain. The server seems to be listening on port 50000 but it’s not responding to TCP SYN requests. So something is amiss in the server process. Not necessarily its code proper. But maybe the socket has gone “stale” (for lack of a better word) and the server should close/reopen it?