Why cron trying to change to user's home directory and how to avoid this?
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I've created new system account for cronjob on my centos 7 and set up a cronjob for it.
However my cronjob fails to run with error:
(CRON) ERROR chdir failed (/home/sysagent): No such file or directory
Currently crontab for sysagent account looks like:
15 16 * * * HOME="/tmp" && cd path/to/project_folder && ./src/mainroutine.sh | ts "[%Y-%m-%d %H:%M:%S]" >> /var/log/automation/sysagent.log
I've added HOME variable and cd to project folder after some investigation (used to have full path to shell script there), but it doesn't help. How to make cronjob forget about home directory? And why it's looking for it by the way?
linux centos cron
asked May 8 at 13:35
SMetana
31
add a comment |Â
up vote
0
down vote
favorite
I've created new system account for cronjob on my centos 7 and set up a cronjob for it.
However my cronjob fails to run with error:
(CRON) ERROR chdir failed (/home/sysagent): No such file or directory
Currently crontab for sysagent account looks like:
15 16 * * * HOME="/tmp" && cd path/to/project_folder && ./src/mainroutine.sh | ts "[%Y-%m-%d %H:%M:%S]" >> /var/log/automation/sysagent.log
I've added HOME variable and cd to project folder after some investigation (used to have full path to shell script there), but it doesn't help. How to make cronjob forget about home directory? And why it's looking for it by the way?
linux centos cron
asked May 8 at 13:35
SMetana
31
1
Please edit your question to include the output of the following command:grep '^sysagent' /etc/passwd | awk -F: ' print $6 'That should print the user's home directory.
– Andy Dalton
May 8 at 13:54
It outputs/home/sysagentwhich shouldn't be so because I've created it as system user (adduser -r). I guess just to specify -r option is not enough for making user no-login...
– SMetana
May 8 at 14:01
Might want to try adding aHOME=/tmpline before the15 16 * * *line.
– Mark Plotnick
May 8 at 14:13
I did so on one of tries, it is the same as having it in one line with script call.
– SMetana
May 8 at 14:22
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I've created new system account for cronjob on my centos 7 and set up a cronjob for it.
However my cronjob fails to run with error:
(CRON) ERROR chdir failed (/home/sysagent): No such file or directory
Currently crontab for sysagent account looks like:
15 16 * * * HOME="/tmp" && cd path/to/project_folder && ./src/mainroutine.sh | ts "[%Y-%m-%d %H:%M:%S]" >> /var/log/automation/sysagent.log
I've added HOME variable and cd to project folder after some investigation (used to have full path to shell script there), but it doesn't help. How to make cronjob forget about home directory? And why it's looking for it by the way?
linux centos cron
asked May 8 at 13:35
SMetana
31
I've created new system account for cronjob on my centos 7 and set up a cronjob for it.
However my cronjob fails to run with error:
(CRON) ERROR chdir failed (/home/sysagent): No such file or directory
Currently crontab for sysagent account looks like:
15 16 * * * HOME="/tmp" && cd path/to/project_folder && ./src/mainroutine.sh | ts "[%Y-%m-%d %H:%M:%S]" >> /var/log/automation/sysagent.log
I've added HOME variable and cd to project folder after some investigation (used to have full path to shell script there), but it doesn't help. How to make cronjob forget about home directory? And why it's looking for it by the way?
linux centos cron
asked May 8 at 13:35
SMetana
31
asked May 8 at 13:35
SMetana
31
asked May 8 at 13:35
SMetana
31
asked May 8 at 13:35
SMetana
31
31
1
Please edit your question to include the output of the following command:grep '^sysagent' /etc/passwd | awk -F: ' print $6 'That should print the user's home directory.
– Andy Dalton
May 8 at 13:54
It outputs/home/sysagentwhich shouldn't be so because I've created it as system user (adduser -r). I guess just to specify -r option is not enough for making user no-login...
– SMetana
May 8 at 14:01
Might want to try adding aHOME=/tmpline before the15 16 * * *line.
– Mark Plotnick
May 8 at 14:13
I did so on one of tries, it is the same as having it in one line with script call.
– SMetana
May 8 at 14:22
add a comment |Â
1
Please edit your question to include the output of the following command:grep '^sysagent' /etc/passwd | awk -F: ' print $6 'That should print the user's home directory.
– Andy Dalton
May 8 at 13:54
It outputs/home/sysagentwhich shouldn't be so because I've created it as system user (adduser -r). I guess just to specify -r option is not enough for making user no-login...
– SMetana
May 8 at 14:01
Might want to try adding aHOME=/tmpline before the15 16 * * *line.
– Mark Plotnick
May 8 at 14:13
I did so on one of tries, it is the same as having it in one line with script call.
– SMetana
May 8 at 14:22
1
1
Please edit your question to include the output of the following command:
grep '^sysagent' /etc/passwd | awk -F: ' print $6 ' That should print the user's home directory.– Andy Dalton
May 8 at 13:54
Please edit your question to include the output of the following command:
grep '^sysagent' /etc/passwd | awk -F: ' print $6 ' That should print the user's home directory.– Andy Dalton
May 8 at 13:54
It outputs
/home/sysagent which shouldn't be so because I've created it as system user (adduser -r). I guess just to specify -r option is not enough for making user no-login...– SMetana
May 8 at 14:01
It outputs
/home/sysagent which shouldn't be so because I've created it as system user (adduser -r). I guess just to specify -r option is not enough for making user no-login...– SMetana
May 8 at 14:01
Might want to try adding a
HOME=/tmp line before the 15 16 * * * line.– Mark Plotnick
May 8 at 14:13
Might want to try adding a
HOME=/tmp line before the 15 16 * * * line.– Mark Plotnick
May 8 at 14:13
I did so on one of tries, it is the same as having it in one line with script call.
– SMetana
May 8 at 14:22
I did so on one of tries, it is the same as having it in one line with script call.
– SMetana
May 8 at 14:22
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
0
down vote
accepted
On the assumption the docs are bad or wrong, a source code dive:
% rpm -qa | grep cron
cronie-1.4.11-17.el7.x86_64
cronie-anacron-1.4.11-17.el7.x86_64
crontabs-1.11-6.20121102git.el7.noarch
... some altagoobingleduckgoing here as the URL in the RPM is broken ...
% git clone https://github.com/cronie-crond/cronie && cd cronie
% fgrep -rl 'chdir failed' .
./src/security.c
... so that error only appears in one place, within the cron_change_user_permanently call that is called from various other places in the code ...
% grep cron_change_user_permanently **/*.c
src/do_command.c: if (cron_change_user_permanently(e->pwd, env_get("HOME", jobenv)) < 0)
src/do_command.c: if (cron_change_user_permanently(e->pwd, env_get("HOME", jobenv)) < 0)
src/popen.c: if (cron_change_user_permanently(pw, env_get("HOME", jobenv)) != 0)
src/security.c:int cron_change_user_permanently(struct passwd *pw, char *homedir) {
... so in all cases the HOME environment variable appears to be used to determine where to chdir to for the user, and there is always a chdir to that directory. So you'll need to ensure that the HOME directory exists, or that HOME is properly set before cron_change_user_permanently is called (which likely happens before the shell code in your cron job is even looked at). (Or monkey patch cronie to do something else, but that's probably a really really bad idea.)
answered May 8 at 14:07
thrig
21.9k12751
Wow, that's a thorough investigation. And this definitely answers to first part of my question. So I understand right there is no way to change this behaviour without source code modification (which is not an option of course). My initial idea was to make user non login, so the user should not have $HOME env set (and I read somewhere on stack overflow that -r is the option I need to achieve that, but I can't find any confirmations to that assumption inman adduser). Which should result in error, if I guess right about cron_change_user_permanently behaviour.
– SMetana
May 8 at 14:28
Users that run cron jobs will need aHOMEdirectory and some level of access rights to be able to run cron jobs, though exactly how to achieve that while also preventing logins (remote? by password? ...) will vary.
– thrig
May 8 at 15:25
Not having a valid home directory will not, by itself, prevent an user from logging in: usually they will just be logged in with/as the default directory instead. Having the account locked (i.e. having the password hash field in/etc/shadowcontain only*) won't necessarily prevent that user's cron jobs from being executed, but will prevent any password-based logins. If you have any other login methods, it depends on their configuration: e.g. if you want an account not to be login-able by SSH keys, don't create a~/.ssh/authorized_keysfile for it.
– telcoM
May 8 at 20:24
add a comment |Â
up vote
0
down vote
When cron runs a user's crontab, it'll want to start in the user's
home directory. The initial value of that variable comes from /etc/passwd (in simple cases). By the time you try to override HOME in the crontab entry, cron has tried to change to $HOME.
answered May 8 at 14:05
Andy Dalton
4,7561520
I like both responses but thrig's is more throughout (though the question was rather ill formed as I understand now).
– SMetana
May 8 at 18:50
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
On the assumption the docs are bad or wrong, a source code dive:
% rpm -qa | grep cron
cronie-1.4.11-17.el7.x86_64
cronie-anacron-1.4.11-17.el7.x86_64
crontabs-1.11-6.20121102git.el7.noarch
... some altagoobingleduckgoing here as the URL in the RPM is broken ...
% git clone https://github.com/cronie-crond/cronie && cd cronie
% fgrep -rl 'chdir failed' .
./src/security.c
... so that error only appears in one place, within the cron_change_user_permanently call that is called from various other places in the code ...
% grep cron_change_user_permanently **/*.c
src/do_command.c: if (cron_change_user_permanently(e->pwd, env_get("HOME", jobenv)) < 0)
src/do_command.c: if (cron_change_user_permanently(e->pwd, env_get("HOME", jobenv)) < 0)
src/popen.c: if (cron_change_user_permanently(pw, env_get("HOME", jobenv)) != 0)
src/security.c:int cron_change_user_permanently(struct passwd *pw, char *homedir) {
... so in all cases the HOME environment variable appears to be used to determine where to chdir to for the user, and there is always a chdir to that directory. So you'll need to ensure that the HOME directory exists, or that HOME is properly set before cron_change_user_permanently is called (which likely happens before the shell code in your cron job is even looked at). (Or monkey patch cronie to do something else, but that's probably a really really bad idea.)
answered May 8 at 14:07
thrig
21.9k12751
Wow, that's a thorough investigation. And this definitely answers to first part of my question. So I understand right there is no way to change this behaviour without source code modification (which is not an option of course). My initial idea was to make user non login, so the user should not have $HOME env set (and I read somewhere on stack overflow that -r is the option I need to achieve that, but I can't find any confirmations to that assumption inman adduser). Which should result in error, if I guess right about cron_change_user_permanently behaviour.
– SMetana
May 8 at 14:28
Users that run cron jobs will need aHOMEdirectory and some level of access rights to be able to run cron jobs, though exactly how to achieve that while also preventing logins (remote? by password? ...) will vary.
– thrig
May 8 at 15:25
Not having a valid home directory will not, by itself, prevent an user from logging in: usually they will just be logged in with/as the default directory instead. Having the account locked (i.e. having the password hash field in/etc/shadowcontain only*) won't necessarily prevent that user's cron jobs from being executed, but will prevent any password-based logins. If you have any other login methods, it depends on their configuration: e.g. if you want an account not to be login-able by SSH keys, don't create a~/.ssh/authorized_keysfile for it.
– telcoM
May 8 at 20:24
add a comment |Â
up vote
0
down vote
accepted
On the assumption the docs are bad or wrong, a source code dive:
% rpm -qa | grep cron
cronie-1.4.11-17.el7.x86_64
cronie-anacron-1.4.11-17.el7.x86_64
crontabs-1.11-6.20121102git.el7.noarch
... some altagoobingleduckgoing here as the URL in the RPM is broken ...
% git clone https://github.com/cronie-crond/cronie && cd cronie
% fgrep -rl 'chdir failed' .
./src/security.c
... so that error only appears in one place, within the cron_change_user_permanently call that is called from various other places in the code ...
% grep cron_change_user_permanently **/*.c
src/do_command.c: if (cron_change_user_permanently(e->pwd, env_get("HOME", jobenv)) < 0)
src/do_command.c: if (cron_change_user_permanently(e->pwd, env_get("HOME", jobenv)) < 0)
src/popen.c: if (cron_change_user_permanently(pw, env_get("HOME", jobenv)) != 0)
src/security.c:int cron_change_user_permanently(struct passwd *pw, char *homedir) {
... so in all cases the HOME environment variable appears to be used to determine where to chdir to for the user, and there is always a chdir to that directory. So you'll need to ensure that the HOME directory exists, or that HOME is properly set before cron_change_user_permanently is called (which likely happens before the shell code in your cron job is even looked at). (Or monkey patch cronie to do something else, but that's probably a really really bad idea.)
answered May 8 at 14:07
thrig
21.9k12751
Wow, that's a thorough investigation. And this definitely answers to first part of my question. So I understand right there is no way to change this behaviour without source code modification (which is not an option of course). My initial idea was to make user non login, so the user should not have $HOME env set (and I read somewhere on stack overflow that -r is the option I need to achieve that, but I can't find any confirmations to that assumption inman adduser). Which should result in error, if I guess right about cron_change_user_permanently behaviour.
– SMetana
May 8 at 14:28
Users that run cron jobs will need aHOMEdirectory and some level of access rights to be able to run cron jobs, though exactly how to achieve that while also preventing logins (remote? by password? ...) will vary.
– thrig
May 8 at 15:25
Not having a valid home directory will not, by itself, prevent an user from logging in: usually they will just be logged in with/as the default directory instead. Having the account locked (i.e. having the password hash field in/etc/shadowcontain only*) won't necessarily prevent that user's cron jobs from being executed, but will prevent any password-based logins. If you have any other login methods, it depends on their configuration: e.g. if you want an account not to be login-able by SSH keys, don't create a~/.ssh/authorized_keysfile for it.
– telcoM
May 8 at 20:24
add a comment |Â
up vote
0
down vote
accepted
up vote
0
down vote
accepted
On the assumption the docs are bad or wrong, a source code dive:
% rpm -qa | grep cron
cronie-1.4.11-17.el7.x86_64
cronie-anacron-1.4.11-17.el7.x86_64
crontabs-1.11-6.20121102git.el7.noarch
... some altagoobingleduckgoing here as the URL in the RPM is broken ...
% git clone https://github.com/cronie-crond/cronie && cd cronie
% fgrep -rl 'chdir failed' .
./src/security.c
... so that error only appears in one place, within the cron_change_user_permanently call that is called from various other places in the code ...
% grep cron_change_user_permanently **/*.c
src/do_command.c: if (cron_change_user_permanently(e->pwd, env_get("HOME", jobenv)) < 0)
src/do_command.c: if (cron_change_user_permanently(e->pwd, env_get("HOME", jobenv)) < 0)
src/popen.c: if (cron_change_user_permanently(pw, env_get("HOME", jobenv)) != 0)
src/security.c:int cron_change_user_permanently(struct passwd *pw, char *homedir) {
... so in all cases the HOME environment variable appears to be used to determine where to chdir to for the user, and there is always a chdir to that directory. So you'll need to ensure that the HOME directory exists, or that HOME is properly set before cron_change_user_permanently is called (which likely happens before the shell code in your cron job is even looked at). (Or monkey patch cronie to do something else, but that's probably a really really bad idea.)
answered May 8 at 14:07
thrig
21.9k12751
On the assumption the docs are bad or wrong, a source code dive:
% rpm -qa | grep cron
cronie-1.4.11-17.el7.x86_64
cronie-anacron-1.4.11-17.el7.x86_64
crontabs-1.11-6.20121102git.el7.noarch
... some altagoobingleduckgoing here as the URL in the RPM is broken ...
% git clone https://github.com/cronie-crond/cronie && cd cronie
% fgrep -rl 'chdir failed' .
./src/security.c
... so that error only appears in one place, within the cron_change_user_permanently call that is called from various other places in the code ...
% grep cron_change_user_permanently **/*.c
src/do_command.c: if (cron_change_user_permanently(e->pwd, env_get("HOME", jobenv)) < 0)
src/do_command.c: if (cron_change_user_permanently(e->pwd, env_get("HOME", jobenv)) < 0)
src/popen.c: if (cron_change_user_permanently(pw, env_get("HOME", jobenv)) != 0)
src/security.c:int cron_change_user_permanently(struct passwd *pw, char *homedir) {
... so in all cases the HOME environment variable appears to be used to determine where to chdir to for the user, and there is always a chdir to that directory. So you'll need to ensure that the HOME directory exists, or that HOME is properly set before cron_change_user_permanently is called (which likely happens before the shell code in your cron job is even looked at). (Or monkey patch cronie to do something else, but that's probably a really really bad idea.)
answered May 8 at 14:07
thrig
21.9k12751
answered May 8 at 14:07
thrig
21.9k12751
answered May 8 at 14:07
thrig
21.9k12751
answered May 8 at 14:07
thrig
21.9k12751
21.9k12751
Wow, that's a thorough investigation. And this definitely answers to first part of my question. So I understand right there is no way to change this behaviour without source code modification (which is not an option of course). My initial idea was to make user non login, so the user should not have $HOME env set (and I read somewhere on stack overflow that -r is the option I need to achieve that, but I can't find any confirmations to that assumption inman adduser). Which should result in error, if I guess right about cron_change_user_permanently behaviour.
– SMetana
May 8 at 14:28
Users that run cron jobs will need aHOMEdirectory and some level of access rights to be able to run cron jobs, though exactly how to achieve that while also preventing logins (remote? by password? ...) will vary.
– thrig
May 8 at 15:25
Not having a valid home directory will not, by itself, prevent an user from logging in: usually they will just be logged in with/as the default directory instead. Having the account locked (i.e. having the password hash field in/etc/shadowcontain only*) won't necessarily prevent that user's cron jobs from being executed, but will prevent any password-based logins. If you have any other login methods, it depends on their configuration: e.g. if you want an account not to be login-able by SSH keys, don't create a~/.ssh/authorized_keysfile for it.
– telcoM
May 8 at 20:24
add a comment |Â
Wow, that's a thorough investigation. And this definitely answers to first part of my question. So I understand right there is no way to change this behaviour without source code modification (which is not an option of course). My initial idea was to make user non login, so the user should not have $HOME env set (and I read somewhere on stack overflow that -r is the option I need to achieve that, but I can't find any confirmations to that assumption inman adduser). Which should result in error, if I guess right about cron_change_user_permanently behaviour.
– SMetana
May 8 at 14:28
Users that run cron jobs will need aHOMEdirectory and some level of access rights to be able to run cron jobs, though exactly how to achieve that while also preventing logins (remote? by password? ...) will vary.
– thrig
May 8 at 15:25
Not having a valid home directory will not, by itself, prevent an user from logging in: usually they will just be logged in with/as the default directory instead. Having the account locked (i.e. having the password hash field in/etc/shadowcontain only*) won't necessarily prevent that user's cron jobs from being executed, but will prevent any password-based logins. If you have any other login methods, it depends on their configuration: e.g. if you want an account not to be login-able by SSH keys, don't create a~/.ssh/authorized_keysfile for it.
– telcoM
May 8 at 20:24
Wow, that's a thorough investigation. And this definitely answers to first part of my question. So I understand right there is no way to change this behaviour without source code modification (which is not an option of course). My initial idea was to make user non login, so the user should not have $HOME env set (and I read somewhere on stack overflow that -r is the option I need to achieve that, but I can't find any confirmations to that assumption in
man adduser). Which should result in error, if I guess right about cron_change_user_permanently behaviour.– SMetana
May 8 at 14:28
Wow, that's a thorough investigation. And this definitely answers to first part of my question. So I understand right there is no way to change this behaviour without source code modification (which is not an option of course). My initial idea was to make user non login, so the user should not have $HOME env set (and I read somewhere on stack overflow that -r is the option I need to achieve that, but I can't find any confirmations to that assumption in
man adduser). Which should result in error, if I guess right about cron_change_user_permanently behaviour.– SMetana
May 8 at 14:28
Users that run cron jobs will need a
HOME directory and some level of access rights to be able to run cron jobs, though exactly how to achieve that while also preventing logins (remote? by password? ...) will vary.– thrig
May 8 at 15:25
Users that run cron jobs will need a
HOME directory and some level of access rights to be able to run cron jobs, though exactly how to achieve that while also preventing logins (remote? by password? ...) will vary.– thrig
May 8 at 15:25
Not having a valid home directory will not, by itself, prevent an user from logging in: usually they will just be logged in with
/ as the default directory instead. Having the account locked (i.e. having the password hash field in /etc/shadow contain only *) won't necessarily prevent that user's cron jobs from being executed, but will prevent any password-based logins. If you have any other login methods, it depends on their configuration: e.g. if you want an account not to be login-able by SSH keys, don't create a ~/.ssh/authorized_keys file for it.– telcoM
May 8 at 20:24
Not having a valid home directory will not, by itself, prevent an user from logging in: usually they will just be logged in with
/ as the default directory instead. Having the account locked (i.e. having the password hash field in /etc/shadow contain only *) won't necessarily prevent that user's cron jobs from being executed, but will prevent any password-based logins. If you have any other login methods, it depends on their configuration: e.g. if you want an account not to be login-able by SSH keys, don't create a ~/.ssh/authorized_keys file for it.– telcoM
May 8 at 20:24
add a comment |Â
up vote
0
down vote
When cron runs a user's crontab, it'll want to start in the user's
home directory. The initial value of that variable comes from /etc/passwd (in simple cases). By the time you try to override HOME in the crontab entry, cron has tried to change to $HOME.
answered May 8 at 14:05
Andy Dalton
4,7561520
I like both responses but thrig's is more throughout (though the question was rather ill formed as I understand now).
– SMetana
May 8 at 18:50
add a comment |Â
up vote
0
down vote
When cron runs a user's crontab, it'll want to start in the user's
home directory. The initial value of that variable comes from /etc/passwd (in simple cases). By the time you try to override HOME in the crontab entry, cron has tried to change to $HOME.
answered May 8 at 14:05
Andy Dalton
4,7561520
I like both responses but thrig's is more throughout (though the question was rather ill formed as I understand now).
– SMetana
May 8 at 18:50
add a comment |Â
up vote
0
down vote
up vote
0
down vote
When cron runs a user's crontab, it'll want to start in the user's
home directory. The initial value of that variable comes from /etc/passwd (in simple cases). By the time you try to override HOME in the crontab entry, cron has tried to change to $HOME.
answered May 8 at 14:05
Andy Dalton
4,7561520
When cron runs a user's crontab, it'll want to start in the user's
home directory. The initial value of that variable comes from /etc/passwd (in simple cases). By the time you try to override HOME in the crontab entry, cron has tried to change to $HOME.
answered May 8 at 14:05
Andy Dalton
4,7561520
answered May 8 at 14:05
Andy Dalton
4,7561520
answered May 8 at 14:05
Andy Dalton
4,7561520
answered May 8 at 14:05
Andy Dalton
4,7561520
4,7561520
I like both responses but thrig's is more throughout (though the question was rather ill formed as I understand now).
– SMetana
May 8 at 18:50
add a comment |Â
I like both responses but thrig's is more throughout (though the question was rather ill formed as I understand now).
– SMetana
May 8 at 18:50
I like both responses but thrig's is more throughout (though the question was rather ill formed as I understand now).
– SMetana
May 8 at 18:50
I like both responses but thrig's is more throughout (though the question was rather ill formed as I understand now).
– SMetana
May 8 at 18:50
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f442547%2fwhy-cron-trying-to-change-to-users-home-directory-and-how-to-avoid-this%23new-answer', 'question_page');
);
Post as a guest
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
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
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
1
Please edit your question to include the output of the following command:
grep '^sysagent' /etc/passwd | awk -F: ' print $6 'That should print the user's home directory.– Andy Dalton
May 8 at 13:54
It outputs
/home/sysagentwhich shouldn't be so because I've created it as system user (adduser -r). I guess just to specify -r option is not enough for making user no-login...– SMetana
May 8 at 14:01
Might want to try adding a
HOME=/tmpline before the15 16 * * *line.– Mark Plotnick
May 8 at 14:13
I did so on one of tries, it is the same as having it in one line with script call.
– SMetana
May 8 at 14:22