Not all shell scripts working with crontab












2















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.










share|improve this question

























  • 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 the iptdef.sh file, so I added it, yet still no luck. Give up time soon.

    – Byonex
    Jul 21 '15 at 2:03
















2















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.










share|improve this question

























  • 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 the iptdef.sh file, so I added it, yet still no luck. Give up time soon.

    – Byonex
    Jul 21 '15 at 2:03














2












2








2


1






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.










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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 the iptdef.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











  • 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 the iptdef.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










3 Answers
3






active

oldest

votes


















6














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.






share|improve this answer



















  • 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



















0














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.






share|improve this answer
























  • 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



















0














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.






share|improve this answer























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    6














    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.






    share|improve this answer



















    • 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
















    6














    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.






    share|improve this answer



















    • 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














    6












    6








    6







    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.






    share|improve this answer













    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Jul 21 '15 at 2:15









    yaegashiyaegashi

    8,38611734




    8,38611734








    • 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














    • 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








    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













    0














    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.






    share|improve this answer
























    • 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
















    0














    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.






    share|improve this answer
























    • 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














    0












    0








    0







    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.






    share|improve this answer













    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    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



















    • 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











    0














    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.






    share|improve this answer




























      0














      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.






      share|improve this answer


























        0












        0








        0







        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.






        share|improve 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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Aug 16 '17 at 18:08









        hamx0rhamx0r

        1011




        1011






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            How to reconfigure Docker Trusted Registry 2.x.x to use CEPH FS mount instead of NFS and other traditional...

            is 'sed' thread safe

            How to make a Squid Proxy server?