-1

Well, the problem is simple. I have the site based on apache and trying to execute cron job at this site from the same server. Let's say my site http://example.com and cronjob is

/usr/bin/curl http://example.com/cron.php

It does not work, error is "curl: (7) couldn't connect to host".

Why this could happen?

P.S. The site is working fine and accessible from any other external machine/client.

Here is an output of iptables -S

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2222 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

Ping failed: (ping example.com) - here I've used my server domain, of course:

134 packets transmitted, 0 received, 100% packet loss, time 136759ms

Verbose curl -v :

* About to connect() to myserver.com port 443 (#0)
*   Trying x.x.x.x... Connection timed out
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host

x.x.x.x is a external IP of my host.

Result of traceroute myserver.com

traceroute to myserver.com (x.x.x.x), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
Epsiloncool
  • 95
  • 2
  • 12

3 Answers3

2

Not quite the answer to your current problem, but it will render the whole issue moot since you're trying to trigger the script from the same host running your site anyway:

When you need to run PHP scripts from cron you're generally better of running them from the PHP command line interface rather than making a web request to the script. Depending on the location of your PHP binary change your batch job to:

/usr/bin/php -q -f /path/to/cron.php

That allows you to:

  • Place your batch jobs outside of web root.
  • Run your batch job under a different effective UID rather than the UID of your webserver.
  • Avoid timeouts (and other restrictions) imposed by your web server.
  • Circumvent any number of issues when the DNS name of your site does not point to a local IP-address on your server.
  • Avoid the overhead of setting up a TCP and/or TLS connection.

and more.

HBruijn
  • 72,524
  • 21
  • 127
  • 192
  • Normally you can't use all PHP framework features using this way. Thats why I always prefer "web call" method. In my case I have LOTS of working sites and absolutely not motivated to rewrite all PHP cron jobs. – Epsiloncool Jul 25 '16 at 07:25
1

Take a good look at the actual running iptables configuration

ipatables -L -vn

and ensure that nothing is blocking the source IP of the system running he curl/ping commands - take appropriate action.

If there is nothing there then something upstream, between the systems may be blocking. As ping is being blocked I guess you could try mtr

mtr -4 example.com

It may show a site blocking you.

Are you sure that the IP address of example.com is correct too ?

user9517
  • 114,104
  • 20
  • 206
  • 289
1

I realized it is a "hairpin DNS" issue. Best solution I guess to configure NAT to not shortcut request to my own external IP to local IP... but still my provider not did it and I temporary fixed it by

nano /etc/hosts

added a line

y.y.y.y   myserver.com

where y.y.y.y is my LOCAL address.

Epsiloncool
  • 95
  • 2
  • 12
  • Imo this is not a temporary fix, but *the* fix ;) especially if you're dealing with NAT – Olle Kelderman Jul 25 '16 at 09:01
  • I don't want to add all sites to /etc/hosts, also I don't know how all scripts will work with this "fix". – Epsiloncool Jul 25 '16 at 13:34
  • I do, although for me thats about 4 entries or so xd. And the hosts file is a system file, every hostname-resolve thing should obey it, if it doesn't, its broken – Olle Kelderman Jul 25 '16 at 13:43
  • Also, correct me if ik wrong, but isn't it ` [other hostnames]` as in the other way around as you said? – Olle Kelderman Jul 25 '16 at 13:45
  • Oh, yes, sure. I am sorry. Let me fix that. – Epsiloncool Jul 25 '16 at 14:56
  • After asking you all of those questions it's now obvious! Did you fix it? if so, mark this as the correct answer. If this were amazon EC2 the hairpinning is taken care of automatically, but you also have firewall rules (security groups) which can be set independently from the machine too. The hosts method certainly is the quickest fix. I was about to suggest it before I saw this answer. – hookenz Jul 27 '16 at 02:28
  • @matt Yes, etc/hosts method is working, however I think this is a temporary solution. Also I found an issue - some people with IP very close to server's IP can't see the server (no pings, no traceroutes, nothing). So I think it is combination of hairpin + firewall issue. – Epsiloncool Jul 27 '16 at 10:45
  • 1
    If you are unable to set up hairpinning perhaps you should ask another question related to the hardware/software you are using. You haven't said what it is. So I don't think we can help you further. – hookenz Jul 27 '16 at 22:20