Problem with crontab
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 Dec 17 at 15:10
Kusalananda
121k16229372
asked Dec 17 at 13:11
diggidre
163
add a comment |
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 Dec 17 at 15:10
Kusalananda
121k16229372
asked Dec 17 at 13:11
diggidre
163
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
Dec 17 at 15:11
add a comment |
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 Dec 17 at 15:10
Kusalananda
121k16229372
asked Dec 17 at 13:11
diggidre
163
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 Dec 17 at 15:10
Kusalananda
121k16229372
asked Dec 17 at 13:11
diggidre
163
edited Dec 17 at 15:10
Kusalananda
121k16229372
asked Dec 17 at 13:11
diggidre
163
edited Dec 17 at 15:10
Kusalananda
121k16229372
edited Dec 17 at 15:10
Kusalananda
121k16229372
edited Dec 17 at 15:10
Kusalananda
121k16229372
121k16229372
asked Dec 17 at 13:11
diggidre
163
asked Dec 17 at 13:11
diggidre
163
asked Dec 17 at 13:11
diggidre
163
163
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
Dec 17 at 15:11
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
Dec 17 at 15:11
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
Dec 17 at 15:11
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
Dec 17 at 15:11
add a comment |
2 Answers
2
active
oldest
votes
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 Dec 17 at 14:48
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
Dec 17 at 15:09
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
Dec 17 at 15:21
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
Dec 17 at 15:30
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
Dec 17 at 15:31
add a comment |
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 Dec 17 at 16:16
diggidre
163
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%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
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 Dec 17 at 14:48
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
Dec 17 at 15:09
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
Dec 17 at 15:21
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
Dec 17 at 15:30
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
Dec 17 at 15:31
add a comment |
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 Dec 17 at 14:48
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
Dec 17 at 15:09
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
Dec 17 at 15:21
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
Dec 17 at 15:30
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
Dec 17 at 15:31
add a comment |
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 Dec 17 at 14:48
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 Dec 17 at 14:48
Hkoof
1,07768
edited Dec 17 at 15:29
answered Dec 17 at 14:48
Hkoof
1,07768
answered Dec 17 at 14:48
Hkoof
1,07768
answered Dec 17 at 14:48
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
Dec 17 at 15:09
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
Dec 17 at 15:21
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
Dec 17 at 15:30
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
Dec 17 at 15:31
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
Dec 17 at 15:09
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
Dec 17 at 15:21
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
Dec 17 at 15:30
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
Dec 17 at 15:31
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
Dec 17 at 15:09
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
Dec 17 at 15:09
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
Dec 17 at 15:21
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
Dec 17 at 15:21
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
Dec 17 at 15:30
@Kusalananda : point taken: cron daemon iself does not try to write to /home/... Edited my answer.
– Hkoof
Dec 17 at 15:30
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
Dec 17 at 15:31
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
Dec 17 at 15:31
add a comment |
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 Dec 17 at 16:16
diggidre
163
add a comment |
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 Dec 17 at 16:16
diggidre
163
add a comment |
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 Dec 17 at 16:16
diggidre
163
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 Dec 17 at 16:16
diggidre
163
answered Dec 17 at 16:16
diggidre
163
answered Dec 17 at 16:16
diggidre
163
answered Dec 17 at 16:16
diggidre
163
163
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Dec 17 at 15:11