Crontab fails because shell path not found Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)Script not running in crontab, file not foundCan't access shell variable in crontab configurationRemoving Prior CrontabsCrontab script not runningCrontab not running entire script?Crontab env variables while using Dockercronjob cannot find environment variables defined in .bashrcCrontab says command not foundcrontab -e does not open the crontab for this userCannot run python script with cron

Will the Antimagic Field spell cause elementals not summoned by magic to dissipate?

/bin/ls sorts differently than just ls

Assertions In A Mock Callout Test

false 'Security alert' from Google - every login generates mails from 'no-reply@accounts.google.com'

How is an IPA symbol that lacks a name (e.g. ɲ) called?

Why isn't everyone flabbergasted about Bran's "gift"?

How to mute a string and play another at the same time

What kind of equipment or other technology is necessary to photograph sprites (atmospheric phenomenon)

How can I wire a 9-position switch so that each position turns on one more LED than the one before?

Like totally amazing interchangeable sister outfit accessory swapping or whatever

Can a Wizard take the Magic Initiate feat and select spells from the Wizard list?

What is the definining line between a helicopter and a drone a person can ride in?

Can the van der Waals coefficients be negative in the van der Waals equation for real gases?

Help Recreating a Table

How was Lagrange appointed professor of mathematics so early?

Is it OK if I do not take the receipt in Germany?

Putting Ant-Man on house arrest

Who can become a wight?

Converting a text document with special format to Pandas DataFrame

What helicopter has the most rotor blades?

Proving inequality for positive definite matrix

Will I be more secure with my own router behind my ISP's router?

What's the difference between using dependency injection with a container and using a service locator?

Weaponising the Grasp-at-a-Distance spell



Crontab fails because shell path not found



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)Script not running in crontab, file not foundCan't access shell variable in crontab configurationRemoving Prior CrontabsCrontab script not runningCrontab not running entire script?Crontab env variables while using Dockercronjob cannot find environment variables defined in .bashrcCrontab says command not foundcrontab -e does not open the crontab for this userCannot run python script with cron



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








2















I am looking at the failure output of my crontab.



* * * * * user /usr/bin/python3 /home/user/src/code/prod.py


I get the error /bin/sh: 1: caleb: not found.



This corresponds to



X-Cron-Env: <SHELL=/bin/sh>


which is part of the email the crontab sent me. I created the crontab using



crontab -e


All of it looks like a simple setup is there anything that I am missing?










share|improve this question



















  • 3





    When you run crontab -e it is already using your username so there is no need to add your username to the beginning of the command. The only place on the system that you add the username is in the /etc/crontab file.

    – Terrance
    Apr 4 at 14:27











  • @Terrance that fixed my problem. i got my solution from cyberciti.biz/faq/… And I looked at the format and paid no attention to the "for system jobs"

    – caleb baker
    Apr 4 at 14:32


















2















I am looking at the failure output of my crontab.



* * * * * user /usr/bin/python3 /home/user/src/code/prod.py


I get the error /bin/sh: 1: caleb: not found.



This corresponds to



X-Cron-Env: <SHELL=/bin/sh>


which is part of the email the crontab sent me. I created the crontab using



crontab -e


All of it looks like a simple setup is there anything that I am missing?










share|improve this question



















  • 3





    When you run crontab -e it is already using your username so there is no need to add your username to the beginning of the command. The only place on the system that you add the username is in the /etc/crontab file.

    – Terrance
    Apr 4 at 14:27











  • @Terrance that fixed my problem. i got my solution from cyberciti.biz/faq/… And I looked at the format and paid no attention to the "for system jobs"

    – caleb baker
    Apr 4 at 14:32














2












2








2








I am looking at the failure output of my crontab.



* * * * * user /usr/bin/python3 /home/user/src/code/prod.py


I get the error /bin/sh: 1: caleb: not found.



This corresponds to



X-Cron-Env: <SHELL=/bin/sh>


which is part of the email the crontab sent me. I created the crontab using



crontab -e


All of it looks like a simple setup is there anything that I am missing?










share|improve this question
















I am looking at the failure output of my crontab.



* * * * * user /usr/bin/python3 /home/user/src/code/prod.py


I get the error /bin/sh: 1: caleb: not found.



This corresponds to



X-Cron-Env: <SHELL=/bin/sh>


which is part of the email the crontab sent me. I created the crontab using



crontab -e


All of it looks like a simple setup is there anything that I am missing?







16.04 cron






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 5 at 3:54









Community

1




1










asked Apr 4 at 14:23









caleb bakercaleb baker

132




132







  • 3





    When you run crontab -e it is already using your username so there is no need to add your username to the beginning of the command. The only place on the system that you add the username is in the /etc/crontab file.

    – Terrance
    Apr 4 at 14:27











  • @Terrance that fixed my problem. i got my solution from cyberciti.biz/faq/… And I looked at the format and paid no attention to the "for system jobs"

    – caleb baker
    Apr 4 at 14:32













  • 3





    When you run crontab -e it is already using your username so there is no need to add your username to the beginning of the command. The only place on the system that you add the username is in the /etc/crontab file.

    – Terrance
    Apr 4 at 14:27











  • @Terrance that fixed my problem. i got my solution from cyberciti.biz/faq/… And I looked at the format and paid no attention to the "for system jobs"

    – caleb baker
    Apr 4 at 14:32








3




3





When you run crontab -e it is already using your username so there is no need to add your username to the beginning of the command. The only place on the system that you add the username is in the /etc/crontab file.

– Terrance
Apr 4 at 14:27





When you run crontab -e it is already using your username so there is no need to add your username to the beginning of the command. The only place on the system that you add the username is in the /etc/crontab file.

– Terrance
Apr 4 at 14:27













@Terrance that fixed my problem. i got my solution from cyberciti.biz/faq/… And I looked at the format and paid no attention to the "for system jobs"

– caleb baker
Apr 4 at 14:32






@Terrance that fixed my problem. i got my solution from cyberciti.biz/faq/… And I looked at the format and paid no attention to the "for system jobs"

– caleb baker
Apr 4 at 14:32











1 Answer
1






active

oldest

votes


















5














If you are using crontab -e that set of Cron tasks runs as the user which crontab -e was executed as - that is, your user user.



Therefore, you should only provide the cron entry WITHOUT the user bits, i.e.:



* * * * * /usr/bin/python3 /home/user/src/code/prod.py


The user definition you were attempting to use should only be used in the system crontab in /etc/crontab and in entries in cron definitions under /etc/cron.d/.






share|improve this answer

























  • Not to nitpick, but the "cron user" probably has /usr/bin in its $PATH. So, * * * * * python3 /home/user/src/code/prod.py will probably work.

    – Seamus
    Apr 4 at 14:56






  • 2





    @Seamus when using crontabs it's generally better to use full paths just to rule out that problem.

    – Thomas Ward
    Apr 4 at 14:58











  • It's redundant... but I suppose that could be considered "generally better", for some. I'm only trying to point out that the "cron user" does have an environment, and it can be determined if it's not known.

    – Seamus
    Apr 4 at 15:02







  • 1





    @Seamus I often have to explain to people why their jobs that run fine from a bash prompt don't work correctly under cron (or Autosys etc.). I tell them that it's best to use the full path to everything they can, and explicitly set PATH= what they want it to be, rather than rely on "probably".

    – Monty Harder
    Apr 4 at 18:24











Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "89"
;
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%2faskubuntu.com%2fquestions%2f1131213%2fcrontab-fails-because-shell-path-not-found%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









5














If you are using crontab -e that set of Cron tasks runs as the user which crontab -e was executed as - that is, your user user.



Therefore, you should only provide the cron entry WITHOUT the user bits, i.e.:



* * * * * /usr/bin/python3 /home/user/src/code/prod.py


The user definition you were attempting to use should only be used in the system crontab in /etc/crontab and in entries in cron definitions under /etc/cron.d/.






share|improve this answer

























  • Not to nitpick, but the "cron user" probably has /usr/bin in its $PATH. So, * * * * * python3 /home/user/src/code/prod.py will probably work.

    – Seamus
    Apr 4 at 14:56






  • 2





    @Seamus when using crontabs it's generally better to use full paths just to rule out that problem.

    – Thomas Ward
    Apr 4 at 14:58











  • It's redundant... but I suppose that could be considered "generally better", for some. I'm only trying to point out that the "cron user" does have an environment, and it can be determined if it's not known.

    – Seamus
    Apr 4 at 15:02







  • 1





    @Seamus I often have to explain to people why their jobs that run fine from a bash prompt don't work correctly under cron (or Autosys etc.). I tell them that it's best to use the full path to everything they can, and explicitly set PATH= what they want it to be, rather than rely on "probably".

    – Monty Harder
    Apr 4 at 18:24















5














If you are using crontab -e that set of Cron tasks runs as the user which crontab -e was executed as - that is, your user user.



Therefore, you should only provide the cron entry WITHOUT the user bits, i.e.:



* * * * * /usr/bin/python3 /home/user/src/code/prod.py


The user definition you were attempting to use should only be used in the system crontab in /etc/crontab and in entries in cron definitions under /etc/cron.d/.






share|improve this answer

























  • Not to nitpick, but the "cron user" probably has /usr/bin in its $PATH. So, * * * * * python3 /home/user/src/code/prod.py will probably work.

    – Seamus
    Apr 4 at 14:56






  • 2





    @Seamus when using crontabs it's generally better to use full paths just to rule out that problem.

    – Thomas Ward
    Apr 4 at 14:58











  • It's redundant... but I suppose that could be considered "generally better", for some. I'm only trying to point out that the "cron user" does have an environment, and it can be determined if it's not known.

    – Seamus
    Apr 4 at 15:02







  • 1





    @Seamus I often have to explain to people why their jobs that run fine from a bash prompt don't work correctly under cron (or Autosys etc.). I tell them that it's best to use the full path to everything they can, and explicitly set PATH= what they want it to be, rather than rely on "probably".

    – Monty Harder
    Apr 4 at 18:24













5












5








5







If you are using crontab -e that set of Cron tasks runs as the user which crontab -e was executed as - that is, your user user.



Therefore, you should only provide the cron entry WITHOUT the user bits, i.e.:



* * * * * /usr/bin/python3 /home/user/src/code/prod.py


The user definition you were attempting to use should only be used in the system crontab in /etc/crontab and in entries in cron definitions under /etc/cron.d/.






share|improve this answer















If you are using crontab -e that set of Cron tasks runs as the user which crontab -e was executed as - that is, your user user.



Therefore, you should only provide the cron entry WITHOUT the user bits, i.e.:



* * * * * /usr/bin/python3 /home/user/src/code/prod.py


The user definition you were attempting to use should only be used in the system crontab in /etc/crontab and in entries in cron definitions under /etc/cron.d/.







share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 4 at 15:03

























answered Apr 4 at 14:29









Thomas WardThomas Ward

45.4k23125178




45.4k23125178












  • Not to nitpick, but the "cron user" probably has /usr/bin in its $PATH. So, * * * * * python3 /home/user/src/code/prod.py will probably work.

    – Seamus
    Apr 4 at 14:56






  • 2





    @Seamus when using crontabs it's generally better to use full paths just to rule out that problem.

    – Thomas Ward
    Apr 4 at 14:58











  • It's redundant... but I suppose that could be considered "generally better", for some. I'm only trying to point out that the "cron user" does have an environment, and it can be determined if it's not known.

    – Seamus
    Apr 4 at 15:02







  • 1





    @Seamus I often have to explain to people why their jobs that run fine from a bash prompt don't work correctly under cron (or Autosys etc.). I tell them that it's best to use the full path to everything they can, and explicitly set PATH= what they want it to be, rather than rely on "probably".

    – Monty Harder
    Apr 4 at 18:24

















  • Not to nitpick, but the "cron user" probably has /usr/bin in its $PATH. So, * * * * * python3 /home/user/src/code/prod.py will probably work.

    – Seamus
    Apr 4 at 14:56






  • 2





    @Seamus when using crontabs it's generally better to use full paths just to rule out that problem.

    – Thomas Ward
    Apr 4 at 14:58











  • It's redundant... but I suppose that could be considered "generally better", for some. I'm only trying to point out that the "cron user" does have an environment, and it can be determined if it's not known.

    – Seamus
    Apr 4 at 15:02







  • 1





    @Seamus I often have to explain to people why their jobs that run fine from a bash prompt don't work correctly under cron (or Autosys etc.). I tell them that it's best to use the full path to everything they can, and explicitly set PATH= what they want it to be, rather than rely on "probably".

    – Monty Harder
    Apr 4 at 18:24
















Not to nitpick, but the "cron user" probably has /usr/bin in its $PATH. So, * * * * * python3 /home/user/src/code/prod.py will probably work.

– Seamus
Apr 4 at 14:56





Not to nitpick, but the "cron user" probably has /usr/bin in its $PATH. So, * * * * * python3 /home/user/src/code/prod.py will probably work.

– Seamus
Apr 4 at 14:56




2




2





@Seamus when using crontabs it's generally better to use full paths just to rule out that problem.

– Thomas Ward
Apr 4 at 14:58





@Seamus when using crontabs it's generally better to use full paths just to rule out that problem.

– Thomas Ward
Apr 4 at 14:58













It's redundant... but I suppose that could be considered "generally better", for some. I'm only trying to point out that the "cron user" does have an environment, and it can be determined if it's not known.

– Seamus
Apr 4 at 15:02






It's redundant... but I suppose that could be considered "generally better", for some. I'm only trying to point out that the "cron user" does have an environment, and it can be determined if it's not known.

– Seamus
Apr 4 at 15:02





1




1





@Seamus I often have to explain to people why their jobs that run fine from a bash prompt don't work correctly under cron (or Autosys etc.). I tell them that it's best to use the full path to everything they can, and explicitly set PATH= what they want it to be, rather than rely on "probably".

– Monty Harder
Apr 4 at 18:24





@Seamus I often have to explain to people why their jobs that run fine from a bash prompt don't work correctly under cron (or Autosys etc.). I tell them that it's best to use the full path to everything they can, and explicitly set PATH= what they want it to be, rather than rely on "probably".

– Monty Harder
Apr 4 at 18:24

















draft saved

draft discarded
















































Thanks for contributing an answer to Ask Ubuntu!


  • 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%2faskubuntu.com%2fquestions%2f1131213%2fcrontab-fails-because-shell-path-not-found%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

Adding axes to figuresAdding axes labels to LaTeX figuresLaTeX equivalent of ConTeXt buffersRotate a node but not its content: the case of the ellipse decorationHow to define the default vertical distance between nodes?TikZ scaling graphic and adjust node position and keep font sizeNumerical conditional within tikz keys?adding axes to shapesAlign axes across subfiguresAdding figures with a certain orderLine up nested tikz enviroments or how to get rid of themAdding axes labels to LaTeX figures

Luettelo Yhdysvaltain laivaston lentotukialuksista Lähteet | Navigointivalikko

Gary (muusikko) Sisällysluettelo Historia | Rockin' High | Lähteet | Aiheesta muualla | NavigointivalikkoInfobox OKTuomas "Gary" Keskinen Ancaran kitaristiksiProjekti Rockin' High