Problem with crontab
up vote
0
down vote
favorite
My script which starts a process and writes the PID of that process to file. This works
as it's supposed to when I execute it from shell:
process & echo $! > /home/xxx/PIDs/process.pid
But when I let cron do that, the process is executed but the PID file is missing.
This is weird to me. What could be wrong?
The cronjob is a simple @reboot trigger. I tried, as Jeff Schaller mentioned,
*/10 * * * * /home/xxx/bin/process & echo $! > /home/xxx/PIDs/process.pid
but this does not work.
bash scripting cron
edited yesterday
Kusalananda
120k16225370
asked yesterday
diggidre
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
0
down vote
favorite
My script which starts a process and writes the PID of that process to file. This works
as it's supposed to when I execute it from shell:
process & echo $! > /home/xxx/PIDs/process.pid
But when I let cron do that, the process is executed but the PID file is missing.
This is weird to me. What could be wrong?
The cronjob is a simple @reboot trigger. I tried, as Jeff Schaller mentioned,
*/10 * * * * /home/xxx/bin/process & echo $! > /home/xxx/PIDs/process.pid
but this does not work.
bash scripting cron
edited yesterday
Kusalananda
120k16225370
asked yesterday
diggidre
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Are you running the command on the command line with the same user whose crontab should execute the job? Do the owner of the crontab get any error messages in their email from cron?
– Kusalananda
yesterday
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
My script which starts a process and writes the PID of that process to file. This works
as it's supposed to when I execute it from shell:
process & echo $! > /home/xxx/PIDs/process.pid
But when I let cron do that, the process is executed but the PID file is missing.
This is weird to me. What could be wrong?
The cronjob is a simple @reboot trigger. I tried, as Jeff Schaller mentioned,
*/10 * * * * /home/xxx/bin/process & echo $! > /home/xxx/PIDs/process.pid
but this does not work.
bash scripting cron
edited yesterday
Kusalananda
120k16225370
asked yesterday
diggidre
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
My script which starts a process and writes the PID of that process to file. This works
as it's supposed to when I execute it from shell:
process & echo $! > /home/xxx/PIDs/process.pid
But when I let cron do that, the process is executed but the PID file is missing.
This is weird to me. What could be wrong?
The cronjob is a simple @reboot trigger. I tried, as Jeff Schaller mentioned,
*/10 * * * * /home/xxx/bin/process & echo $! > /home/xxx/PIDs/process.pid
but this does not work.
bash scripting cron
bash scripting cron
edited yesterday
Kusalananda
120k16225370
asked yesterday
diggidre
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited yesterday
Kusalananda
120k16225370
asked yesterday
diggidre
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited yesterday
Kusalananda
120k16225370
edited yesterday
Kusalananda
120k16225370
edited yesterday
Kusalananda
120k16225370
120k16225370
asked yesterday
diggidre
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked yesterday
diggidre
163
asked yesterday
diggidre
163
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Are you running the command on the command line with the same user whose crontab should execute the job? Do the owner of the crontab get any error messages in their email from cron?
– Kusalananda
yesterday
add a comment |
Are you running the command on the command line with the same user whose crontab should execute the job? Do the owner of the crontab get any error messages in their email from cron?
– Kusalananda
yesterday
Are you running the command on the command line with the same user whose crontab should execute the job? Do the owner of the crontab get any error messages in their email from cron?
– Kusalananda
yesterday
Are you running the command on the command line with the same user whose crontab should execute the job? Do the owner of the crontab get any error messages in their email from cron?
– Kusalananda
yesterday
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
To me it sounds like the user your cron job runs as, does not have permission to write the PID-file to /home/xxx/PIDs/.
This could be the case if e.g. /home is mounted over NFS for example, or perhaps due to things like SELinux.
Try checking local e-mail. In most setup's cron sends error to the local root user by e-mail.
It may also be worth to try running the command as user account xxx by specifying this in the crontab, or login as user xxx and run crontab -e to edit the 'personal' crontab of user xxx.
answered yesterday
Hkoof
1,07768
On most systems,cronwould send an email to the owner of the crontab. If the owner is root, then there should be no permission problem. Also, the user mentions that they are able to run the command on the command line. You answer has merit if it mentions the fact that it's the user that owns the crontab that has to have write permission in the destination directory (the cron daemon itself will not try to write anything).
– Kusalananda
yesterday
I use sudo crontab -e for editing so it's roots cron. I think something is going on with the external hdd. when i reboot i get a unmount fail and system hangs until it fully reboots. that's only the case when a process writes to file when it reboots. I could swear normally it rebooted without this unmount failure.
– diggidre
yesterday
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
yesterday
Not /home is directly mounted as NFS but a subfolder on exHDD is mounted under /home. And that is also the place where the scripts stored. Even tried with users cron but same. I reinstalled cron with purge but old crontab was still there after reinstall. Anyways I'll test now if that helped.
– diggidre
yesterday
add a comment |
up vote
0
down vote
Sry I said scripts are at subfolder on exHDD thats not correct, they are stored in /home/subfolder but doesn't matter anymore.
reinstalling cron does it. Can't figure out why...
answered yesterday
diggidre
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
diggidre is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f489474%2fproblem-with-crontab%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
To me it sounds like the user your cron job runs as, does not have permission to write the PID-file to /home/xxx/PIDs/.
This could be the case if e.g. /home is mounted over NFS for example, or perhaps due to things like SELinux.
Try checking local e-mail. In most setup's cron sends error to the local root user by e-mail.
It may also be worth to try running the command as user account xxx by specifying this in the crontab, or login as user xxx and run crontab -e to edit the 'personal' crontab of user xxx.
answered yesterday
Hkoof
1,07768
On most systems,cronwould send an email to the owner of the crontab. If the owner is root, then there should be no permission problem. Also, the user mentions that they are able to run the command on the command line. You answer has merit if it mentions the fact that it's the user that owns the crontab that has to have write permission in the destination directory (the cron daemon itself will not try to write anything).
– Kusalananda
yesterday
I use sudo crontab -e for editing so it's roots cron. I think something is going on with the external hdd. when i reboot i get a unmount fail and system hangs until it fully reboots. that's only the case when a process writes to file when it reboots. I could swear normally it rebooted without this unmount failure.
– diggidre
yesterday
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
yesterday
Not /home is directly mounted as NFS but a subfolder on exHDD is mounted under /home. And that is also the place where the scripts stored. Even tried with users cron but same. I reinstalled cron with purge but old crontab was still there after reinstall. Anyways I'll test now if that helped.
– diggidre
yesterday
add a comment |
up vote
0
down vote
To me it sounds like the user your cron job runs as, does not have permission to write the PID-file to /home/xxx/PIDs/.
This could be the case if e.g. /home is mounted over NFS for example, or perhaps due to things like SELinux.
Try checking local e-mail. In most setup's cron sends error to the local root user by e-mail.
It may also be worth to try running the command as user account xxx by specifying this in the crontab, or login as user xxx and run crontab -e to edit the 'personal' crontab of user xxx.
answered yesterday
Hkoof
1,07768
On most systems,cronwould send an email to the owner of the crontab. If the owner is root, then there should be no permission problem. Also, the user mentions that they are able to run the command on the command line. You answer has merit if it mentions the fact that it's the user that owns the crontab that has to have write permission in the destination directory (the cron daemon itself will not try to write anything).
– Kusalananda
yesterday
I use sudo crontab -e for editing so it's roots cron. I think something is going on with the external hdd. when i reboot i get a unmount fail and system hangs until it fully reboots. that's only the case when a process writes to file when it reboots. I could swear normally it rebooted without this unmount failure.
– diggidre
yesterday
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
yesterday
Not /home is directly mounted as NFS but a subfolder on exHDD is mounted under /home. And that is also the place where the scripts stored. Even tried with users cron but same. I reinstalled cron with purge but old crontab was still there after reinstall. Anyways I'll test now if that helped.
– diggidre
yesterday
add a comment |
up vote
0
down vote
up vote
0
down vote
To me it sounds like the user your cron job runs as, does not have permission to write the PID-file to /home/xxx/PIDs/.
This could be the case if e.g. /home is mounted over NFS for example, or perhaps due to things like SELinux.
Try checking local e-mail. In most setup's cron sends error to the local root user by e-mail.
It may also be worth to try running the command as user account xxx by specifying this in the crontab, or login as user xxx and run crontab -e to edit the 'personal' crontab of user xxx.
answered yesterday
Hkoof
1,07768
To me it sounds like the user your cron job runs as, does not have permission to write the PID-file to /home/xxx/PIDs/.
This could be the case if e.g. /home is mounted over NFS for example, or perhaps due to things like SELinux.
Try checking local e-mail. In most setup's cron sends error to the local root user by e-mail.
It may also be worth to try running the command as user account xxx by specifying this in the crontab, or login as user xxx and run crontab -e to edit the 'personal' crontab of user xxx.
answered yesterday
Hkoof
1,07768
edited yesterday
answered yesterday
Hkoof
1,07768
answered yesterday
Hkoof
1,07768
answered yesterday
Hkoof
1,07768
1,07768
On most systems,cronwould send an email to the owner of the crontab. If the owner is root, then there should be no permission problem. Also, the user mentions that they are able to run the command on the command line. You answer has merit if it mentions the fact that it's the user that owns the crontab that has to have write permission in the destination directory (the cron daemon itself will not try to write anything).
– Kusalananda
yesterday
I use sudo crontab -e for editing so it's roots cron. I think something is going on with the external hdd. when i reboot i get a unmount fail and system hangs until it fully reboots. that's only the case when a process writes to file when it reboots. I could swear normally it rebooted without this unmount failure.
– diggidre
yesterday
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
yesterday
Not /home is directly mounted as NFS but a subfolder on exHDD is mounted under /home. And that is also the place where the scripts stored. Even tried with users cron but same. I reinstalled cron with purge but old crontab was still there after reinstall. Anyways I'll test now if that helped.
– diggidre
yesterday
add a comment |
On most systems,cronwould send an email to the owner of the crontab. If the owner is root, then there should be no permission problem. Also, the user mentions that they are able to run the command on the command line. You answer has merit if it mentions the fact that it's the user that owns the crontab that has to have write permission in the destination directory (the cron daemon itself will not try to write anything).
– Kusalananda
yesterday
I use sudo crontab -e for editing so it's roots cron. I think something is going on with the external hdd. when i reboot i get a unmount fail and system hangs until it fully reboots. that's only the case when a process writes to file when it reboots. I could swear normally it rebooted without this unmount failure.
– diggidre
yesterday
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
yesterday
Not /home is directly mounted as NFS but a subfolder on exHDD is mounted under /home. And that is also the place where the scripts stored. Even tried with users cron but same. I reinstalled cron with purge but old crontab was still there after reinstall. Anyways I'll test now if that helped.
– diggidre
yesterday
On most systems,
cron would send an email to the owner of the crontab. If the owner is root, then there should be no permission problem. Also, the user mentions that they are able to run the command on the command line. You answer has merit if it mentions the fact that it's the user that owns the crontab that has to have write permission in the destination directory (the cron daemon itself will not try to write anything).– Kusalananda
yesterday
On most systems,
cron would send an email to the owner of the crontab. If the owner is root, then there should be no permission problem. Also, the user mentions that they are able to run the command on the command line. You answer has merit if it mentions the fact that it's the user that owns the crontab that has to have write permission in the destination directory (the cron daemon itself will not try to write anything).– Kusalananda
yesterday
I use sudo crontab -e for editing so it's roots cron. I think something is going on with the external hdd. when i reboot i get a unmount fail and system hangs until it fully reboots. that's only the case when a process writes to file when it reboots. I could swear normally it rebooted without this unmount failure.
– diggidre
yesterday
I use sudo crontab -e for editing so it's roots cron. I think something is going on with the external hdd. when i reboot i get a unmount fail and system hangs until it fully reboots. that's only the case when a process writes to file when it reboots. I could swear normally it rebooted without this unmount failure.
– diggidre
yesterday
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
yesterday
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
yesterday
Not /home is directly mounted as NFS but a subfolder on exHDD is mounted under /home. And that is also the place where the scripts stored. Even tried with users cron but same. I reinstalled cron with purge but old crontab was still there after reinstall. Anyways I'll test now if that helped.
– diggidre
yesterday
Not /home is directly mounted as NFS but a subfolder on exHDD is mounted under /home. And that is also the place where the scripts stored. Even tried with users cron but same. I reinstalled cron with purge but old crontab was still there after reinstall. Anyways I'll test now if that helped.
– diggidre
yesterday
add a comment |
up vote
0
down vote
Sry I said scripts are at subfolder on exHDD thats not correct, they are stored in /home/subfolder but doesn't matter anymore.
reinstalling cron does it. Can't figure out why...
answered yesterday
diggidre
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
0
down vote
Sry I said scripts are at subfolder on exHDD thats not correct, they are stored in /home/subfolder but doesn't matter anymore.
reinstalling cron does it. Can't figure out why...
answered yesterday
diggidre
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
0
down vote
up vote
0
down vote
Sry I said scripts are at subfolder on exHDD thats not correct, they are stored in /home/subfolder but doesn't matter anymore.
reinstalling cron does it. Can't figure out why...
answered yesterday
diggidre
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Sry I said scripts are at subfolder on exHDD thats not correct, they are stored in /home/subfolder but doesn't matter anymore.
reinstalling cron does it. Can't figure out why...
answered yesterday
diggidre
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered yesterday
diggidre
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered yesterday
diggidre
163
answered yesterday
diggidre
163
163
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
diggidre is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
diggidre is a new contributor. Be nice, and check out our Code of Conduct.
diggidre is a new contributor. Be nice, and check out our Code of Conduct.
diggidre is a new contributor. Be nice, and check out our Code of Conduct.
diggidre is a new contributor. Be nice, and check out our Code of Conduct.
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f489474%2fproblem-with-crontab%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Are you running the command on the command line with the same user whose crontab should execute the job? Do the owner of the crontab get any error messages in their email from cron?
– Kusalananda
yesterday