Error timeout was reached attempt 1 5

Error timeout was reached attempt 1 5

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Asked by:

Question

We have a service built on C# that is a part of our application. The service has the following dependencies:

— TCP/IP Protocol Driver

The service is define like this:

Then we run it like this:

This is pretty standard way to run services in C#. In most cases the service starts OK, but in some situations, after a system restart, the service does not start and we see the following error in the System log:

A timeout was reached (30000 milliseconds) while waiting for the Accurate ID Service service to connect.

The problem here is that there is no sign of any attempt from the system to actually start the service. As soon as the above «Main()» function is called, we write a message into our log file and when the service does not start, we do not see this message. This suggests that the problem may be system related because Windows Operating System does not call the executable for some reasons. Our support guys told us that this is probably happening when Windows installs automatic updates. This is reasonable because updates take some time and maybe our service times out before the system gets to the point when it can call the service, because it was busy installing updates.

It looks like this problem became more often recently, which might point to some windows system update that is causing this issue.

All replies

Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
Stack over flow profile.. VB Forums — moderator

Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
Stack over flow profile.. VB Forums — moderator

Hi Aleksey Malyshev,

Thank you for posting here.

>> In most cases the service starts OK, but in some situations, after a system restart, the service does not start and we see the following error in the System log:

I am not sure the update cause the error. Do you have some code to end your service? If yes, you could try to get the status of your system. When you system shut down, close your service. You could set the service to start at boot as well.

MSDN Community Support
Please remember to click «Mark as Answer» the responses that resolved your issue, and to click «Unmark as Answer» if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

The lifetime of a service is very well defined by Windows. It is unclear to me where in the lifetime you’re seeing your error, if at all.

Service Main is called when the service process is started. This is generally when the service starts but if you are hosting multiple services then it’ll get called when the first service is started. Shortly after that call you’ll get the OnStart call for the specific service being started. The service has a fixed amount of time to start before the SCM will assume it is non-responsive and report an error. The error you get doesn’t line up with the one you posted so it seems unlikely.

1) Given your logging you have configured, you’re saying your Main method is never called? If so then your service process isn’t getting started either. Go to the event log and look in the System logs to see if Windows is recording your service starting or stopping at all.

2) In your timeout message it mentions the Accurate ID service. Is that your service? Is your service configured for AutoStart or Delay (AutoStart)?

3) You mentioned you have dependencies. Does that mean your installer has configured our service to depend on those other services as well? Windows starts services based upon group and dependencies so until those services come online your service wouldn’t attempt to start.

4) Does the service start correctly if you start it manually? Does this failure occur on every reboot or just certain ones? Enable boot logging to see what is going on in the system at the time of the failure if possible.

Источник

Timeout was reached vmware horizon ошибка

I opened with notepad and it works, it is compressed to 1 from 5kb

then I just post it here.

«18»,»0.323939000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»66″,»49765 > 443 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1″

«19»,»0.324010000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»66″,»443 > 49765 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=2 SACK_PERM=1″

«20»,»0.324475000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»60″,»49765 > 443 [ACK] Seq=1 Ack=1 Win=131328 Len=0″

«22»,»0.335299000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»54″,»443 > 49765 [ACK] Seq=1 Ack=158 Win=65378 Len=0″

«23»,»0.360269000″,»192.168.0.8″,»192.168.178.29″,»TLSv1.1″,»1075″,»Server Hello, Certificate, Server Key Exchange, Server Hello Done»

«24»,»0.386587000″,»192.168.178.29″,»192.168.0.8″,»TLSv1.1″,»284″,»Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message»

«25»,»0.397283000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»54″,»443 > 49765 [ACK] Seq=1022 Ack=388 Win=65148 Len=0″

«26»,»0.404559000″,»192.168.0.8″,»192.168.178.29″,»TLSv1.1″,»60″,»Change Cipher Spec»

«27»,»0.404995000″,»192.168.0.8″,»192.168.178.29″,»TLSv1.1″,»123″,»Encrypted Handshake Message»

«28»,»0.405371000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»60″,»49765 > 443 [ACK] Seq=388 Ack=1097 Win=130304 Len=0″

«30»,»0.416349000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»54″,»443 > 49765 [ACK] Seq=1097 Ack=697 Win=64840 Len=0″

«34»,»0.431046000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»60″,»49765 > 443 [ACK] Seq=878 Ack=1523 Win=131328 Len=0″

«37»,»0.436215000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»54″,»443 > 49749 [RST] Seq=1 Win=0 Len=0″

«38»,»0.436354000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»60″,»49749 > 443 [RST, ACK] Seq=54 Ack=1 Win=0 Len=0″

«39»,»0.446324000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»54″,»443 > 49765 [ACK] Seq=1523 Ack=1235 Win=64302 Len=0″

«41»,»0.466337000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»54″,»443 > 49765 [ACK] Seq=1523 Ack=1544 Win=65536 Len=0″

«44»,»0.634692000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»60″,»49765 > 443 [ACK] Seq=1544 Ack=2285 Win=130560 Len=0″

«112»,»4.413532000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»54″,»443 > 49765 [ACK] Seq=2285 Ack=1901 Win=65178 Len=0″

«114»,»4.423536000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»54″,»443 > 49765 [ACK] Seq=2285 Ack=2594 Win=64486 Len=0″

«147»,»4.678458000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»60″,»49765 > 443 [ACK] Seq=2594 Ack=3127 Win=131328 Len=0″

«149»,»4.691548000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»54″,»443 > 49765 [ACK] Seq=3127 Ack=2951 Win=64128 Len=0″

«151»,»4.701584000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»54″,»443 > 49765 [ACK] Seq=3127 Ack=3100 Win=65536 Len=0″

«154»,»4.795270000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»60″,»49765 > 443 [ACK] Seq=3100 Ack=3873 Win=130560 Len=0″

«308»,»1.768750000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»66″,»49749 > 443 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1″

«309»,»1.769172000″,»192.168.178.1″,»192.168.178.29″,»ICMP»,»94″,»Redirect (Redirect for host)»

«312»,»1.770650000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»66″,»443 > 49749 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=2 SACK_PERM=1″

«313»,»1.770720000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»54″,»49749 > 443 [ACK] Seq=1 Ack=1 Win=131328 Len=0″

«315»,»1.780436000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»60″,»443 > 49749 [ACK] Seq=1 Ack=158 Win=65378 Len=0″

«318»,»1.811578000″,»192.168.0.8″,»192.168.178.29″,»TLSv1.1″,»1075″,»Server Hello, Certificate, Server Key Exchange, Server Hello Done»

«319»,»1.859810000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»54″,»49749 > 443 [ACK] Seq=158 Ack=1022 Win=130304 Len=0″

«320»,»1.883643000″,»192.168.178.29″,»192.168.0.8″,»TLSv1.1″,»284″,»Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message»

«321»,»1.905421000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»60″,»443 > 49749 [ACK] Seq=1022 Ack=388 Win=65148 Len=0″

«322»,»1.905493000″,»192.168.0.8″,»192.168.178.29″,»TLSv1.1″,»60″,»Change Cipher Spec»

«323»,»1.905945000″,»192.168.0.8″,»192.168.178.29″,»TLSv1.1″,»123″,»Encrypted Handshake Message»

«324»,»1.905991000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»54″,»49749 > 443 [ACK] Seq=388 Ack=1097 Win=130304 Len=0″

«326»,»1.936678000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»60″,»443 > 49749 [ACK] Seq=1097 Ack=697 Win=64840 Len=0″

«330»,»1.945060000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»54″,»49749 > 443 [ACK] Seq=878 Ack=1523 Win=131328 Len=0″

«332»,»1.957461000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»60″,»443 > 49749 [ACK] Seq=1523 Ack=1235 Win=64302 Len=0″

«334»,»1.967477000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»60″,»443 > 49749 [ACK] Seq=1523 Ack=1544 Win=65536 Len=0″

«337»,»2.003566000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»54″,»49749 > 443 [ACK] Seq=1544 Ack=2285 Win=130560 Len=0″

«359»,»6.903774000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»60″,»443 > 49749 [ACK] Seq=2285 Ack=1901 Win=65178 Len=0″

«361»,»6.914856000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»60″,»443 > 49749 [ACK] Seq=2285 Ack=2594 Win=64486 Len=0″

«364»,»7.030403000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»54″,»49749 > 443 [ACK] Seq=2594 Ack=3127 Win=131328 Len=0″

«366»,»7.044746000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»60″,»443 > 49749 [ACK] Seq=3127 Ack=2951 Win=64128 Len=0″

«368»,»7.055910000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»60″,»443 > 49749 [ACK] Seq=3127 Ack=3100 Win=65536 Len=0″

«371»,»7.144683000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»54″,»49749 > 443 [ACK] Seq=3100 Ack=3873 Win=130560 Len=0″

«407»,»34.169464000″,»192.168.0.8″,»192.168.178.29″,»TCP»,»60″,»443 > 49749 [FIN, ACK] Seq=3926 Ack=3100 Win=65536 Len=0″

«408»,»34.169571000″,»192.168.178.29″,»192.168.0.8″,»TCP»,»54″,»49749 > 443 [ACK] Seq=3100 Ack=3927 Win=130560 Len=0″

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

• VMware Technology Network
• :
• Digital Workspace
• :
• Horizon
• :
• Horizon Desktops and Apps
• :
• Horizon client cant connect to connection server «.

simonsimon1129

• Mark as New
• Bookmark
• Subscribe
• Mute
• Email to a Friend

Horizon client cant connect to connection server «ERROR:Timeout was reached»

Where should I start troubleshooting I cant connect my Horizon Client my home laptop. «ERROR:Timeout was reached».
How to fix this ?

Locally my set up is working, but using client that’s my error. 1st time deploying Horizon.
Here are some info’s log file and screenshot

Shreyskar

• Mark as New
• Bookmark
• Subscribe
• Mute
• Email to a Friend

What is the horizon client version you are running?

Did you install it from windows store?

Are you connecting internally or from external network? Does the connection goes through a security server/UAG/load balancer?

simonsimon1129

• Mark as New
• Bookmark
• Subscribe
• Mute
• Email to a Friend

What is the horizon client version you are running?

Did you install it from windows store?
No, from VMware website sir.

Are you connecting internally or from external network? Does the connection goes through a security server/UAG/load balancer?

Client = External network.
Connection server goes through Security server. no Load balancer

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

• VMware Technology Network
• :
• Digital Workspace
• :
• Horizon
• :
• Horizon Desktops and Apps
• :
• Vmware Horizon 7.11 with Horizon Client 5.4.2 runn.

Peakay

• Mark as New
• Bookmark
• Subscribe
• Mute
• Email to a Friend

Vmware Horizon 7.11 with Horizon Client 5.4.2 running windows 10 — Error: Timeout was reached

I have noticed a pattern with our environment that doesn’t appear to happen always, but probably about 40% of the time.

this for me is occurring while running the client from home, connected via ethernet to my home router, then connecting to work VDI.

Vmware Tools in Guest OS 11.0.5 build 15389592

After 4 hours and while actively using my Horizon session, I am kicked from my Horizon session with the message «Error:Timeout was reached».

I am unable to reconnect for approximately 10 minutes

pool settings are set to 480 mins (8 hrs ) after disconnect, but I haven’t disconnected.

global settings are set to never forcibly disconnect users

Is there a «forcibly logoff users» timeout setting somewhere?

this issue occurs about 4 hours after logging in at the beginning of the day (around 11:30am) and although I am normally logged in for about 9 hours, I have not seen this behavior in the afternoons.

Shreyskar

• Mark as New
• Bookmark
• Subscribe
• Mute
• Email to a Friend

Do you have any GPO in your AD for View agent or client which forces session timeout value?

Peakay

• Mark as New
• Bookmark
• Subscribe
• Mute
• Email to a Friend

we do have view Policy in place, but nothing about log off or disconnect — is there one normally, do you know what it would be called?

this is all we have enabled

Shreyskar

• Mark as New
• Bookmark
• Subscribe
• Mute
• Email to a Friend

Hi Peakay , What protocol are you using? Does it happen with both pcoip/blast?

Peakay

• Mark as New
• Bookmark
• Subscribe
• Mute
• Email to a Friend

we only use PCOIP

Shreyskar

• Mark as New
• Bookmark
• Subscribe
• Mute
• Email to a Friend

Thanks for the update. Are these RDS session Or normal desktop session. The reason I ask this because for RDS,we do have below GPO which controls session timeout for an active session:

• Set time limit for active Remote Desktop Services sessions
• Terminate session when time limits are reached

1.If you are not connecting to RDS based session, by default, a user’s View session (PCoIP )will automatically be disconnected after 600min (10hrs). Not after the session has been ‘idle’ for ten hours.Event setting it to ‘Never’ makes it 1200min.

2. To effectively disable the session time out, enter 9999999 under ‘Forcibly disconnect users’, which equates to 19 years.

3. In this case you only few of your users might be getting logged off after 10hrs since not all of your users would be working a ten hour day on any regular basis, hence disconnect would be random in this case. Connection timeout time in the View admin page isn’t an idle or inactivity timer, but rather it is an automatic session timeout.Set

4. If issue still persist, please follow VMware Knowledge Base and set cs-disconnectlegacyclientsessionsontimeout=0.

We are running VMware Horizon View VDIs for our users when they are remote, want to work from home, etc. We are on version 6.0.1 build-208845. We have this one user that always seems to have connectivity issues. The only way that he can get back into his VDI is if an administrator goes into the VMware Horizon View Administrator console and performs a ‘Reset’ on his session. This fixes him for the session, however when he goes to use it again the next weekend, or evening, its the same story. The logs on the console aren’t very revealing, they show him attempt to sign-in, then attempt to access the VDI session, connect in successfully, then approximately 5-10 minutes later get dropped. The message in the Event log says «The pending session on machine VDI_MACHINE_NAME for user MY_DOMAINVDI_USER has expired.»

Has anyone experienced this or possibly have a suggestion as to what could be causing this issue?

just another thought, looks like you are using persistent disks. have you detached the disk and rebuilt a new desktop? this should alleviate any possible machine issues

14 Replies

Is this user in the same pool as the rest? Does the same issue occur with the both PCoIP and RDP protocols? How about the client version, I’m assuming its updated?

Kind of a specific situation, but we had one user who would have this issue because they kept redirecting their USB monitor to the virtual desktop forcing an install of display link drivers which would kill the VDI session. Most likely not your issue but maybe its something the user is doing to cause it?

Summing the Horizon Guru.

just another thought, looks like you are using persistent disks. have you detached the disk and rebuilt a new desktop? this should alleviate any possible machine issues

Is this user in the same pool as the rest? Does the same issue occur with the both PCoIP and RDP protocols? How about the client version, I’m assuming its updated?

Kind of a specific situation, but we had one user who would have this issue because they kept redirecting their USB monitor to the virtual desktop forcing an install of display link drivers which would kill the VDI session. Most likely not your issue but maybe its something the user is doing to cause it?

just another thought, looks like you are using persistent disks. have you detached the disk and rebuilt a new desktop? this should alleviate any possible machine issues

Check your Global Settings Session timeout.

Have you solved this issue. I also have the same issue with hundreds of users in different pools randomly disconnecting from their VM. Global settings session timeout are set to never.

I too have the same issue and our Global settings are set to NEVER as well. Have an open ticket with VMWare and nothing they have had me try has resolved the issue. We were running Horizon 5 for 3 years with no issues. This all started after the upgrade to Horizon 7.

Any luck? We are seeing this after updating to 7.0.3 from 7.0.0. VMware just keeps sending me KB articles to look at.

We are also seeing this after a 7.0.0 to 7.0.3 upgrade. Did you get any updates from VMware?

Nothing from VMware yet. They wanted us to send them a suspended VMs file that had the issue. I ended up monitoring the warnings and seeing one in that state. I had to put it in Maintenance Mode before it refreshed on me. Once that was done, i suspended it so I can grab the .vmss file. I sent that to them on Wednesday and as of yesterday (Friday), they were still reviewing them. Luckily, this doesnt apprear to be causing issues with any of our 1600 end users. Its more of an annoyance than anything. My guess is that there is a bug on the connection server side or on the agent. I will share what VM found when I hear back.

I think I might have found a workaround on the random disconnections.

I am almost certain that the disconnections has to do with something related to the network and not a bad configuration from the Horizon side.

I went through my pool settings again under Desktop Pool Settings under Remote Settings there is an option to «Automatically logoff after disconnect»; I had mine set to Immediately. I changed this setting to «After.. and put in 120 Minutes». My thought behind this was if a disconnection is occurring to the user’s Vm even if this would be a second the Composer has a clear instruction to logout the user, therefore changing this setting would mean that if there will be a disconnection the Composer would wait 2 hours to logout the user and since the user comes back online right after it won’t.

I know this does not give the answer to the disconnection issues, however at least it’s not impacting the users.

Try it out and Let me know if it worked for you or not.

We had a similar issue where everyone would get disconnected around a certain time nearly every day in 3 different companies.

The times were different among the 3, but consistent within.

A VERY long story short: I was able to track down the cause, but never able to fully get to the why. And I could duplicate the issue.

We were using Samsung NC241 Zero Clients connecting to View 6 via PCoIP. It’s could have started with View 5 and continued to View 6.

Certain users were pressing the soft off power button on the front of the device instead of logging off or pressing ctrl-alt-F12 to disconnect first. When this happened the «turned off» client would lock up the ports on the connection broker causing all other desktops to freeze and disconnect. After about 15 minutes (long enough for us to get in and see there was nothing wrong 😛 ), users could reconnect to their sessions and keep working.

Once we figured out that, just as a specific user left for the day, the problem occurred. We were able to isolate the source of the problem and replicate it.

If action was taken fast enough, other users didn’t drop their connection: Press the soft off button. a few seconds later everyone’s session locks up. disconnect the NIC or hard power off the unit and everyone’s session sprang back to life.

When the issue happened the connection broker just stopped responding to any client traffic until the client timed out, was cut from the network or the broker service was restarted.

VMware, Samsung and Teradici were engaged and strangely we ended up in a Mexican stand off where no one would pull the trigger as they didn’t want to be responsible for the blood bath 😛

1st solution: We tracked down users leaving around the disconnect times and trained them to DISCONNECT (ctrl-alt-F12) and then turn the screen(unit) off. or just leave it and let it go to low power mode.

2nd solution: We were running the connection brokers in tunnel mode for both internal and external access. We added additional connection brokers and configured the «internal» brokers to not use tunneling, while tunneling the «external» brokers. I believe this was the final «solution» as misbehaving client connections could no longer lock up the connection broker’s services. Though the problem probably still exists, I think it’s isolated to the individual desktops and is recorded in the logs as a PCoIP session timeout warning or some such.

Note: This happened with certain users on certain client units on certain desktops/pools. UserA could cause the problem on unit1 in pool-a, while shifting a seat and connecting UserA on unit2 in pool-a would not be a problem when pressing the soft off button. Likewise, UserB sitting in the problem seat of unit1 in pool-a could not generate the issue. AND to make you even crazier UserA on unit1 in pool-b (roaming profiles and folders redirections, et al.) would have not issues when pressing the soft off button.

Источник

Начну с того, что у меня довольно часто возникали синтаксические ошибки в коде php из-за чего, при их исправлении, vk api начинал по несколько раз выполнять скрипт. Это очень мешало, поэтому я сделал промежуточный скрипт. Он принимает callback-вызов на себя, пересылает post-запрос на мой основной php-файл и отвечает ‘ok’, чтобы вк больше не ругался. Я точно не уверен, но казалось, что всё работало прекрасно. У меня чат-менеджер, выполняющий базовые команды по типу /kick /ban /info и т.п. Среди них есть команда, которая проходится по списку пользователей беседы и выводит в чат тех, у кого дата регистрации меньше определённого значения. Вот, собственно его код:

// ответить
$repl = $data->object->reply_message;
if ($repl) {
    array_push($users, $repl->from_id);
}

// переслать
$repl = $data->object->fwd_messages;
if ($repl) {
    foreach ($repl as $user) {
        array_push($users, $user->from_id);
    }
}
switch($cmd) {
    case '/regdate':
    case '+regdate':
        if (empty($users)) { break; }
        foreach ($users as $id) {
            $numid = getUserInfo(substr($id, 1), 'id');
            $str = file_get_contents("http://vk.com/foaf.php?id=$numid");
            $res = preg_match('/<ya:created dc:date=".{25}"/>/', $str, $found);
            if ($res !== 0) {
                preg_match('/".{25}/', $found[0], $found);
                $regdate = substr($found[0], 1);
                // разница
                $interval = date_diff((new DateTime($regdate)), (new DateTime(date('c'))));
                $years = $interval->y;
                $month = $interval->m;
                $day = $interval->d;
                date_default_timezone_set('UTC');
                $date = (new DateTime($regdate))->getTimestamp();
                $startTimeStamp = (new DateTime())->setTimestamp($date);
                $detail = $startTimeStamp->format('m.d.Y в H:i');
                send("@id$numid (Пользователь) зарегистрировался: $detailnС момента регистрации прошло " . convDays($years, $month, $day));
            } else {
                send("Невозможно получить информацию. Страница пользователя заблокирована.");
            }
        }
        $executed = true;
        break;
}

И тут у меня возникает проблема. ВК говорит: Error: Timeout was reached (ну и 5 повторов), хотя ‘ok’ ему отвечают при пересылке. Код выполняется 5 раз (что понятно). Я грешу на то, что код выполняется долго и из-за этого появляется ошибка. Пересылаю запрос я при помощи curl и скорее всего после отправки скрипт ждёт завершения работы того скрипта, хотя это под вопросом. Кстати, вот сама переадресация:

if (!isset($_REQUEST)) { 
    return; 
}

$content = file_get_contents('php://input');
$data = json_decode($content);
include_once('../conf.php');

switch ($data->type) {
    case 'confirmation':
        echo $conf['callback_token'];
        break;
    default:
        $url = "http://example.com/index.php";
        $ch = curl_init($url);
        curl_setopt($ch, CURLOPT_POSTFIELDS, $content);
        curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type:application/json'));
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        $result = curl_exec($ch);
        curl_close($ch);

        echo "ok";
        break;
}

Напоследок хочу добавить, что в основном php-файле есть и другие команды, такие как /kick, /warn, отправка сообщений в беседу, получение даты регистрации конкретного человека и всё работает без нареканий, то есть технически моя конструкция работоспособна. Я не знаю, как мне быть с этим, поэтому нуждаюсь в советах старших

Достаточно часто многие пользователи ПК, которые так или иначе
связаны с Интернетом, а также геймеры, подключающиеся к игровым
порталам, наблюдают появление ошибок соединения с сервером. Сейчас мы
рассмотрим вопрос о том, что значит тайм-аут операции. Более того, будет
предложено несколько основных способов решения этой проблемы.

Тайм-аут операции — что это такое?

Итак,
на экране монитора возникает ошибка, сообщающая пользователю о том, что
соединение прервано, вернее, время ожидания подключения истекло.

В
принципе, тайм-аут и можно трактовать как некий временной промежуток, в
течение которого система ожидает ответа сервера на собственный
отправленный запрос. В системах Windows это параметр установлен по
умолчанию, а его значение прописано в сетке системного реестра настроек
текущего компьютерного терминала в подразделе SYSTEM, где во вложенных
директориях находится подпапка Parameters, где время указано в секундах.
Как правило, изменять его не рекомендуется.

Причины возникновения ошибки

Причин, когда
возникает тайм-аут операции, может быть довольно много. Выделим наиболее
часто встречающиеся ситуации. Прежде всего, в качестве основного
фактора выступает нестабильное подключение к Интернету, когда постоянно
происходит прерывание связи, и система не может получить цельный ответ
сервера, к которому в данный момент выполняется подключение.

В
некоторых случаях тайм-аут операции может срабатывать при включенных
антивирусных программах или при неправильных настройках брэндмауэра
Windows. Как известно, брэндмауэр при настройках по умолчанию способен
блокировать достаточно много веб-ресурсов, считая их опасными или
содержащими потенциально нежелательные данные. Такое очень часто
встречается при подключению к серверам многопользовательских онлайн-игр.

Кроме всего прочего, тайм-аут операции завершает время
ожидания подключения при использовании или неправильной настройке
прокси-сервера. В данном случае речь идет и о настройках прокси в
системе, и об использовании анонимных прокси-серверов, когда
пользователь по каким-либо причинам хочет остаться во Всемирной паутине
неузнанным, а проще говоря, скрыть истинный IP-адрес своего
компьютерного терминала. Рассмотрим несколько основных методов
исправления ситуации без вмешательства в системный реестр для
выставления более высокого значения периода ожидания.

Тайм-аут операции: что делать? Простейший способ исправления ситуации

Как
считается, наиболее простым способом, позволяющим избавиться от ошибки
118, является обычное закрытие не отвечающей страницы и ее повторное
открытие по истечении минут десяти. Иногда может потребоваться закрыть и
перезапустить сам интернет-браузер (часто такие ситуации почему-то
наблюдаются в Google Chrome и других браузерах на его основе).

Если
такой вариант не помогает, а сообщение «Ошибка: Тайм-аут операции…»
выдается снова, можно применить обычную перезагрузку компьютера или
ноутбука (а лучше и всех маршрутизаторов типа роутеров или
ADSL-модемов).

Достаточно
эффективным может оказаться решение проблемы, связанное с внесением,
допустим, игрового сайта в список разрешений (исключений) антивируса и
брэндмауэра, тем более что в обоих случаях в настройках сделать это не
так уж и сложно.

Изменение параметров прокси-сервера

Несколько
сложнее обстоит дело с настройками прокси в системе. Рассмотрим в
качестве примера стандартный Internet Explorer. В браузере нужно
использовать раздел «Свойства обозревателя» и вкладку «Подключения».

Снизу
имеется кнопка «Настройка сети», после нажатия на которую будет
произведен вход в окно настройки параметров локальной сети. Здесь
достаточно просто снять галочку (флажок) со строки «Использовать
прокси-сервер» и сохранить изменения (иногда можно отключить прокси для
локальных адресов).

Но вот если подключение производится при помощи прокси, для установки правильных настроек лучше обратиться к провайдеру.

Исправление системного файла Hosts

Теперь перейдем к более сложному методу исправления ошибок, когда может срабатывать тайм-аут операции.

Сначала
в меню отображения файлов и папок (в стандартном «Проводнике» это меню
«Сервис» со строкой «Параметры папок») на вкладке вида необходимо задать
показ скрытых папок и файлов.

После
вышеуказанной операции необходимо открыть меню «Выполнить» и ввести в
строке команду «notepad %windir%system32driversetchosts»
(естественно, без кавычек), поле чего в «Блокноте» будет открыт файл
Hosts. Обратите внимание: снизу имеется строка «::1 localhost». По идее,
она должна быть последней, так что все, что находится ниже нее, нужно
удалить, после чего произвести сохранение файла с оригинальным названием
и местоположением. Теперь остается только перезагрузить компьютерный
терминал. Затем, как правило, ошибка исчезает.

Заключение

Вот,
собственно, и все по поводу срабатывающего тайм-аута. Конечно, можно
использовать еще и редактирование системного реестра с заданием большего
значения периода ожидания ответа сервера, вот только гарантии, что все
остальные ресурсы будут грузиться без проблем, никто дать не может. К
тому же, как уже понятно, и сами страницы, если и будут грузиться, то
намного дольше. А это ни одному юзеру не нужно.

sudo apt-get install php5-gd php5-curl php5-cli php5-common

php: /usr/bin/php /usr/share/man/man1/php.1.gz 

Error: Timeout was reached                  
Reading package lists... Done

apt-cache policy php5-gd php5-curl php5-cli php5-common

php5-gd:
  Installed: 5.6.30+dfsg-0+deb8u1
  Candidate: 5.6.30+dfsg-0+deb8u1
  Version table:
 *** 5.6.30+dfsg-0+deb8u1 0
        500 http://mirrordirector.raspbian.org/raspbian/ jessie/main armhf Packages
        100 /var/lib/dpkg/status
php5-curl:
  Installed: 5.6.30+dfsg-0+deb8u1
  Candidate: 5.6.30+dfsg-0+deb8u1
  Version table:
 *** 5.6.30+dfsg-0+deb8u1 0
        500 http://mirrordirector.raspbian.org/raspbian/ jessie/main armhf Packages
        100 /var/lib/dpkg/status
php5-cli:
  Installed: 5.6.30+dfsg-0+deb8u1
  Candidate: 5.6.30+dfsg-0+deb8u1
  Version table:
 *** 5.6.30+dfsg-0+deb8u1 0
        500 http://mirrordirector.raspbian.org/raspbian/ jessie/main armhf Packages
        100 /var/lib/dpkg/status
php5-common:
  Installed: 5.6.30+dfsg-0+deb8u1
  Candidate: 5.6.30+dfsg-0+deb8u1
  Version table:
 *** 5.6.30+dfsg-0+deb8u1 0
        500 http://mirrordirector.raspbian.org/raspbian/ jessie/main armhf Packages
        100 /var/lib/dpkg/status

Return to “Troubleshooting”