crontab has been corrupted? @^@^@^@^@^ after clone
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
So I have created the following cronjob to run after the VM clones first boot
@reboot sleep 30 && sudo bash /root/first.sh
@reboot sleep 30 && sudo bash /root/first2.sh
However after I clone the VM and boot it back up the scripts don't run and crontab -e shows the following
I am doing the same process on CentOS 6/Ubuntu 14.04 / Ubuntu 16.04 with no problem. Only CentOS 7 is causing an issue.
centos cron
asked May 28 at 2:05
masterq
165
add a comment |Â
up vote
0
down vote
favorite
So I have created the following cronjob to run after the VM clones first boot
@reboot sleep 30 && sudo bash /root/first.sh
@reboot sleep 30 && sudo bash /root/first2.sh
However after I clone the VM and boot it back up the scripts don't run and crontab -e shows the following
I am doing the same process on CentOS 6/Ubuntu 14.04 / Ubuntu 16.04 with no problem. Only CentOS 7 is causing an issue.
centos cron
asked May 28 at 2:05
masterq
165
yes, those are probablyNULcharacters. as to how they got there, we'd need to know a lot more about your process
– thrig
May 28 at 2:23
The scripts? If so I don't think it's them. The screenshot taken was within the first 30 seconds of boot.
– masterq
May 28 at 3:02
There's a whole lot of missing information that this question assumes that we telepathically have, starting with "the" VM clone. There's no information about how this clone operation was done, not even how the machine was shut down in order to clone it.
– JdeBP
May 28 at 3:44
NULcharacters. So the filesystem metadata is there, but the actual data is not. Are you cloning filesystems of an active VM without at least a minimal "flush buffers and quiesce" procedure first? Note that CentOS 7 has XFS as a default filesystem type, unlike CentOS 6 and probably the Ubuntus: your cloning procedure may need some tweaking for it.
– telcoM
May 28 at 5:03
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
So I have created the following cronjob to run after the VM clones first boot
@reboot sleep 30 && sudo bash /root/first.sh
@reboot sleep 30 && sudo bash /root/first2.sh
However after I clone the VM and boot it back up the scripts don't run and crontab -e shows the following
I am doing the same process on CentOS 6/Ubuntu 14.04 / Ubuntu 16.04 with no problem. Only CentOS 7 is causing an issue.
centos cron
asked May 28 at 2:05
masterq
165
So I have created the following cronjob to run after the VM clones first boot
@reboot sleep 30 && sudo bash /root/first.sh
@reboot sleep 30 && sudo bash /root/first2.sh
However after I clone the VM and boot it back up the scripts don't run and crontab -e shows the following
I am doing the same process on CentOS 6/Ubuntu 14.04 / Ubuntu 16.04 with no problem. Only CentOS 7 is causing an issue.
centos cron
asked May 28 at 2:05
masterq
165
asked May 28 at 2:05
masterq
165
asked May 28 at 2:05
masterq
165
asked May 28 at 2:05
masterq
165
165
yes, those are probablyNULcharacters. as to how they got there, we'd need to know a lot more about your process
– thrig
May 28 at 2:23
The scripts? If so I don't think it's them. The screenshot taken was within the first 30 seconds of boot.
– masterq
May 28 at 3:02
There's a whole lot of missing information that this question assumes that we telepathically have, starting with "the" VM clone. There's no information about how this clone operation was done, not even how the machine was shut down in order to clone it.
– JdeBP
May 28 at 3:44
NULcharacters. So the filesystem metadata is there, but the actual data is not. Are you cloning filesystems of an active VM without at least a minimal "flush buffers and quiesce" procedure first? Note that CentOS 7 has XFS as a default filesystem type, unlike CentOS 6 and probably the Ubuntus: your cloning procedure may need some tweaking for it.
– telcoM
May 28 at 5:03
add a comment |Â
yes, those are probablyNULcharacters. as to how they got there, we'd need to know a lot more about your process
– thrig
May 28 at 2:23
The scripts? If so I don't think it's them. The screenshot taken was within the first 30 seconds of boot.
– masterq
May 28 at 3:02
There's a whole lot of missing information that this question assumes that we telepathically have, starting with "the" VM clone. There's no information about how this clone operation was done, not even how the machine was shut down in order to clone it.
– JdeBP
May 28 at 3:44
NULcharacters. So the filesystem metadata is there, but the actual data is not. Are you cloning filesystems of an active VM without at least a minimal "flush buffers and quiesce" procedure first? Note that CentOS 7 has XFS as a default filesystem type, unlike CentOS 6 and probably the Ubuntus: your cloning procedure may need some tweaking for it.
– telcoM
May 28 at 5:03
yes, those are probably
NUL characters. as to how they got there, we'd need to know a lot more about your process– thrig
May 28 at 2:23
yes, those are probably
NUL characters. as to how they got there, we'd need to know a lot more about your process– thrig
May 28 at 2:23
The scripts? If so I don't think it's them. The screenshot taken was within the first 30 seconds of boot.
– masterq
May 28 at 3:02
The scripts? If so I don't think it's them. The screenshot taken was within the first 30 seconds of boot.
– masterq
May 28 at 3:02
There's a whole lot of missing information that this question assumes that we telepathically have, starting with "the" VM clone. There's no information about how this clone operation was done, not even how the machine was shut down in order to clone it.
– JdeBP
May 28 at 3:44
There's a whole lot of missing information that this question assumes that we telepathically have, starting with "the" VM clone. There's no information about how this clone operation was done, not even how the machine was shut down in order to clone it.
– JdeBP
May 28 at 3:44
NUL characters. So the filesystem metadata is there, but the actual data is not. Are you cloning filesystems of an active VM without at least a minimal "flush buffers and quiesce" procedure first? Note that CentOS 7 has XFS as a default filesystem type, unlike CentOS 6 and probably the Ubuntus: your cloning procedure may need some tweaking for it.– telcoM
May 28 at 5:03
NUL characters. So the filesystem metadata is there, but the actual data is not. Are you cloning filesystems of an active VM without at least a minimal "flush buffers and quiesce" procedure first? Note that CentOS 7 has XFS as a default filesystem type, unlike CentOS 6 and probably the Ubuntus: your cloning procedure may need some tweaking for it.– telcoM
May 28 at 5:03
add a comment |Â
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Â
draft saved
draft discarded
Â
draft saved
draft discarded
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%2f446379%2fcrontab-has-been-corrupted-after-clone%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
yes, those are probably
NULcharacters. as to how they got there, we'd need to know a lot more about your process– thrig
May 28 at 2:23
The scripts? If so I don't think it's them. The screenshot taken was within the first 30 seconds of boot.
– masterq
May 28 at 3:02
There's a whole lot of missing information that this question assumes that we telepathically have, starting with "the" VM clone. There's no information about how this clone operation was done, not even how the machine was shut down in order to clone it.
– JdeBP
May 28 at 3:44
NULcharacters. So the filesystem metadata is there, but the actual data is not. Are you cloning filesystems of an active VM without at least a minimal "flush buffers and quiesce" procedure first? Note that CentOS 7 has XFS as a default filesystem type, unlike CentOS 6 and probably the Ubuntus: your cloning procedure may need some tweaking for it.– telcoM
May 28 at 5:03