HFS needs restart

[adam]

We're successfully using HFS for years. Lately we started to have problems: after a while (hours or days) HFS stops answering HTTP requests, restarting it from the menu (or F4 + F4) solves the problem.

I'm not a network expert, but I did some basic checks:
– HFS does answer if I connect locally as localhost, but doesn't answer if I connect locally as from the IP of the local network interface;
– TcpView shows the connection in LISTENING state, and this looks identical after restart;
– the only suspicious thing in TcpView is that about 10 connections are in CloseWait state;
– turning off the firewall doesn't help (and HFS is let through anyway);
– turning off the Defender doesn't help;
– sometimes it shows banning, but other times it doesn't, I don't think that's the problem.

I tried upgrading to the 2.4.0. RC7, that is even worse than the old 2.3 (failing on almost daily basis, while the old one failed on weekly basis).

Any ideas what else to check?

[LeoNeeson]

Hi, and welcome to the forum...

Have you tried disabling 'power saving' (or something similar) on your network adapter to avoid getting idle?. I've read that some network adapters would not reconnect after returning from sleep, and/or that they could enter on idle mode without you even noticing it (check HERE and HERE, for a possible solution).

Perhaps is as easy as that (since you were 'successfully using HFS for years', it could happen that some 'Windows Update' changed some networking setting).

Hope it helps.
Leo.-

[adam]

Hi Leo,

Thanks for the suggestion. However, unfortunately the problem must be elsewhere: this is our server computer, all the other services (such as FTP, TeamViewer, invoicing, building heating, files) work seamlessly, HFS is the only one which fails on almost daily basis, and with F4+F4 it continues working.

Let me know if you have any other ideas. I'd be glad to supply logs, but the default on-screen log certainly doesn't show anything (the last log is about the last downloaded file).

[LeoNeeson]

I've found a very similar report from 2004, where no solution was found, but as ‘workaround’ it seemed that using a non-standard port, other higher than port 80, it could help on those cases.

» Just wondering: besides upgrading from HFS 2.3 to 2.4, try to think what other changes you did on your server. Since HFS worked fine for years, there must be something else that suddenly is causing this (like for example, an incompatibility with another software, or some other change). It's known that some applications like Skype, could 'take over' (or grab) port 80/443, thus blocking the normal functioning of HFS, as you can read HERE. In Windows 10, an "IIS service" is enabled by default (or it could have been re-enabled after a Windows Update), and it could cause the same issue, as you can read HERE.

• Besides that, if you wish, you can share a debug log by uploading it as attachment here on the forum. To get a debug log, follow THESE steps, but on step 4 wait until HFS stop responding, and then continue with step 5 onwards. I can't make any promises or guarantee about fixing this (this only could be useful to find the origin of the issue, or find a possible workaround, but most of the time, it is not enough to find the source of the error). Remember that without having an EXACT way to reproduce this bug, this could be hard to fix.

At the moment, since Rejetto stopped developing HFS v2.x (now considered obsolete by him), and until an independent fork of the old HFS v2.x branch doesn't arise, I would highly recommend testing his new HFS v3.

[adam]

Hi Leo,

I updated to 2.4 only after 2.3 started to have problems, after years of working seamlessly without any change on our end. I believe the reason was rather that spiders started to download thousands of files daily, and I guess HFS crashed due to the large number of downloads (possibly a memory leak or something similar).

Regarding 3.0: I installed this, it is a nice stuff (the remote HTTP admin is particularly useful, as well as the HTTPS), What is a bit unclear is whether that PowerShell window can be made to run in the background (a system tray icon was nicer for 2.x), and not to open the browser on each startup.

Let's see whether 3.0 will have the same problems or not...

[rejetto]

see if this can workaround your problem with HFS 2
https://rejetto.com/forum/index.php?topic=9577.msg1054784#msg1054784

for HFS 3, "browser at startup" is an option you can disable.
The "powershell window" can be avoided by turning hfs into a Service, or using a utility like this https://github.com/benbuck/rbtray
The Service is the right choice for an always-running server.
Hopefully in the future I will make this easier.

[adam]

The good news is that v3 seems to be stable, no crash since I installed it.

Turning it into service: is that something I can do externally? Our software also has service mode, but as far as I recall, our installer does that programmatically, registering the software as a service through Windows API. Also, I also seem to remember that a service running in the SYSTEM account has issues having access to the network, which again may be an issue as long as HFS should serve files from other computers in the network.

Anyway, this is rather just an aesthetical issue, the old one was nicer with the system tray icon.

[rejetto]

yes, you can do it externally.
I wrote some instructions about it https://github.com/rejetto/hfs#service
but you may prefer other methods https://www.google.com/search?q=run+program+as+service+windows&oq=run+program+as+service+windows
If people know better methods I will update the documentation.

At the moment there's no automatic service installation. Hopefully in the future.
HFS is now cross-platform, and making system dependent actions is harder for me.