Not all shell scripts working with crontab
I have a little VPS I run apache and a Minecraft server on. I don't ever turn it off, but should I restart it for some reason, IPTables blocks most of my ports, including port 80. I've tried so many different suggestions on fixing this, but with no luck. Also, since the provider is OVH, the support is... lacking.
So, I've created a workaround, which I'm happy with. I created a simple shell script file to open certain ports I need opened on restart (80 and 25565 for now). The important ones such as 21 and 22 are not affected on restart.
The script looks like this:
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p udp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 25565 -j ACCEPT
iptables -I INPUT -p udp --dport 25565 -j ACCEPT
/sbin/service iptables save
When I manually run it by typing /iptdef.sh
, it runs fine, the ports become open and it's all good.
Of course, it's not practical having to remember to run it every time I restart the server, so I added a crontab. The problem is, it doesn't work/run. This is my crontab file:
*/5 * * * * /backup2.sh
*/55 * * * * /backup3.sh
@reboot /iptdef.sh
* * * * * /iptdef.sh
The first two lines work. They are just simple scripts that make a backup of a folder for me. The second two lines are what's not working.
Is there a chance that perhaps it's not possible to run iptables commands from a cron? It sounds silly, but I can't see any other reason for it not to work. The scripts have the correct permissions.
cron
add a comment |
I have a little VPS I run apache and a Minecraft server on. I don't ever turn it off, but should I restart it for some reason, IPTables blocks most of my ports, including port 80. I've tried so many different suggestions on fixing this, but with no luck. Also, since the provider is OVH, the support is... lacking.
So, I've created a workaround, which I'm happy with. I created a simple shell script file to open certain ports I need opened on restart (80 and 25565 for now). The important ones such as 21 and 22 are not affected on restart.
The script looks like this:
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p udp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 25565 -j ACCEPT
iptables -I INPUT -p udp --dport 25565 -j ACCEPT
/sbin/service iptables save
When I manually run it by typing /iptdef.sh
, it runs fine, the ports become open and it's all good.
Of course, it's not practical having to remember to run it every time I restart the server, so I added a crontab. The problem is, it doesn't work/run. This is my crontab file:
*/5 * * * * /backup2.sh
*/55 * * * * /backup3.sh
@reboot /iptdef.sh
* * * * * /iptdef.sh
The first two lines work. They are just simple scripts that make a backup of a folder for me. The second two lines are what's not working.
Is there a chance that perhaps it's not possible to run iptables commands from a cron? It sounds silly, but I can't see any other reason for it not to work. The scripts have the correct permissions.
cron
Are the scripts being run as root (basically, are they inroot
's crontab)?
– saiarcot895
Jul 21 '15 at 1:50
Yes, it is. I even tried giving the script public execution permissions, just in case, but nope, still the same old nothingness.
– Byonex
Jul 21 '15 at 1:55
WAIT A SECOND I THINK I FOUND THE PROBLEM
– Byonex
Jul 21 '15 at 1:58
Or not - I just realised I missed off the all important#!/bin/bash
line at the top of theiptdef.sh
file, so I added it, yet still no luck. Give up time soon.
– Byonex
Jul 21 '15 at 2:03
add a comment |
I have a little VPS I run apache and a Minecraft server on. I don't ever turn it off, but should I restart it for some reason, IPTables blocks most of my ports, including port 80. I've tried so many different suggestions on fixing this, but with no luck. Also, since the provider is OVH, the support is... lacking.
So, I've created a workaround, which I'm happy with. I created a simple shell script file to open certain ports I need opened on restart (80 and 25565 for now). The important ones such as 21 and 22 are not affected on restart.
The script looks like this:
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p udp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 25565 -j ACCEPT
iptables -I INPUT -p udp --dport 25565 -j ACCEPT
/sbin/service iptables save
When I manually run it by typing /iptdef.sh
, it runs fine, the ports become open and it's all good.
Of course, it's not practical having to remember to run it every time I restart the server, so I added a crontab. The problem is, it doesn't work/run. This is my crontab file:
*/5 * * * * /backup2.sh
*/55 * * * * /backup3.sh
@reboot /iptdef.sh
* * * * * /iptdef.sh
The first two lines work. They are just simple scripts that make a backup of a folder for me. The second two lines are what's not working.
Is there a chance that perhaps it's not possible to run iptables commands from a cron? It sounds silly, but I can't see any other reason for it not to work. The scripts have the correct permissions.
cron
I have a little VPS I run apache and a Minecraft server on. I don't ever turn it off, but should I restart it for some reason, IPTables blocks most of my ports, including port 80. I've tried so many different suggestions on fixing this, but with no luck. Also, since the provider is OVH, the support is... lacking.
So, I've created a workaround, which I'm happy with. I created a simple shell script file to open certain ports I need opened on restart (80 and 25565 for now). The important ones such as 21 and 22 are not affected on restart.
The script looks like this:
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p udp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 25565 -j ACCEPT
iptables -I INPUT -p udp --dport 25565 -j ACCEPT
/sbin/service iptables save
When I manually run it by typing /iptdef.sh
, it runs fine, the ports become open and it's all good.
Of course, it's not practical having to remember to run it every time I restart the server, so I added a crontab. The problem is, it doesn't work/run. This is my crontab file:
*/5 * * * * /backup2.sh
*/55 * * * * /backup3.sh
@reboot /iptdef.sh
* * * * * /iptdef.sh
The first two lines work. They are just simple scripts that make a backup of a folder for me. The second two lines are what's not working.
Is there a chance that perhaps it's not possible to run iptables commands from a cron? It sounds silly, but I can't see any other reason for it not to work. The scripts have the correct permissions.
cron
cron
edited Feb 10 at 19:28
Rui F Ribeiro
40.5k1479137
40.5k1479137
asked Jul 21 '15 at 1:26
ByonexByonex
1314
1314
Are the scripts being run as root (basically, are they inroot
's crontab)?
– saiarcot895
Jul 21 '15 at 1:50
Yes, it is. I even tried giving the script public execution permissions, just in case, but nope, still the same old nothingness.
– Byonex
Jul 21 '15 at 1:55
WAIT A SECOND I THINK I FOUND THE PROBLEM
– Byonex
Jul 21 '15 at 1:58
Or not - I just realised I missed off the all important#!/bin/bash
line at the top of theiptdef.sh
file, so I added it, yet still no luck. Give up time soon.
– Byonex
Jul 21 '15 at 2:03
add a comment |
Are the scripts being run as root (basically, are they inroot
's crontab)?
– saiarcot895
Jul 21 '15 at 1:50
Yes, it is. I even tried giving the script public execution permissions, just in case, but nope, still the same old nothingness.
– Byonex
Jul 21 '15 at 1:55
WAIT A SECOND I THINK I FOUND THE PROBLEM
– Byonex
Jul 21 '15 at 1:58
Or not - I just realised I missed off the all important#!/bin/bash
line at the top of theiptdef.sh
file, so I added it, yet still no luck. Give up time soon.
– Byonex
Jul 21 '15 at 2:03
Are the scripts being run as root (basically, are they in
root
's crontab)?– saiarcot895
Jul 21 '15 at 1:50
Are the scripts being run as root (basically, are they in
root
's crontab)?– saiarcot895
Jul 21 '15 at 1:50
Yes, it is. I even tried giving the script public execution permissions, just in case, but nope, still the same old nothingness.
– Byonex
Jul 21 '15 at 1:55
Yes, it is. I even tried giving the script public execution permissions, just in case, but nope, still the same old nothingness.
– Byonex
Jul 21 '15 at 1:55
WAIT A SECOND I THINK I FOUND THE PROBLEM
– Byonex
Jul 21 '15 at 1:58
WAIT A SECOND I THINK I FOUND THE PROBLEM
– Byonex
Jul 21 '15 at 1:58
Or not - I just realised I missed off the all important
#!/bin/bash
line at the top of the iptdef.sh
file, so I added it, yet still no luck. Give up time soon.– Byonex
Jul 21 '15 at 2:03
Or not - I just realised I missed off the all important
#!/bin/bash
line at the top of the iptdef.sh
file, so I added it, yet still no luck. Give up time soon.– Byonex
Jul 21 '15 at 2:03
add a comment |
3 Answers
3
active
oldest
votes
It's because cron forcibly sets PATH
to /usr/bin:/bin
. You need to invoke iptables
as /sbin/iptables
or add PATH=/usr/sbin:/sbin:/usr/bin:/bin
in your script or crontab. See crontab(5) for details.
2
I addedPATH=/usr/sbin:/sbin:/usr/bin:/bin
to top of the script file and it works perfectly! You, sir, are a gentleman and a scholar and a breeder of fine horses!
– Byonex
Jul 21 '15 at 2:32
add a comment |
This looks like it is covered well here: crontab's @reboot only works for root? basically the answer depends heavily on what you use for Cron and your Linux distribution.
The issue isn't just that. As you can see, it's also supposed to run every minute too (although it's also running as root anyway)
– Byonex
Jul 21 '15 at 2:02
add a comment |
I had to add this to /etc/hosts
so that mail to anyone at my server's own FQDN would be resolved:
127.0.0.1 mydomain.com.
Notice the dot at the end. In my case, I'm sending email essentially to root@localhost with MAILTO=root
which gets translated to root@mydomain.com.
Here's some more detail on this answer.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f217284%2fnot-all-shell-scripts-working-with-crontab%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
It's because cron forcibly sets PATH
to /usr/bin:/bin
. You need to invoke iptables
as /sbin/iptables
or add PATH=/usr/sbin:/sbin:/usr/bin:/bin
in your script or crontab. See crontab(5) for details.
2
I addedPATH=/usr/sbin:/sbin:/usr/bin:/bin
to top of the script file and it works perfectly! You, sir, are a gentleman and a scholar and a breeder of fine horses!
– Byonex
Jul 21 '15 at 2:32
add a comment |
It's because cron forcibly sets PATH
to /usr/bin:/bin
. You need to invoke iptables
as /sbin/iptables
or add PATH=/usr/sbin:/sbin:/usr/bin:/bin
in your script or crontab. See crontab(5) for details.
2
I addedPATH=/usr/sbin:/sbin:/usr/bin:/bin
to top of the script file and it works perfectly! You, sir, are a gentleman and a scholar and a breeder of fine horses!
– Byonex
Jul 21 '15 at 2:32
add a comment |
It's because cron forcibly sets PATH
to /usr/bin:/bin
. You need to invoke iptables
as /sbin/iptables
or add PATH=/usr/sbin:/sbin:/usr/bin:/bin
in your script or crontab. See crontab(5) for details.
It's because cron forcibly sets PATH
to /usr/bin:/bin
. You need to invoke iptables
as /sbin/iptables
or add PATH=/usr/sbin:/sbin:/usr/bin:/bin
in your script or crontab. See crontab(5) for details.
answered Jul 21 '15 at 2:15
yaegashiyaegashi
8,38611734
8,38611734
2
I addedPATH=/usr/sbin:/sbin:/usr/bin:/bin
to top of the script file and it works perfectly! You, sir, are a gentleman and a scholar and a breeder of fine horses!
– Byonex
Jul 21 '15 at 2:32
add a comment |
2
I addedPATH=/usr/sbin:/sbin:/usr/bin:/bin
to top of the script file and it works perfectly! You, sir, are a gentleman and a scholar and a breeder of fine horses!
– Byonex
Jul 21 '15 at 2:32
2
2
I added
PATH=/usr/sbin:/sbin:/usr/bin:/bin
to top of the script file and it works perfectly! You, sir, are a gentleman and a scholar and a breeder of fine horses!– Byonex
Jul 21 '15 at 2:32
I added
PATH=/usr/sbin:/sbin:/usr/bin:/bin
to top of the script file and it works perfectly! You, sir, are a gentleman and a scholar and a breeder of fine horses!– Byonex
Jul 21 '15 at 2:32
add a comment |
This looks like it is covered well here: crontab's @reboot only works for root? basically the answer depends heavily on what you use for Cron and your Linux distribution.
The issue isn't just that. As you can see, it's also supposed to run every minute too (although it's also running as root anyway)
– Byonex
Jul 21 '15 at 2:02
add a comment |
This looks like it is covered well here: crontab's @reboot only works for root? basically the answer depends heavily on what you use for Cron and your Linux distribution.
The issue isn't just that. As you can see, it's also supposed to run every minute too (although it's also running as root anyway)
– Byonex
Jul 21 '15 at 2:02
add a comment |
This looks like it is covered well here: crontab's @reboot only works for root? basically the answer depends heavily on what you use for Cron and your Linux distribution.
This looks like it is covered well here: crontab's @reboot only works for root? basically the answer depends heavily on what you use for Cron and your Linux distribution.
answered Jul 21 '15 at 1:59
JennaKOJennaKO
212
212
The issue isn't just that. As you can see, it's also supposed to run every minute too (although it's also running as root anyway)
– Byonex
Jul 21 '15 at 2:02
add a comment |
The issue isn't just that. As you can see, it's also supposed to run every minute too (although it's also running as root anyway)
– Byonex
Jul 21 '15 at 2:02
The issue isn't just that. As you can see, it's also supposed to run every minute too (although it's also running as root anyway)
– Byonex
Jul 21 '15 at 2:02
The issue isn't just that. As you can see, it's also supposed to run every minute too (although it's also running as root anyway)
– Byonex
Jul 21 '15 at 2:02
add a comment |
I had to add this to /etc/hosts
so that mail to anyone at my server's own FQDN would be resolved:
127.0.0.1 mydomain.com.
Notice the dot at the end. In my case, I'm sending email essentially to root@localhost with MAILTO=root
which gets translated to root@mydomain.com.
Here's some more detail on this answer.
add a comment |
I had to add this to /etc/hosts
so that mail to anyone at my server's own FQDN would be resolved:
127.0.0.1 mydomain.com.
Notice the dot at the end. In my case, I'm sending email essentially to root@localhost with MAILTO=root
which gets translated to root@mydomain.com.
Here's some more detail on this answer.
add a comment |
I had to add this to /etc/hosts
so that mail to anyone at my server's own FQDN would be resolved:
127.0.0.1 mydomain.com.
Notice the dot at the end. In my case, I'm sending email essentially to root@localhost with MAILTO=root
which gets translated to root@mydomain.com.
Here's some more detail on this answer.
I had to add this to /etc/hosts
so that mail to anyone at my server's own FQDN would be resolved:
127.0.0.1 mydomain.com.
Notice the dot at the end. In my case, I'm sending email essentially to root@localhost with MAILTO=root
which gets translated to root@mydomain.com.
Here's some more detail on this answer.
answered Aug 16 '17 at 18:08
hamx0rhamx0r
1011
1011
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f217284%2fnot-all-shell-scripts-working-with-crontab%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Are the scripts being run as root (basically, are they in
root
's crontab)?– saiarcot895
Jul 21 '15 at 1:50
Yes, it is. I even tried giving the script public execution permissions, just in case, but nope, still the same old nothingness.
– Byonex
Jul 21 '15 at 1:55
WAIT A SECOND I THINK I FOUND THE PROBLEM
– Byonex
Jul 21 '15 at 1:58
Or not - I just realised I missed off the all important
#!/bin/bash
line at the top of theiptdef.sh
file, so I added it, yet still no luck. Give up time soon.– Byonex
Jul 21 '15 at 2:03