I don’t know how soon. But it is being worked on at the moment but still requires a bit of patience.
All I know about the resolution time is in the topic.
@Admin what about the other issues?
About the other issues, most of them are either fixed already or so vague I don’t really know where to start looking.
When did that happen? We’ve had problems with the database servers previously, but a week ago, the servers were upgraded which should solve the problem. Although the upgrade itself also caused some downtime.
Have you experienced any database outages in the last week? If so, what did those “outages” look like?
How is not not accessible? What do you see?
I also need more specific for this.
When is sometimes and when is not sometimes? What are you executing and how do you know for sure that it doesn’t execute sometimes?
No, to be honest I experienced them a week ago. The database refused to connect (I couldn’t inizialize mysqli).
So I guess this problem is solved. Thank you.
The main problem is that I can’t change some flag, and a list of disabled flags (such as auto_prepend_file or upload_max_filesize) would be really useful.
But in some cases, even if I do not change anything related with them, flags like output_buffering (see this post too, it’s mine) get disabled on their own.
The same problem you described in this post (“Could not read line from socket” or a non-working login message), so I just have to wait you fix this bug.
If it can help, when the FTP works but is slow, the files are updated immediately after I start uploading them (I checked it inside the file manager), but the FTP client stays on that file for a lot of time: so it seems a problem related to the “server response” (I don’t really know how it works) more than to the uploading process itself. Hope it helps, good luck!
I don’t have a list of PHP settings which are or aren’t user customizable, but I can tell you that most of them are not configurable on free hosting. Any setting which can, if configured inappropriately, cause additional server load or interferes with other server behavior is typically disabled.
upload_max_filesize is a good example of that.
As for the
output_buffering flag, what sort of issue do you experience with it? Our servers do allow some output buffering. So as long as you’re using output buffering in your script and the amount of output you buffer doesn’t exceed the configured buffer size (4 MB), it should be fine. And if it does work some times but other times it doesn’t, could that be because you’re exceeding the buffer size?
That’s a very good observation! Now you mention it, it does take a long time between the file being transferred and the full transfer being complete. That could be a result of the storage system having issues properly synchronizing the file (to make sure a stored file is actually stored properly).
Yeah, it could be, even if 4KB seem to be enough of a single request.
Anyway, I solved using
ob_start() at the very top of every script…
I found out that the problem is probably related to the fact that I can only choose
http://mydomain.com/..., while my domain redirects every request to
https://mydomain.com (with SSL).
So i should be allowed to set a job pointing to the secure version of my domain:
It’s 4 MB, not 4 kB. 4 kB would be quite small, but 4 MB is big enough to fit most normal web pages.
It also doesn’t let you choose the www subdomain and the time selector is quite confusing. I will admit the interface isn’t great.
However, I’m a bit surprised by your conclusion though. How do you suppose the non-HTTPS URL causes the cron job to work sometimes and other times not?
It was my error: the few times it “worked”, that happened because I manually opened up the desired page to check if anything was going wrong.
So it never works.
Anyway, if this problem is not solved I could just switch to easycron.com and keep this hosting service.
The real problem is that damned FTP connection (even if today it seemed to work a bit faster, so let’s hope for the best)
That could be caused by the confusing time selector. It’s quite easy to misconfigure a cron job to make it never work.
Maintenance was performed yesterday which should fix this, but as far as I can tell, it hasn’t worked yet.
There are only hours/minutes selectors, so even if I made something wrong the cron should be executed within the first day.
I’ve seen your post and I was going to answer right now.
It seemed to be A BIT faster at some moments, but a few hours ago I experienced the “3900 users are already loggen in, sorry” error again.
Anyway, talking with a friend who uses profreehost.com (which I think uses iFastNet too for the similar Panel graphics) he said that that site has had this same problem for an year, and it seems that they can’t solve it.
So I fear that the problem could be more serious than expected.
Yes, it should. But it doesn’t. Because the time selector is confusing.
If you leave the hour selector empty and only fill in something in the minute selector, then the cron job will not execute. I believe you need to enter “1” in the hour selector to make it run every X minutes as defined in the minute counter. I don’t know which shedule your task should run on, but it could be that you’ve also run into the weird scheduler issues.
And if you think “that doesn’t make sense”, then I agree with you. Which is why I said it was confusing (which could be considered an understatement).
In the past, these “users already logged in” errors did happen, but only very rarely. I only happened a couple of times per year at most, and was usually solved by adding capacity.
On April 13, maintenance was performed on the storage system, after which these errors occurred multiple times per day. iFastNet has done various attempts to fix it, but it hasn’t worked so far.
I don’t know exactly what causes this. It could be the additional load of people sitting at home and deciding to spend their quarantine time to build a website, because of hardware failure (made worse due to the difficulty of getting people in the datacenter) or other reasons, I don’t know.
I run my cron jobs every 23h59m or 5h59m, so this shouldn’t be the case.
Anyway, I tried to delete and re-create them again… So I will know the result in a few hours.
I hope so… This would mean that in a few weeks the problem could be solved.
My personal opinion is that there’s not enough capacity to manage all the users, which constantly increase. In fact at night or during low-traffic hours the FTP works properly and even very fast.
The solution would be buying more “space” (as said I don’t know how exactly FTP works, but I mean “expanding that 3900 user limit”, which could be the real problem), but I know it could cost a lot and the price is not always affordable.
I would personally prefer a week of downtime if the problem gets solved, than keeping this issue for months; but I can understand the reason why you don’t want to do that.
Can I ask you how many people are there behind infinityfree.net? If you are alone, congratulation for the effort!
I hope it doesn’t take weeks, but I know that this problem is being taken seriously and that people are working on this.
It really depends on the nature of the issue. If there are really 3900 legitimate user connections and the FTP servers can handle more, then that limit could be increased. If the server can’t handle it, then maybe bigger or more servers are needed. But whether that’s feasible depends on why the limit is the way it is, and how much effort it would take to integrate. New server hardware is expensive, but having to re-engineer a good part of the free hosting system is much, much more expensive in time and money.
But the increased connections could also be caused by an attack (which would need to be stopped) or by another issue down the line (e.g. the storage system having inexplicable slowdowns). Neither would be resolved by adding more FTP capacity.
InfinityFree is just me. However, it should be noted that most of the free hosting infrastructure is maintained by iFastNet. The client area is the only part I can take credit for.
Tried 10 hours ago and it showed
6900 users (the maximum) are already logged in, sorry
Note that 6900 instead of 3900.
Tried now and works WAYY FASTER (I could even say as fast as before the issue).
So it’s obvious that something changed. Does that mean that you’ve solved the problem this morning or is it still too soon to draw a conclusion?
Anyway, thank you for the effort!
Regarding the Cron Jobs, my logs are still empty, so I have to pass to Easy Cron
The fact that you got that error in the first place means the issue isn’t resolved. If it was, you should never see that error.
Still getting the problem:
6900 users (the maximum) are already logged in, sorry
Furthermore, I sometimes find a 522 error which lasts for several hours:
You may want to refer to this announcement about that error:
As said here, the issue is solved and FTP works even better than before!
I wanted to wait a bit longer to see whether the problem came up again, but that hasn’t been the case.
Thanks to @Admin and iFastNet for the commitment and because they keep this website always up to date!
I think that this topic can be considered closed…