crontab's @reboot only works for root?












60















man 5 crontab is pretty clear on how to use crontab to run a script on boot:



   These special time specification "nicknames" are supported, which replace the 5 initial time and date
fields, and are prefixed by the `@` character:
@reboot : Run once after reboot.


So I happily added a single line to my crontab (under my user account, not root):



@reboot     /home/me/myscript.sh


But for some reason, myscript.sh wouldn't run on machine reboot.
(it runs fine if I invoke it from the command line, so it's not a permissions problem)



What am I missing?





Update to answer @Anthon's questions:




  1. Oracle-linux version: 5.8 (uname: 2.6.32-300.39.2.el5uek #1 SMP)

  2. Cron version: vixie-cron-4.1-81.el5.x86_64

  3. Yes, /home is a mounted partition. Looks like this is the problem. How do I workaround this?

  4. Currently, myscript.sh only echos a text message to a file in /home/me.










share|improve this question




















  • 2





    your user crontab does not support @reboot option, there are a few crontab layouts, once you start poking around.

    – X Tian
    Jan 17 '14 at 18:20











  • @XTian Thanks. What is the recommended way to run a script on reboot as a user other than root?

    – Withheld
    Jan 17 '14 at 18:38






  • 2





    What you are missing is unclear, but what we are missing is details. What version of oracle-linux are you running? Which version of cron do you have? Is /home a mounted partition? What are the contents of your /home/me/myscript.sh?

    – Anthon
    Jan 18 '14 at 5:47






  • 1





    If you're using Oracle's Lin. ver. 5 there is this changelog about issues with vixie-cron + @reboot. oss.oracle.com/pipermail/el-errata/2012-March/002655.html

    – slm
    Jan 18 '14 at 6:08






  • 1





    @Daniel - is myscript.sh executable? chmod +x myscript.sh.

    – slm
    Jan 24 '14 at 12:51
















60















man 5 crontab is pretty clear on how to use crontab to run a script on boot:



   These special time specification "nicknames" are supported, which replace the 5 initial time and date
fields, and are prefixed by the `@` character:
@reboot : Run once after reboot.


So I happily added a single line to my crontab (under my user account, not root):



@reboot     /home/me/myscript.sh


But for some reason, myscript.sh wouldn't run on machine reboot.
(it runs fine if I invoke it from the command line, so it's not a permissions problem)



What am I missing?





Update to answer @Anthon's questions:




  1. Oracle-linux version: 5.8 (uname: 2.6.32-300.39.2.el5uek #1 SMP)

  2. Cron version: vixie-cron-4.1-81.el5.x86_64

  3. Yes, /home is a mounted partition. Looks like this is the problem. How do I workaround this?

  4. Currently, myscript.sh only echos a text message to a file in /home/me.










share|improve this question




















  • 2





    your user crontab does not support @reboot option, there are a few crontab layouts, once you start poking around.

    – X Tian
    Jan 17 '14 at 18:20











  • @XTian Thanks. What is the recommended way to run a script on reboot as a user other than root?

    – Withheld
    Jan 17 '14 at 18:38






  • 2





    What you are missing is unclear, but what we are missing is details. What version of oracle-linux are you running? Which version of cron do you have? Is /home a mounted partition? What are the contents of your /home/me/myscript.sh?

    – Anthon
    Jan 18 '14 at 5:47






  • 1





    If you're using Oracle's Lin. ver. 5 there is this changelog about issues with vixie-cron + @reboot. oss.oracle.com/pipermail/el-errata/2012-March/002655.html

    – slm
    Jan 18 '14 at 6:08






  • 1





    @Daniel - is myscript.sh executable? chmod +x myscript.sh.

    – slm
    Jan 24 '14 at 12:51














60












60








60


17






man 5 crontab is pretty clear on how to use crontab to run a script on boot:



   These special time specification "nicknames" are supported, which replace the 5 initial time and date
fields, and are prefixed by the `@` character:
@reboot : Run once after reboot.


So I happily added a single line to my crontab (under my user account, not root):



@reboot     /home/me/myscript.sh


But for some reason, myscript.sh wouldn't run on machine reboot.
(it runs fine if I invoke it from the command line, so it's not a permissions problem)



What am I missing?





Update to answer @Anthon's questions:




  1. Oracle-linux version: 5.8 (uname: 2.6.32-300.39.2.el5uek #1 SMP)

  2. Cron version: vixie-cron-4.1-81.el5.x86_64

  3. Yes, /home is a mounted partition. Looks like this is the problem. How do I workaround this?

  4. Currently, myscript.sh only echos a text message to a file in /home/me.










share|improve this question
















man 5 crontab is pretty clear on how to use crontab to run a script on boot:



   These special time specification "nicknames" are supported, which replace the 5 initial time and date
fields, and are prefixed by the `@` character:
@reboot : Run once after reboot.


So I happily added a single line to my crontab (under my user account, not root):



@reboot     /home/me/myscript.sh


But for some reason, myscript.sh wouldn't run on machine reboot.
(it runs fine if I invoke it from the command line, so it's not a permissions problem)



What am I missing?





Update to answer @Anthon's questions:




  1. Oracle-linux version: 5.8 (uname: 2.6.32-300.39.2.el5uek #1 SMP)

  2. Cron version: vixie-cron-4.1-81.el5.x86_64

  3. Yes, /home is a mounted partition. Looks like this is the problem. How do I workaround this?

  4. Currently, myscript.sh only echos a text message to a file in /home/me.







cron reboot






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Sep 10 '14 at 1:41









Braiam

23.7k2077142




23.7k2077142










asked Jan 17 '14 at 17:56









WithheldWithheld

403146




403146








  • 2





    your user crontab does not support @reboot option, there are a few crontab layouts, once you start poking around.

    – X Tian
    Jan 17 '14 at 18:20











  • @XTian Thanks. What is the recommended way to run a script on reboot as a user other than root?

    – Withheld
    Jan 17 '14 at 18:38






  • 2





    What you are missing is unclear, but what we are missing is details. What version of oracle-linux are you running? Which version of cron do you have? Is /home a mounted partition? What are the contents of your /home/me/myscript.sh?

    – Anthon
    Jan 18 '14 at 5:47






  • 1





    If you're using Oracle's Lin. ver. 5 there is this changelog about issues with vixie-cron + @reboot. oss.oracle.com/pipermail/el-errata/2012-March/002655.html

    – slm
    Jan 18 '14 at 6:08






  • 1





    @Daniel - is myscript.sh executable? chmod +x myscript.sh.

    – slm
    Jan 24 '14 at 12:51














  • 2





    your user crontab does not support @reboot option, there are a few crontab layouts, once you start poking around.

    – X Tian
    Jan 17 '14 at 18:20











  • @XTian Thanks. What is the recommended way to run a script on reboot as a user other than root?

    – Withheld
    Jan 17 '14 at 18:38






  • 2





    What you are missing is unclear, but what we are missing is details. What version of oracle-linux are you running? Which version of cron do you have? Is /home a mounted partition? What are the contents of your /home/me/myscript.sh?

    – Anthon
    Jan 18 '14 at 5:47






  • 1





    If you're using Oracle's Lin. ver. 5 there is this changelog about issues with vixie-cron + @reboot. oss.oracle.com/pipermail/el-errata/2012-March/002655.html

    – slm
    Jan 18 '14 at 6:08






  • 1





    @Daniel - is myscript.sh executable? chmod +x myscript.sh.

    – slm
    Jan 24 '14 at 12:51








2




2





your user crontab does not support @reboot option, there are a few crontab layouts, once you start poking around.

– X Tian
Jan 17 '14 at 18:20





your user crontab does not support @reboot option, there are a few crontab layouts, once you start poking around.

– X Tian
Jan 17 '14 at 18:20













@XTian Thanks. What is the recommended way to run a script on reboot as a user other than root?

– Withheld
Jan 17 '14 at 18:38





@XTian Thanks. What is the recommended way to run a script on reboot as a user other than root?

– Withheld
Jan 17 '14 at 18:38




2




2





What you are missing is unclear, but what we are missing is details. What version of oracle-linux are you running? Which version of cron do you have? Is /home a mounted partition? What are the contents of your /home/me/myscript.sh?

– Anthon
Jan 18 '14 at 5:47





What you are missing is unclear, but what we are missing is details. What version of oracle-linux are you running? Which version of cron do you have? Is /home a mounted partition? What are the contents of your /home/me/myscript.sh?

– Anthon
Jan 18 '14 at 5:47




1




1





If you're using Oracle's Lin. ver. 5 there is this changelog about issues with vixie-cron + @reboot. oss.oracle.com/pipermail/el-errata/2012-March/002655.html

– slm
Jan 18 '14 at 6:08





If you're using Oracle's Lin. ver. 5 there is this changelog about issues with vixie-cron + @reboot. oss.oracle.com/pipermail/el-errata/2012-March/002655.html

– slm
Jan 18 '14 at 6:08




1




1





@Daniel - is myscript.sh executable? chmod +x myscript.sh.

– slm
Jan 24 '14 at 12:51





@Daniel - is myscript.sh executable? chmod +x myscript.sh.

– slm
Jan 24 '14 at 12:51










7 Answers
7






active

oldest

votes


















45














This can be a bit of a confusing topic because there are different implementations of cron. Also there were several bugs that broke this feature, and there are also some use cases where it simply won't work, specifically if you do a shutdown/boot vs. a reboot.



Bugs



datapoint #1



One such bug in Debian is covered here, titled: cron: @reboot jobs are not run. This seems to have made it's way into Ubuntu as well, which I can't confirm directly.



datapoint #2



Evidence of the bug in Ubuntu would seem to be confirmed here in this SO Q&A titled: @reboot cronjob not executing.



excerpt




comment #1: .... 3) your version of crond may not support @reboot are you using vix's crond? ... show results of crontab -l -u user



comment #2: ... It might be a good idea to set it up as an init script instead of relying on a specific version of cron's @reboot.



comment #3: ... @MarkRoberts removed the reboot and modified the 1 * * * * , to */1 * * * * , problem is solved! Where do I send the rep pts Mark? Thank you!




The accepted answer in that Q&A also had this comment:




Seems to me Lubuntu doesn't support the @Reboot Cron syntax.




Additional evidence



datapoint #3



As additional evidence there was this thread that someone was attempting the very same thing and getting frustrated that it didn't work. It's titled: Thread: Cron - @reboot jobs not working.



excerpt




Re: Cron - @reboot jobs not working




Quote Originally Posted by ceallred View Post
This is killing me... Tried the wrapper script. Running manually generates the log file... rebooting and the job doesn't run or create log file.



Syslog shows that CRON ran the job... but again, no output and the process isn't running.
Jul 15 20:07:45 RavenWing cron[1026]: (CRON) INFO (Running @reboot jobs)
Jul 15 20:07:45 RavenWing CRON[1053]: (ceallred) CMD (/home/ceallred/Scripts/run_spideroak.sh > /home/ceallred/Scripts/SpiderOak.log 2>&1 &)



It's seems like cron doesn't like the @reboot command.... Any other ideas?




Okay... Partially solved. I'll mark this one as solved and start a new thread with the new issue.....



I think the answer was my encrypted home directory wasn't mounted when CRON was trying to run the script (stored in /home/username/scripts). Moved to /usr/scripts and the job runs as expected.



So now it appears to be a spideroak issue. Process starts, but by the time the boot process is finished, it's gone. I'm guessing a crash for some reason.... New thread to ask about that.



Thanks for all the help!




Once this above user figured out his issue he was able to get @reboot working out of the crontab entry of a user.



I'm not entirely sure what version of cron is used on Ubuntu, but this would seem to indicate that user's can use @reboot too, or that the bug was fixed at some point in subsequent versions of cron.



datapoint #4



I tested on CentOS 6 the following and it worked.



Example



$ crontab -l
@reboot echo "hi" > /home/sam/reboot.txt 2>&1


I then rebooted the system.



$ sudo reboot


After the reboot.



$ cat reboot.txt 
hi


Take aways




  1. This feature does seem to be supported for both system and user crontab entries.

  2. You have to make sure that it's supported/working in your particular distro and/or version of the cron package.


For more on how the actual mechanism works for @reboot I did come across this blog post which discusses the innards. It's titled: @reboot - explaining simple cron magic.



Debugging crond



You can turn up the verbosity of crond by adding the following to this configuration file on RHEL/CentOS/Fedora based distros.



$ more crond 
# Settings for the CRON daemon.
# CRONDARGS= : any extra command-line startup arguments for crond
CRONDARGS="-L 2"


The valid levels are 0, 1, or 2. To revert this file back to it's default logging level simply remove the "-L 2" when you're done debugging the situation.






share|improve this answer


























  • @Daniel - please take a peek at my updates. There is a lot more to the @reboot feature than I initially let on.

    – slm
    Jan 17 '14 at 19:31











  • Got a comment yesterday, looked at your answer and decided to answer myself after a good night sleep. Set up a VM, retried @reboot, wanted to post my answer and only then saw you 'reworded' your answer :-(

    – Anthon
    Jan 18 '14 at 5:55













  • @Anthon - sorry, I quickly answered it yesterday and then continued to research it and found very conflicting details. When I found the bug on Debian about it and Ubuntu SO I realized some of what was at play. I saw that it worked on CentOS and put it together that @reboot is OK in certain crons, and apparently buggy/broken in others. Hence the confusion.

    – slm
    Jan 18 '14 at 6:01













  • Apart from that the OP provides little detail, you can easily use something that does not work yet (at boot time) in your script that make it fail, or have it reside on a not-yet-mounted disc. My answer which the OP commented on, was confirmed by a 3rd party as well. It is the black swan problem...

    – Anthon
    Jan 18 '14 at 6:07






  • 3





    You might want to point out that the bug in Ubuntu is easily solved by adding a delay: @reboot sleep 60; <your command>. To quote the thread, "my guess is that cron's @reboot directive is running too early in the boot process"

    – pzkpfw
    Feb 19 '15 at 21:30



















10














I found out that on my Ubuntu machine, I do not have access to dns services, yet, at @reboot time. This prevented me from mounting remote volumes. This corny, yet simple, solution worked:



@reboot sleep 60 && /home/me/bin/mount.sh 2>&1 >> /home/me/reboot.log



(in root cron; last parts only for debugging)






share|improve this answer
























  • This is the only thing that actually works on ubuntu 16.04 for non-root users!

    – Aleksandar Pavić
    Apr 18 '17 at 13:56











  • Not working on Debian 8 jessie (gnome 3). :(

    – JedatKinports
    Apr 29 '17 at 16:25





















2














I have mac osx as well and I had same issue where my script were not running. but When i fixed my script to like



@reboot   cd /home/me/  && sh myscript.sh


it worked fine for me. make sure to make your shell file to be executable by running the command



chmod +x myscript.sh


hope these helps.






share|improve this answer

































    1














    Take a fresh install of Ubuntu Gnome 13.10 (default user in my case: avanderneut).



    avanderneut@uggo:~$ crontab -l
    no crontab for avanderneut
    avanderneut@uggo:~$ crontab -e
    no crontab for avanderneut - using an empty one

    Select an editor. To change later, run 'select-editor'.
    1. /bin/ed
    2. /bin/nano <---- easiest
    3. /usr/bin/vim.tiny

    Choose 1-3 [2]: 3
    crontab: installing new crontab
    avanderneut@uggo:~$ crontab -l | tail -2
    # m h dom mon dow command
    @reboot /home/avanderneut/bin/on_reboot
    avanderneut@uggo:~$ vi /home/avanderneut/bin/on_reboot
    avanderneut@uggo:~$ more !$
    more /home/avanderneut/bin/on_reboot
    #! /bin/bash
    echo "Reboot script" > /var/tmp/xxx
    avanderneut@uggo:~$ chmod 755 /home/avanderneut/bin/on_reboot
    avanderneut@uggo:~$ ls /var/tmp
    avanderneut@uggo:~$ /home/avanderneut/bin/on_reboot
    avanderneut@uggo:~$ ls /var/tmp
    xxx
    avanderneut@uggo:~$ rm /var/tmp/xxx
    avanderneut@uggo:~$ sudo reboot
    [sudo] password for avanderneut:


    And see that after reboot the file /var/tmp/xxx is there although it was not there before rebooting.



    This was done with cron version 3.0.



    You have to make sure that no services discs etc are used that might not be available at the time the script runs. Start with something simple like the above and make sure it has no terminal output as email is probably not up and running.



    You might aslo need a more up-to-date cron (or an upgrade from oracle-linux) if this did not work for you and you need this feature.






    share|improve this answer
























    • I updated my OP to answer your questions. Turns out your suspicion was right from the start: The script to-be-run on reboot resides on a mountable /dev/mapper/VolGroup00-LogVol01 partition.

      – Withheld
      Jan 24 '14 at 12:56











    • @Daniel Thanks for letting me know, I'm glad you found the culprit. I am not sure if you can delay the start of cron until the partitions are mounted, some of that startup is done in parallel and you would have to change dependencies. I would not want to mess with that and possible break cron. You should IMHO take a different route than crontab & @reboot to run something once on startup as the user.

      – Anthon
      Jan 24 '14 at 13:15



















    1














    I don't know if you have already solved this, or if any of the above was the solution you needed, but another possibility is:



    if you have your /home directory encrypted, it may not be available until you log in, i.e. it is not available at reboot.



    in this scenario, you could move your scripts to another location like /srv or /opt or /usr/local/bin/ etc.






    share|improve this answer































      0














      I would say yes for the question. Just had difficulties with running cron on reboot (Debian 3.10.70) and managed to solve with:



      @reboot root /usr/bin/python3 /path/to/script



      And a newline character 'n' in the end



      This is the contents of file:



      /etc/cron.d/runOnReboot


      Finally, I think it is worth noting an abstract from man 5 crontab




      ...
      The format of a cron command is very much the V7 standard, with a number of upward-compatible extensions. Each line has five time and date
      fields, followed by a command, followed by a newline character ('n'). The system crontab (/etc/crontab) uses the same format, except that the
      username for the command is specified after the time and date fields and before the command. The fields may be separated by spaces or tabs. The
      maximum permitted length for the command field is 998 characters.
      ...







      share|improve this answer































        -1














        prueba:



        usuario@ubuntu:~$ touch script.sh
        usuario@ubuntu:~$ chmod +x script.sh



        usuario@ubuntu:~$ $crontrab -e



        @reboot /home/usuario/script.sh



        save and restart your pc






        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%2f109804%2fcrontabs-reboot-only-works-for-root%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          7 Answers
          7






          active

          oldest

          votes








          7 Answers
          7






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          45














          This can be a bit of a confusing topic because there are different implementations of cron. Also there were several bugs that broke this feature, and there are also some use cases where it simply won't work, specifically if you do a shutdown/boot vs. a reboot.



          Bugs



          datapoint #1



          One such bug in Debian is covered here, titled: cron: @reboot jobs are not run. This seems to have made it's way into Ubuntu as well, which I can't confirm directly.



          datapoint #2



          Evidence of the bug in Ubuntu would seem to be confirmed here in this SO Q&A titled: @reboot cronjob not executing.



          excerpt




          comment #1: .... 3) your version of crond may not support @reboot are you using vix's crond? ... show results of crontab -l -u user



          comment #2: ... It might be a good idea to set it up as an init script instead of relying on a specific version of cron's @reboot.



          comment #3: ... @MarkRoberts removed the reboot and modified the 1 * * * * , to */1 * * * * , problem is solved! Where do I send the rep pts Mark? Thank you!




          The accepted answer in that Q&A also had this comment:




          Seems to me Lubuntu doesn't support the @Reboot Cron syntax.




          Additional evidence



          datapoint #3



          As additional evidence there was this thread that someone was attempting the very same thing and getting frustrated that it didn't work. It's titled: Thread: Cron - @reboot jobs not working.



          excerpt




          Re: Cron - @reboot jobs not working




          Quote Originally Posted by ceallred View Post
          This is killing me... Tried the wrapper script. Running manually generates the log file... rebooting and the job doesn't run or create log file.



          Syslog shows that CRON ran the job... but again, no output and the process isn't running.
          Jul 15 20:07:45 RavenWing cron[1026]: (CRON) INFO (Running @reboot jobs)
          Jul 15 20:07:45 RavenWing CRON[1053]: (ceallred) CMD (/home/ceallred/Scripts/run_spideroak.sh > /home/ceallred/Scripts/SpiderOak.log 2>&1 &)



          It's seems like cron doesn't like the @reboot command.... Any other ideas?




          Okay... Partially solved. I'll mark this one as solved and start a new thread with the new issue.....



          I think the answer was my encrypted home directory wasn't mounted when CRON was trying to run the script (stored in /home/username/scripts). Moved to /usr/scripts and the job runs as expected.



          So now it appears to be a spideroak issue. Process starts, but by the time the boot process is finished, it's gone. I'm guessing a crash for some reason.... New thread to ask about that.



          Thanks for all the help!




          Once this above user figured out his issue he was able to get @reboot working out of the crontab entry of a user.



          I'm not entirely sure what version of cron is used on Ubuntu, but this would seem to indicate that user's can use @reboot too, or that the bug was fixed at some point in subsequent versions of cron.



          datapoint #4



          I tested on CentOS 6 the following and it worked.



          Example



          $ crontab -l
          @reboot echo "hi" > /home/sam/reboot.txt 2>&1


          I then rebooted the system.



          $ sudo reboot


          After the reboot.



          $ cat reboot.txt 
          hi


          Take aways




          1. This feature does seem to be supported for both system and user crontab entries.

          2. You have to make sure that it's supported/working in your particular distro and/or version of the cron package.


          For more on how the actual mechanism works for @reboot I did come across this blog post which discusses the innards. It's titled: @reboot - explaining simple cron magic.



          Debugging crond



          You can turn up the verbosity of crond by adding the following to this configuration file on RHEL/CentOS/Fedora based distros.



          $ more crond 
          # Settings for the CRON daemon.
          # CRONDARGS= : any extra command-line startup arguments for crond
          CRONDARGS="-L 2"


          The valid levels are 0, 1, or 2. To revert this file back to it's default logging level simply remove the "-L 2" when you're done debugging the situation.






          share|improve this answer


























          • @Daniel - please take a peek at my updates. There is a lot more to the @reboot feature than I initially let on.

            – slm
            Jan 17 '14 at 19:31











          • Got a comment yesterday, looked at your answer and decided to answer myself after a good night sleep. Set up a VM, retried @reboot, wanted to post my answer and only then saw you 'reworded' your answer :-(

            – Anthon
            Jan 18 '14 at 5:55













          • @Anthon - sorry, I quickly answered it yesterday and then continued to research it and found very conflicting details. When I found the bug on Debian about it and Ubuntu SO I realized some of what was at play. I saw that it worked on CentOS and put it together that @reboot is OK in certain crons, and apparently buggy/broken in others. Hence the confusion.

            – slm
            Jan 18 '14 at 6:01













          • Apart from that the OP provides little detail, you can easily use something that does not work yet (at boot time) in your script that make it fail, or have it reside on a not-yet-mounted disc. My answer which the OP commented on, was confirmed by a 3rd party as well. It is the black swan problem...

            – Anthon
            Jan 18 '14 at 6:07






          • 3





            You might want to point out that the bug in Ubuntu is easily solved by adding a delay: @reboot sleep 60; <your command>. To quote the thread, "my guess is that cron's @reboot directive is running too early in the boot process"

            – pzkpfw
            Feb 19 '15 at 21:30
















          45














          This can be a bit of a confusing topic because there are different implementations of cron. Also there were several bugs that broke this feature, and there are also some use cases where it simply won't work, specifically if you do a shutdown/boot vs. a reboot.



          Bugs



          datapoint #1



          One such bug in Debian is covered here, titled: cron: @reboot jobs are not run. This seems to have made it's way into Ubuntu as well, which I can't confirm directly.



          datapoint #2



          Evidence of the bug in Ubuntu would seem to be confirmed here in this SO Q&A titled: @reboot cronjob not executing.



          excerpt




          comment #1: .... 3) your version of crond may not support @reboot are you using vix's crond? ... show results of crontab -l -u user



          comment #2: ... It might be a good idea to set it up as an init script instead of relying on a specific version of cron's @reboot.



          comment #3: ... @MarkRoberts removed the reboot and modified the 1 * * * * , to */1 * * * * , problem is solved! Where do I send the rep pts Mark? Thank you!




          The accepted answer in that Q&A also had this comment:




          Seems to me Lubuntu doesn't support the @Reboot Cron syntax.




          Additional evidence



          datapoint #3



          As additional evidence there was this thread that someone was attempting the very same thing and getting frustrated that it didn't work. It's titled: Thread: Cron - @reboot jobs not working.



          excerpt




          Re: Cron - @reboot jobs not working




          Quote Originally Posted by ceallred View Post
          This is killing me... Tried the wrapper script. Running manually generates the log file... rebooting and the job doesn't run or create log file.



          Syslog shows that CRON ran the job... but again, no output and the process isn't running.
          Jul 15 20:07:45 RavenWing cron[1026]: (CRON) INFO (Running @reboot jobs)
          Jul 15 20:07:45 RavenWing CRON[1053]: (ceallred) CMD (/home/ceallred/Scripts/run_spideroak.sh > /home/ceallred/Scripts/SpiderOak.log 2>&1 &)



          It's seems like cron doesn't like the @reboot command.... Any other ideas?




          Okay... Partially solved. I'll mark this one as solved and start a new thread with the new issue.....



          I think the answer was my encrypted home directory wasn't mounted when CRON was trying to run the script (stored in /home/username/scripts). Moved to /usr/scripts and the job runs as expected.



          So now it appears to be a spideroak issue. Process starts, but by the time the boot process is finished, it's gone. I'm guessing a crash for some reason.... New thread to ask about that.



          Thanks for all the help!




          Once this above user figured out his issue he was able to get @reboot working out of the crontab entry of a user.



          I'm not entirely sure what version of cron is used on Ubuntu, but this would seem to indicate that user's can use @reboot too, or that the bug was fixed at some point in subsequent versions of cron.



          datapoint #4



          I tested on CentOS 6 the following and it worked.



          Example



          $ crontab -l
          @reboot echo "hi" > /home/sam/reboot.txt 2>&1


          I then rebooted the system.



          $ sudo reboot


          After the reboot.



          $ cat reboot.txt 
          hi


          Take aways




          1. This feature does seem to be supported for both system and user crontab entries.

          2. You have to make sure that it's supported/working in your particular distro and/or version of the cron package.


          For more on how the actual mechanism works for @reboot I did come across this blog post which discusses the innards. It's titled: @reboot - explaining simple cron magic.



          Debugging crond



          You can turn up the verbosity of crond by adding the following to this configuration file on RHEL/CentOS/Fedora based distros.



          $ more crond 
          # Settings for the CRON daemon.
          # CRONDARGS= : any extra command-line startup arguments for crond
          CRONDARGS="-L 2"


          The valid levels are 0, 1, or 2. To revert this file back to it's default logging level simply remove the "-L 2" when you're done debugging the situation.






          share|improve this answer


























          • @Daniel - please take a peek at my updates. There is a lot more to the @reboot feature than I initially let on.

            – slm
            Jan 17 '14 at 19:31











          • Got a comment yesterday, looked at your answer and decided to answer myself after a good night sleep. Set up a VM, retried @reboot, wanted to post my answer and only then saw you 'reworded' your answer :-(

            – Anthon
            Jan 18 '14 at 5:55













          • @Anthon - sorry, I quickly answered it yesterday and then continued to research it and found very conflicting details. When I found the bug on Debian about it and Ubuntu SO I realized some of what was at play. I saw that it worked on CentOS and put it together that @reboot is OK in certain crons, and apparently buggy/broken in others. Hence the confusion.

            – slm
            Jan 18 '14 at 6:01













          • Apart from that the OP provides little detail, you can easily use something that does not work yet (at boot time) in your script that make it fail, or have it reside on a not-yet-mounted disc. My answer which the OP commented on, was confirmed by a 3rd party as well. It is the black swan problem...

            – Anthon
            Jan 18 '14 at 6:07






          • 3





            You might want to point out that the bug in Ubuntu is easily solved by adding a delay: @reboot sleep 60; <your command>. To quote the thread, "my guess is that cron's @reboot directive is running too early in the boot process"

            – pzkpfw
            Feb 19 '15 at 21:30














          45












          45








          45







          This can be a bit of a confusing topic because there are different implementations of cron. Also there were several bugs that broke this feature, and there are also some use cases where it simply won't work, specifically if you do a shutdown/boot vs. a reboot.



          Bugs



          datapoint #1



          One such bug in Debian is covered here, titled: cron: @reboot jobs are not run. This seems to have made it's way into Ubuntu as well, which I can't confirm directly.



          datapoint #2



          Evidence of the bug in Ubuntu would seem to be confirmed here in this SO Q&A titled: @reboot cronjob not executing.



          excerpt




          comment #1: .... 3) your version of crond may not support @reboot are you using vix's crond? ... show results of crontab -l -u user



          comment #2: ... It might be a good idea to set it up as an init script instead of relying on a specific version of cron's @reboot.



          comment #3: ... @MarkRoberts removed the reboot and modified the 1 * * * * , to */1 * * * * , problem is solved! Where do I send the rep pts Mark? Thank you!




          The accepted answer in that Q&A also had this comment:




          Seems to me Lubuntu doesn't support the @Reboot Cron syntax.




          Additional evidence



          datapoint #3



          As additional evidence there was this thread that someone was attempting the very same thing and getting frustrated that it didn't work. It's titled: Thread: Cron - @reboot jobs not working.



          excerpt




          Re: Cron - @reboot jobs not working




          Quote Originally Posted by ceallred View Post
          This is killing me... Tried the wrapper script. Running manually generates the log file... rebooting and the job doesn't run or create log file.



          Syslog shows that CRON ran the job... but again, no output and the process isn't running.
          Jul 15 20:07:45 RavenWing cron[1026]: (CRON) INFO (Running @reboot jobs)
          Jul 15 20:07:45 RavenWing CRON[1053]: (ceallred) CMD (/home/ceallred/Scripts/run_spideroak.sh > /home/ceallred/Scripts/SpiderOak.log 2>&1 &)



          It's seems like cron doesn't like the @reboot command.... Any other ideas?




          Okay... Partially solved. I'll mark this one as solved and start a new thread with the new issue.....



          I think the answer was my encrypted home directory wasn't mounted when CRON was trying to run the script (stored in /home/username/scripts). Moved to /usr/scripts and the job runs as expected.



          So now it appears to be a spideroak issue. Process starts, but by the time the boot process is finished, it's gone. I'm guessing a crash for some reason.... New thread to ask about that.



          Thanks for all the help!




          Once this above user figured out his issue he was able to get @reboot working out of the crontab entry of a user.



          I'm not entirely sure what version of cron is used on Ubuntu, but this would seem to indicate that user's can use @reboot too, or that the bug was fixed at some point in subsequent versions of cron.



          datapoint #4



          I tested on CentOS 6 the following and it worked.



          Example



          $ crontab -l
          @reboot echo "hi" > /home/sam/reboot.txt 2>&1


          I then rebooted the system.



          $ sudo reboot


          After the reboot.



          $ cat reboot.txt 
          hi


          Take aways




          1. This feature does seem to be supported for both system and user crontab entries.

          2. You have to make sure that it's supported/working in your particular distro and/or version of the cron package.


          For more on how the actual mechanism works for @reboot I did come across this blog post which discusses the innards. It's titled: @reboot - explaining simple cron magic.



          Debugging crond



          You can turn up the verbosity of crond by adding the following to this configuration file on RHEL/CentOS/Fedora based distros.



          $ more crond 
          # Settings for the CRON daemon.
          # CRONDARGS= : any extra command-line startup arguments for crond
          CRONDARGS="-L 2"


          The valid levels are 0, 1, or 2. To revert this file back to it's default logging level simply remove the "-L 2" when you're done debugging the situation.






          share|improve this answer















          This can be a bit of a confusing topic because there are different implementations of cron. Also there were several bugs that broke this feature, and there are also some use cases where it simply won't work, specifically if you do a shutdown/boot vs. a reboot.



          Bugs



          datapoint #1



          One such bug in Debian is covered here, titled: cron: @reboot jobs are not run. This seems to have made it's way into Ubuntu as well, which I can't confirm directly.



          datapoint #2



          Evidence of the bug in Ubuntu would seem to be confirmed here in this SO Q&A titled: @reboot cronjob not executing.



          excerpt




          comment #1: .... 3) your version of crond may not support @reboot are you using vix's crond? ... show results of crontab -l -u user



          comment #2: ... It might be a good idea to set it up as an init script instead of relying on a specific version of cron's @reboot.



          comment #3: ... @MarkRoberts removed the reboot and modified the 1 * * * * , to */1 * * * * , problem is solved! Where do I send the rep pts Mark? Thank you!




          The accepted answer in that Q&A also had this comment:




          Seems to me Lubuntu doesn't support the @Reboot Cron syntax.




          Additional evidence



          datapoint #3



          As additional evidence there was this thread that someone was attempting the very same thing and getting frustrated that it didn't work. It's titled: Thread: Cron - @reboot jobs not working.



          excerpt




          Re: Cron - @reboot jobs not working




          Quote Originally Posted by ceallred View Post
          This is killing me... Tried the wrapper script. Running manually generates the log file... rebooting and the job doesn't run or create log file.



          Syslog shows that CRON ran the job... but again, no output and the process isn't running.
          Jul 15 20:07:45 RavenWing cron[1026]: (CRON) INFO (Running @reboot jobs)
          Jul 15 20:07:45 RavenWing CRON[1053]: (ceallred) CMD (/home/ceallred/Scripts/run_spideroak.sh > /home/ceallred/Scripts/SpiderOak.log 2>&1 &)



          It's seems like cron doesn't like the @reboot command.... Any other ideas?




          Okay... Partially solved. I'll mark this one as solved and start a new thread with the new issue.....



          I think the answer was my encrypted home directory wasn't mounted when CRON was trying to run the script (stored in /home/username/scripts). Moved to /usr/scripts and the job runs as expected.



          So now it appears to be a spideroak issue. Process starts, but by the time the boot process is finished, it's gone. I'm guessing a crash for some reason.... New thread to ask about that.



          Thanks for all the help!




          Once this above user figured out his issue he was able to get @reboot working out of the crontab entry of a user.



          I'm not entirely sure what version of cron is used on Ubuntu, but this would seem to indicate that user's can use @reboot too, or that the bug was fixed at some point in subsequent versions of cron.



          datapoint #4



          I tested on CentOS 6 the following and it worked.



          Example



          $ crontab -l
          @reboot echo "hi" > /home/sam/reboot.txt 2>&1


          I then rebooted the system.



          $ sudo reboot


          After the reboot.



          $ cat reboot.txt 
          hi


          Take aways




          1. This feature does seem to be supported for both system and user crontab entries.

          2. You have to make sure that it's supported/working in your particular distro and/or version of the cron package.


          For more on how the actual mechanism works for @reboot I did come across this blog post which discusses the innards. It's titled: @reboot - explaining simple cron magic.



          Debugging crond



          You can turn up the verbosity of crond by adding the following to this configuration file on RHEL/CentOS/Fedora based distros.



          $ more crond 
          # Settings for the CRON daemon.
          # CRONDARGS= : any extra command-line startup arguments for crond
          CRONDARGS="-L 2"


          The valid levels are 0, 1, or 2. To revert this file back to it's default logging level simply remove the "-L 2" when you're done debugging the situation.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited May 23 '17 at 12:40









          Community

          1




          1










          answered Jan 17 '14 at 18:27









          slmslm

          254k71537687




          254k71537687













          • @Daniel - please take a peek at my updates. There is a lot more to the @reboot feature than I initially let on.

            – slm
            Jan 17 '14 at 19:31











          • Got a comment yesterday, looked at your answer and decided to answer myself after a good night sleep. Set up a VM, retried @reboot, wanted to post my answer and only then saw you 'reworded' your answer :-(

            – Anthon
            Jan 18 '14 at 5:55













          • @Anthon - sorry, I quickly answered it yesterday and then continued to research it and found very conflicting details. When I found the bug on Debian about it and Ubuntu SO I realized some of what was at play. I saw that it worked on CentOS and put it together that @reboot is OK in certain crons, and apparently buggy/broken in others. Hence the confusion.

            – slm
            Jan 18 '14 at 6:01













          • Apart from that the OP provides little detail, you can easily use something that does not work yet (at boot time) in your script that make it fail, or have it reside on a not-yet-mounted disc. My answer which the OP commented on, was confirmed by a 3rd party as well. It is the black swan problem...

            – Anthon
            Jan 18 '14 at 6:07






          • 3





            You might want to point out that the bug in Ubuntu is easily solved by adding a delay: @reboot sleep 60; <your command>. To quote the thread, "my guess is that cron's @reboot directive is running too early in the boot process"

            – pzkpfw
            Feb 19 '15 at 21:30



















          • @Daniel - please take a peek at my updates. There is a lot more to the @reboot feature than I initially let on.

            – slm
            Jan 17 '14 at 19:31











          • Got a comment yesterday, looked at your answer and decided to answer myself after a good night sleep. Set up a VM, retried @reboot, wanted to post my answer and only then saw you 'reworded' your answer :-(

            – Anthon
            Jan 18 '14 at 5:55













          • @Anthon - sorry, I quickly answered it yesterday and then continued to research it and found very conflicting details. When I found the bug on Debian about it and Ubuntu SO I realized some of what was at play. I saw that it worked on CentOS and put it together that @reboot is OK in certain crons, and apparently buggy/broken in others. Hence the confusion.

            – slm
            Jan 18 '14 at 6:01













          • Apart from that the OP provides little detail, you can easily use something that does not work yet (at boot time) in your script that make it fail, or have it reside on a not-yet-mounted disc. My answer which the OP commented on, was confirmed by a 3rd party as well. It is the black swan problem...

            – Anthon
            Jan 18 '14 at 6:07






          • 3





            You might want to point out that the bug in Ubuntu is easily solved by adding a delay: @reboot sleep 60; <your command>. To quote the thread, "my guess is that cron's @reboot directive is running too early in the boot process"

            – pzkpfw
            Feb 19 '15 at 21:30

















          @Daniel - please take a peek at my updates. There is a lot more to the @reboot feature than I initially let on.

          – slm
          Jan 17 '14 at 19:31





          @Daniel - please take a peek at my updates. There is a lot more to the @reboot feature than I initially let on.

          – slm
          Jan 17 '14 at 19:31













          Got a comment yesterday, looked at your answer and decided to answer myself after a good night sleep. Set up a VM, retried @reboot, wanted to post my answer and only then saw you 'reworded' your answer :-(

          – Anthon
          Jan 18 '14 at 5:55







          Got a comment yesterday, looked at your answer and decided to answer myself after a good night sleep. Set up a VM, retried @reboot, wanted to post my answer and only then saw you 'reworded' your answer :-(

          – Anthon
          Jan 18 '14 at 5:55















          @Anthon - sorry, I quickly answered it yesterday and then continued to research it and found very conflicting details. When I found the bug on Debian about it and Ubuntu SO I realized some of what was at play. I saw that it worked on CentOS and put it together that @reboot is OK in certain crons, and apparently buggy/broken in others. Hence the confusion.

          – slm
          Jan 18 '14 at 6:01







          @Anthon - sorry, I quickly answered it yesterday and then continued to research it and found very conflicting details. When I found the bug on Debian about it and Ubuntu SO I realized some of what was at play. I saw that it worked on CentOS and put it together that @reboot is OK in certain crons, and apparently buggy/broken in others. Hence the confusion.

          – slm
          Jan 18 '14 at 6:01















          Apart from that the OP provides little detail, you can easily use something that does not work yet (at boot time) in your script that make it fail, or have it reside on a not-yet-mounted disc. My answer which the OP commented on, was confirmed by a 3rd party as well. It is the black swan problem...

          – Anthon
          Jan 18 '14 at 6:07





          Apart from that the OP provides little detail, you can easily use something that does not work yet (at boot time) in your script that make it fail, or have it reside on a not-yet-mounted disc. My answer which the OP commented on, was confirmed by a 3rd party as well. It is the black swan problem...

          – Anthon
          Jan 18 '14 at 6:07




          3




          3





          You might want to point out that the bug in Ubuntu is easily solved by adding a delay: @reboot sleep 60; <your command>. To quote the thread, "my guess is that cron's @reboot directive is running too early in the boot process"

          – pzkpfw
          Feb 19 '15 at 21:30





          You might want to point out that the bug in Ubuntu is easily solved by adding a delay: @reboot sleep 60; <your command>. To quote the thread, "my guess is that cron's @reboot directive is running too early in the boot process"

          – pzkpfw
          Feb 19 '15 at 21:30













          10














          I found out that on my Ubuntu machine, I do not have access to dns services, yet, at @reboot time. This prevented me from mounting remote volumes. This corny, yet simple, solution worked:



          @reboot sleep 60 && /home/me/bin/mount.sh 2>&1 >> /home/me/reboot.log



          (in root cron; last parts only for debugging)






          share|improve this answer
























          • This is the only thing that actually works on ubuntu 16.04 for non-root users!

            – Aleksandar Pavić
            Apr 18 '17 at 13:56











          • Not working on Debian 8 jessie (gnome 3). :(

            – JedatKinports
            Apr 29 '17 at 16:25


















          10














          I found out that on my Ubuntu machine, I do not have access to dns services, yet, at @reboot time. This prevented me from mounting remote volumes. This corny, yet simple, solution worked:



          @reboot sleep 60 && /home/me/bin/mount.sh 2>&1 >> /home/me/reboot.log



          (in root cron; last parts only for debugging)






          share|improve this answer
























          • This is the only thing that actually works on ubuntu 16.04 for non-root users!

            – Aleksandar Pavić
            Apr 18 '17 at 13:56











          • Not working on Debian 8 jessie (gnome 3). :(

            – JedatKinports
            Apr 29 '17 at 16:25
















          10












          10








          10







          I found out that on my Ubuntu machine, I do not have access to dns services, yet, at @reboot time. This prevented me from mounting remote volumes. This corny, yet simple, solution worked:



          @reboot sleep 60 && /home/me/bin/mount.sh 2>&1 >> /home/me/reboot.log



          (in root cron; last parts only for debugging)






          share|improve this answer













          I found out that on my Ubuntu machine, I do not have access to dns services, yet, at @reboot time. This prevented me from mounting remote volumes. This corny, yet simple, solution worked:



          @reboot sleep 60 && /home/me/bin/mount.sh 2>&1 >> /home/me/reboot.log



          (in root cron; last parts only for debugging)







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Mar 23 '16 at 11:24









          AndréAndré

          10112




          10112













          • This is the only thing that actually works on ubuntu 16.04 for non-root users!

            – Aleksandar Pavić
            Apr 18 '17 at 13:56











          • Not working on Debian 8 jessie (gnome 3). :(

            – JedatKinports
            Apr 29 '17 at 16:25





















          • This is the only thing that actually works on ubuntu 16.04 for non-root users!

            – Aleksandar Pavić
            Apr 18 '17 at 13:56











          • Not working on Debian 8 jessie (gnome 3). :(

            – JedatKinports
            Apr 29 '17 at 16:25



















          This is the only thing that actually works on ubuntu 16.04 for non-root users!

          – Aleksandar Pavić
          Apr 18 '17 at 13:56





          This is the only thing that actually works on ubuntu 16.04 for non-root users!

          – Aleksandar Pavić
          Apr 18 '17 at 13:56













          Not working on Debian 8 jessie (gnome 3). :(

          – JedatKinports
          Apr 29 '17 at 16:25







          Not working on Debian 8 jessie (gnome 3). :(

          – JedatKinports
          Apr 29 '17 at 16:25













          2














          I have mac osx as well and I had same issue where my script were not running. but When i fixed my script to like



          @reboot   cd /home/me/  && sh myscript.sh


          it worked fine for me. make sure to make your shell file to be executable by running the command



          chmod +x myscript.sh


          hope these helps.






          share|improve this answer






























            2














            I have mac osx as well and I had same issue where my script were not running. but When i fixed my script to like



            @reboot   cd /home/me/  && sh myscript.sh


            it worked fine for me. make sure to make your shell file to be executable by running the command



            chmod +x myscript.sh


            hope these helps.






            share|improve this answer




























              2












              2








              2







              I have mac osx as well and I had same issue where my script were not running. but When i fixed my script to like



              @reboot   cd /home/me/  && sh myscript.sh


              it worked fine for me. make sure to make your shell file to be executable by running the command



              chmod +x myscript.sh


              hope these helps.






              share|improve this answer















              I have mac osx as well and I had same issue where my script were not running. but When i fixed my script to like



              @reboot   cd /home/me/  && sh myscript.sh


              it worked fine for me. make sure to make your shell file to be executable by running the command



              chmod +x myscript.sh


              hope these helps.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Feb 8 '17 at 18:35









              phk

              4,04852255




              4,04852255










              answered Feb 8 '17 at 18:16









              KidaneKidane

              211




              211























                  1














                  Take a fresh install of Ubuntu Gnome 13.10 (default user in my case: avanderneut).



                  avanderneut@uggo:~$ crontab -l
                  no crontab for avanderneut
                  avanderneut@uggo:~$ crontab -e
                  no crontab for avanderneut - using an empty one

                  Select an editor. To change later, run 'select-editor'.
                  1. /bin/ed
                  2. /bin/nano <---- easiest
                  3. /usr/bin/vim.tiny

                  Choose 1-3 [2]: 3
                  crontab: installing new crontab
                  avanderneut@uggo:~$ crontab -l | tail -2
                  # m h dom mon dow command
                  @reboot /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ vi /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ more !$
                  more /home/avanderneut/bin/on_reboot
                  #! /bin/bash
                  echo "Reboot script" > /var/tmp/xxx
                  avanderneut@uggo:~$ chmod 755 /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ ls /var/tmp
                  avanderneut@uggo:~$ /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ ls /var/tmp
                  xxx
                  avanderneut@uggo:~$ rm /var/tmp/xxx
                  avanderneut@uggo:~$ sudo reboot
                  [sudo] password for avanderneut:


                  And see that after reboot the file /var/tmp/xxx is there although it was not there before rebooting.



                  This was done with cron version 3.0.



                  You have to make sure that no services discs etc are used that might not be available at the time the script runs. Start with something simple like the above and make sure it has no terminal output as email is probably not up and running.



                  You might aslo need a more up-to-date cron (or an upgrade from oracle-linux) if this did not work for you and you need this feature.






                  share|improve this answer
























                  • I updated my OP to answer your questions. Turns out your suspicion was right from the start: The script to-be-run on reboot resides on a mountable /dev/mapper/VolGroup00-LogVol01 partition.

                    – Withheld
                    Jan 24 '14 at 12:56











                  • @Daniel Thanks for letting me know, I'm glad you found the culprit. I am not sure if you can delay the start of cron until the partitions are mounted, some of that startup is done in parallel and you would have to change dependencies. I would not want to mess with that and possible break cron. You should IMHO take a different route than crontab & @reboot to run something once on startup as the user.

                    – Anthon
                    Jan 24 '14 at 13:15
















                  1














                  Take a fresh install of Ubuntu Gnome 13.10 (default user in my case: avanderneut).



                  avanderneut@uggo:~$ crontab -l
                  no crontab for avanderneut
                  avanderneut@uggo:~$ crontab -e
                  no crontab for avanderneut - using an empty one

                  Select an editor. To change later, run 'select-editor'.
                  1. /bin/ed
                  2. /bin/nano <---- easiest
                  3. /usr/bin/vim.tiny

                  Choose 1-3 [2]: 3
                  crontab: installing new crontab
                  avanderneut@uggo:~$ crontab -l | tail -2
                  # m h dom mon dow command
                  @reboot /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ vi /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ more !$
                  more /home/avanderneut/bin/on_reboot
                  #! /bin/bash
                  echo "Reboot script" > /var/tmp/xxx
                  avanderneut@uggo:~$ chmod 755 /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ ls /var/tmp
                  avanderneut@uggo:~$ /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ ls /var/tmp
                  xxx
                  avanderneut@uggo:~$ rm /var/tmp/xxx
                  avanderneut@uggo:~$ sudo reboot
                  [sudo] password for avanderneut:


                  And see that after reboot the file /var/tmp/xxx is there although it was not there before rebooting.



                  This was done with cron version 3.0.



                  You have to make sure that no services discs etc are used that might not be available at the time the script runs. Start with something simple like the above and make sure it has no terminal output as email is probably not up and running.



                  You might aslo need a more up-to-date cron (or an upgrade from oracle-linux) if this did not work for you and you need this feature.






                  share|improve this answer
























                  • I updated my OP to answer your questions. Turns out your suspicion was right from the start: The script to-be-run on reboot resides on a mountable /dev/mapper/VolGroup00-LogVol01 partition.

                    – Withheld
                    Jan 24 '14 at 12:56











                  • @Daniel Thanks for letting me know, I'm glad you found the culprit. I am not sure if you can delay the start of cron until the partitions are mounted, some of that startup is done in parallel and you would have to change dependencies. I would not want to mess with that and possible break cron. You should IMHO take a different route than crontab & @reboot to run something once on startup as the user.

                    – Anthon
                    Jan 24 '14 at 13:15














                  1












                  1








                  1







                  Take a fresh install of Ubuntu Gnome 13.10 (default user in my case: avanderneut).



                  avanderneut@uggo:~$ crontab -l
                  no crontab for avanderneut
                  avanderneut@uggo:~$ crontab -e
                  no crontab for avanderneut - using an empty one

                  Select an editor. To change later, run 'select-editor'.
                  1. /bin/ed
                  2. /bin/nano <---- easiest
                  3. /usr/bin/vim.tiny

                  Choose 1-3 [2]: 3
                  crontab: installing new crontab
                  avanderneut@uggo:~$ crontab -l | tail -2
                  # m h dom mon dow command
                  @reboot /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ vi /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ more !$
                  more /home/avanderneut/bin/on_reboot
                  #! /bin/bash
                  echo "Reboot script" > /var/tmp/xxx
                  avanderneut@uggo:~$ chmod 755 /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ ls /var/tmp
                  avanderneut@uggo:~$ /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ ls /var/tmp
                  xxx
                  avanderneut@uggo:~$ rm /var/tmp/xxx
                  avanderneut@uggo:~$ sudo reboot
                  [sudo] password for avanderneut:


                  And see that after reboot the file /var/tmp/xxx is there although it was not there before rebooting.



                  This was done with cron version 3.0.



                  You have to make sure that no services discs etc are used that might not be available at the time the script runs. Start with something simple like the above and make sure it has no terminal output as email is probably not up and running.



                  You might aslo need a more up-to-date cron (or an upgrade from oracle-linux) if this did not work for you and you need this feature.






                  share|improve this answer













                  Take a fresh install of Ubuntu Gnome 13.10 (default user in my case: avanderneut).



                  avanderneut@uggo:~$ crontab -l
                  no crontab for avanderneut
                  avanderneut@uggo:~$ crontab -e
                  no crontab for avanderneut - using an empty one

                  Select an editor. To change later, run 'select-editor'.
                  1. /bin/ed
                  2. /bin/nano <---- easiest
                  3. /usr/bin/vim.tiny

                  Choose 1-3 [2]: 3
                  crontab: installing new crontab
                  avanderneut@uggo:~$ crontab -l | tail -2
                  # m h dom mon dow command
                  @reboot /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ vi /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ more !$
                  more /home/avanderneut/bin/on_reboot
                  #! /bin/bash
                  echo "Reboot script" > /var/tmp/xxx
                  avanderneut@uggo:~$ chmod 755 /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ ls /var/tmp
                  avanderneut@uggo:~$ /home/avanderneut/bin/on_reboot
                  avanderneut@uggo:~$ ls /var/tmp
                  xxx
                  avanderneut@uggo:~$ rm /var/tmp/xxx
                  avanderneut@uggo:~$ sudo reboot
                  [sudo] password for avanderneut:


                  And see that after reboot the file /var/tmp/xxx is there although it was not there before rebooting.



                  This was done with cron version 3.0.



                  You have to make sure that no services discs etc are used that might not be available at the time the script runs. Start with something simple like the above and make sure it has no terminal output as email is probably not up and running.



                  You might aslo need a more up-to-date cron (or an upgrade from oracle-linux) if this did not work for you and you need this feature.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jan 18 '14 at 5:44









                  AnthonAnthon

                  61.3k17105168




                  61.3k17105168













                  • I updated my OP to answer your questions. Turns out your suspicion was right from the start: The script to-be-run on reboot resides on a mountable /dev/mapper/VolGroup00-LogVol01 partition.

                    – Withheld
                    Jan 24 '14 at 12:56











                  • @Daniel Thanks for letting me know, I'm glad you found the culprit. I am not sure if you can delay the start of cron until the partitions are mounted, some of that startup is done in parallel and you would have to change dependencies. I would not want to mess with that and possible break cron. You should IMHO take a different route than crontab & @reboot to run something once on startup as the user.

                    – Anthon
                    Jan 24 '14 at 13:15



















                  • I updated my OP to answer your questions. Turns out your suspicion was right from the start: The script to-be-run on reboot resides on a mountable /dev/mapper/VolGroup00-LogVol01 partition.

                    – Withheld
                    Jan 24 '14 at 12:56











                  • @Daniel Thanks for letting me know, I'm glad you found the culprit. I am not sure if you can delay the start of cron until the partitions are mounted, some of that startup is done in parallel and you would have to change dependencies. I would not want to mess with that and possible break cron. You should IMHO take a different route than crontab & @reboot to run something once on startup as the user.

                    – Anthon
                    Jan 24 '14 at 13:15

















                  I updated my OP to answer your questions. Turns out your suspicion was right from the start: The script to-be-run on reboot resides on a mountable /dev/mapper/VolGroup00-LogVol01 partition.

                  – Withheld
                  Jan 24 '14 at 12:56





                  I updated my OP to answer your questions. Turns out your suspicion was right from the start: The script to-be-run on reboot resides on a mountable /dev/mapper/VolGroup00-LogVol01 partition.

                  – Withheld
                  Jan 24 '14 at 12:56













                  @Daniel Thanks for letting me know, I'm glad you found the culprit. I am not sure if you can delay the start of cron until the partitions are mounted, some of that startup is done in parallel and you would have to change dependencies. I would not want to mess with that and possible break cron. You should IMHO take a different route than crontab & @reboot to run something once on startup as the user.

                  – Anthon
                  Jan 24 '14 at 13:15





                  @Daniel Thanks for letting me know, I'm glad you found the culprit. I am not sure if you can delay the start of cron until the partitions are mounted, some of that startup is done in parallel and you would have to change dependencies. I would not want to mess with that and possible break cron. You should IMHO take a different route than crontab & @reboot to run something once on startup as the user.

                  – Anthon
                  Jan 24 '14 at 13:15











                  1














                  I don't know if you have already solved this, or if any of the above was the solution you needed, but another possibility is:



                  if you have your /home directory encrypted, it may not be available until you log in, i.e. it is not available at reboot.



                  in this scenario, you could move your scripts to another location like /srv or /opt or /usr/local/bin/ etc.






                  share|improve this answer




























                    1














                    I don't know if you have already solved this, or if any of the above was the solution you needed, but another possibility is:



                    if you have your /home directory encrypted, it may not be available until you log in, i.e. it is not available at reboot.



                    in this scenario, you could move your scripts to another location like /srv or /opt or /usr/local/bin/ etc.






                    share|improve this answer


























                      1












                      1








                      1







                      I don't know if you have already solved this, or if any of the above was the solution you needed, but another possibility is:



                      if you have your /home directory encrypted, it may not be available until you log in, i.e. it is not available at reboot.



                      in this scenario, you could move your scripts to another location like /srv or /opt or /usr/local/bin/ etc.






                      share|improve this answer













                      I don't know if you have already solved this, or if any of the above was the solution you needed, but another possibility is:



                      if you have your /home directory encrypted, it may not be available until you log in, i.e. it is not available at reboot.



                      in this scenario, you could move your scripts to another location like /srv or /opt or /usr/local/bin/ etc.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Apr 6 '17 at 16:44









                      fbasfbas

                      1265




                      1265























                          0














                          I would say yes for the question. Just had difficulties with running cron on reboot (Debian 3.10.70) and managed to solve with:



                          @reboot root /usr/bin/python3 /path/to/script



                          And a newline character 'n' in the end



                          This is the contents of file:



                          /etc/cron.d/runOnReboot


                          Finally, I think it is worth noting an abstract from man 5 crontab




                          ...
                          The format of a cron command is very much the V7 standard, with a number of upward-compatible extensions. Each line has five time and date
                          fields, followed by a command, followed by a newline character ('n'). The system crontab (/etc/crontab) uses the same format, except that the
                          username for the command is specified after the time and date fields and before the command. The fields may be separated by spaces or tabs. The
                          maximum permitted length for the command field is 998 characters.
                          ...







                          share|improve this answer




























                            0














                            I would say yes for the question. Just had difficulties with running cron on reboot (Debian 3.10.70) and managed to solve with:



                            @reboot root /usr/bin/python3 /path/to/script



                            And a newline character 'n' in the end



                            This is the contents of file:



                            /etc/cron.d/runOnReboot


                            Finally, I think it is worth noting an abstract from man 5 crontab




                            ...
                            The format of a cron command is very much the V7 standard, with a number of upward-compatible extensions. Each line has five time and date
                            fields, followed by a command, followed by a newline character ('n'). The system crontab (/etc/crontab) uses the same format, except that the
                            username for the command is specified after the time and date fields and before the command. The fields may be separated by spaces or tabs. The
                            maximum permitted length for the command field is 998 characters.
                            ...







                            share|improve this answer


























                              0












                              0








                              0







                              I would say yes for the question. Just had difficulties with running cron on reboot (Debian 3.10.70) and managed to solve with:



                              @reboot root /usr/bin/python3 /path/to/script



                              And a newline character 'n' in the end



                              This is the contents of file:



                              /etc/cron.d/runOnReboot


                              Finally, I think it is worth noting an abstract from man 5 crontab




                              ...
                              The format of a cron command is very much the V7 standard, with a number of upward-compatible extensions. Each line has five time and date
                              fields, followed by a command, followed by a newline character ('n'). The system crontab (/etc/crontab) uses the same format, except that the
                              username for the command is specified after the time and date fields and before the command. The fields may be separated by spaces or tabs. The
                              maximum permitted length for the command field is 998 characters.
                              ...







                              share|improve this answer













                              I would say yes for the question. Just had difficulties with running cron on reboot (Debian 3.10.70) and managed to solve with:



                              @reboot root /usr/bin/python3 /path/to/script



                              And a newline character 'n' in the end



                              This is the contents of file:



                              /etc/cron.d/runOnReboot


                              Finally, I think it is worth noting an abstract from man 5 crontab




                              ...
                              The format of a cron command is very much the V7 standard, with a number of upward-compatible extensions. Each line has five time and date
                              fields, followed by a command, followed by a newline character ('n'). The system crontab (/etc/crontab) uses the same format, except that the
                              username for the command is specified after the time and date fields and before the command. The fields may be separated by spaces or tabs. The
                              maximum permitted length for the command field is 998 characters.
                              ...








                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered Feb 27 at 15:28









                              dmytro.poliarushdmytro.poliarush

                              585




                              585























                                  -1














                                  prueba:



                                  usuario@ubuntu:~$ touch script.sh
                                  usuario@ubuntu:~$ chmod +x script.sh



                                  usuario@ubuntu:~$ $crontrab -e



                                  @reboot /home/usuario/script.sh



                                  save and restart your pc






                                  share|improve this answer




























                                    -1














                                    prueba:



                                    usuario@ubuntu:~$ touch script.sh
                                    usuario@ubuntu:~$ chmod +x script.sh



                                    usuario@ubuntu:~$ $crontrab -e



                                    @reboot /home/usuario/script.sh



                                    save and restart your pc






                                    share|improve this answer


























                                      -1












                                      -1








                                      -1







                                      prueba:



                                      usuario@ubuntu:~$ touch script.sh
                                      usuario@ubuntu:~$ chmod +x script.sh



                                      usuario@ubuntu:~$ $crontrab -e



                                      @reboot /home/usuario/script.sh



                                      save and restart your pc






                                      share|improve this answer













                                      prueba:



                                      usuario@ubuntu:~$ touch script.sh
                                      usuario@ubuntu:~$ chmod +x script.sh



                                      usuario@ubuntu:~$ $crontrab -e



                                      @reboot /home/usuario/script.sh



                                      save and restart your pc







                                      share|improve this answer












                                      share|improve this answer



                                      share|improve this answer










                                      answered May 22 '18 at 3:13









                                      gnumangnuman

                                      1




                                      1






























                                          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%2f109804%2fcrontabs-reboot-only-works-for-root%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?