Tar stucks while extracting

I am trying to extract tar file of size 167MB but most of the times tar command stuck while extraction.

Command:

new   24389 24369  0 Nov21 ?        00:00:00 tar -xf NCSanJose1_req_rep.tar

While running process with gdb following back trace was obtain:

root@nsdev-10g-1:/home/netstorm/work# gdb -p 24389

(gdb) bt
#0  0x00007f95d8147900 in write () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f95d80da883 in _IO_file_write () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f95d80da74a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007f95d80db1fe in _IO_file_xsputn () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007f95d80af246 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x00007f95d80a9bde in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x00007f95d8152cd5 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#7  0x00007f95d8152e33 in error () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x000000000040dcec in ?? ()
#9  0x000000000040e087 in ?? ()
#10 0x000000000040f6f3 in ?? ()
#11 0x000000000040f8f8 in ?? ()
#12 0x0000000000417df7 in ?? ()
#13 0x00000000004046a6 in ?? ()
#14 0x00007f95d808276d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6

Could anyone please help me to understand why tar command stuck ?

Thanks in advance:)

What happens when you do a tar tvf file first? It should tell you where it wants to write to. First you need to very that it can in fact write to the path inside the tar file with regards to permissions and disk space...

Yes i have verified with -t option, permissions and disk space seems to be fine

What do you mean -t option? What's with the minus???

Please post the exact command you are issuing.
Please post unix/Linux version.
Are you running this command as root? Or a standard user?

Command:

tar -tvf NCSanJose1_req_rep.tar

Linux version: Linux netstorm-X9DRW 3.8.0

I was running this command as standard user

A few more questions I'm afraid.:-

  • What output do you get? Just the last few lines if it's very long.
  • Are you running this on the command line or batched up with the output being collected?

The second point is that tar may only write to a log file every time it fills a block of output, frequently 1024 bytes but not necessarily. This can lead to partial output whilst a restore is still running. On a terminal it should keep going though.

Robin

Commands:

tar -xf NCSanJose1_req_rep.tar

This command was running as part of shell script, which stuck

In order to check tar file with verbose option, command was ran on console which exited successfully.

tar -tvf NCSanJose1_req_rep.tar

Output

-rw-rw-r-- new/new   14176 2014-11-21 18:46 logs/req_rep/url_req_2564_78_78_0_0_0_0_3_0.dat
-rw-rw-r-- new/new    3696 2014-11-21 18:46 logs/req_rep/url_rep_2564_78_78_2_0_0_0_5_0.dat
-rw-rw-r-- new/new   22444 2014-11-21 18:46 logs/req_rep/url_req_2563_81_81_0_0_0_0_136_0.dat
-rw-rw-r-- new/new 1325262 2014-11-21 18:47 logs/req_rep/url_rep_2564_81_81_2_0_0_0_140_0.dat
-rw-rw-r-- new/new    1030 2014-11-21 18:47 logs/req_rep/url_rep_2562_84_84_1_0_0_0_150_0.dat
-rw-rw-r-- new/new     600 2014-11-21 18:46 logs/req_rep/url_rep_body_2561_82_82_4_0_0_0_150_0.dat
-rw-rw-r-- new/new   77492 2014-11-21 18:47 logs/req_rep/url_req_2560_82_82_14_0_0_0_221_0.dat
-rw-rw-r-- new/new 1166136 2014-11-21 18:47 logs/req_rep/url_rep_2564_80_80_9_0_0_0_221_0.dat
-rw-rw-r-- new/new    2206 2014-11-21 18:46 logs/req_rep/url_rep_body_2562_81_81_1_0_0_0_4_0.dat
-rw-rw-r-- new/new  267248 2014-11-21 18:47 logs/req_rep/url_rep_body_2560_84_84_3_0_0_0_140_0.dat
-rw-rw-r-- new/new  191925 2014-11-21 18:46 logs/req_rep/url_rep_body_2564_79_79_0_0_0_0_136_0.dat
-rw-rw-r-- new/new   23619 2014-11-21 18:46 logs/req_rep/url_req_2564_77_77_5_0_0_0_144_0.dat
-rw-rw-r-- new/new 1141907 2014-11-21 18:47 logs/req_rep/url_rep_2563_83_83_0_0_0_0_149_0.dat
-rw-rw-r-- new/new   41867 2014-11-21 18:47 logs/req_rep/url_req_2564_80_80_6_0_0_0_184_0.dat
-rw-rw-r-- new/new      42 2014-11-21 18:47 logs/req_rep/url_rep_body_2563_81_81_8_0_0_0_220_0.dat
-rw-rw-r-- new/new    4242 2014-11-21 18:46 logs/req_rep/url_req_2560_82_82_10_0_0_0_145_0.dat
-rw-rw-r-- new/new  276062 2014-11-21 18:46 logs/req_rep/url_rep_body_2562_81_81_6_0_0_0_139_0.dat

It looks like it's trying to report an error.

What is the entire command used to run tar from inside the script?

What else does the script do?

Is the script run remotely, for example via ssh?

Is the script run by cron or at?

A few more thoughts:-

  • Is there a particularly large file to extract somewhere within the file? It might be that it's running but giving no output for a while.
  • Is the process clocking CPU? Is there anything else running on the server? If not, have a look at the output of iostat 3 3 to see if there is activity.

Does that give you anything?

Robin

You can trace it while running using tusc/truss/strace, properly optioned up for long and full output and the tar pid, to see what it is up to.

The shell script runs remotely with aim is to extract tar content and remove the tar files from remote host machine

extract_scripts()
{
  cd $SCRIPT_PATH/scripts/
  su new -c "tar --no-overwrite-dir -hxzf $SCRIPTS_TAR_FILE"
  su new -c "gzip -fd script.tar.gz"
  su new -c "tar --no-overwrite-dir -hxf script.tar"
  if [ -f abs_path_file.tar.gz ]; then
    su new -c "mv abs_path_file.tar.gz /tmp"
    cd /
    su new -c "gzip -fd /tmp/abs_path_file.tar.gz"
    su new -c "tar --no-overwrite-dir -hxf /tmp/abs_path_file.tar"
  fi
  echo $?
}

This tar file size may vary, on host machine these script directories are created and then bundled in tar. FTP tar to remote host and later initiate extraction.

@Robin -This behavior (tar command stuck) is rare and I have observed CPU, server was not busy and once it happen again will provide the output (iostat 3 3)

Thanks all for help and advice will get back with details.

As a "standard user" the script seems to be untarring from the root ( / ) directory. The paths contained in the tars are relative paths that start with logs/ . So that would means a a regular user, the script is trying to create a directory /logs which I suspect may be failing?

The script is ran from superuser and in order to extract tar files I change directory to target and then un-tar files.

Hence tar path will be created without any error

OK, but in post #5 you said you were running the script as a "standard user". Which version is correct?

Sorry for misleading, but the shell script is ran as root user but please check tar command is ran as standard user.

su new -c "tar --no-overwrite-dir -hxf script.tar"

Try redirecting the stdout and stderr streams from the tar command to files - one for stdout, one for stderr.

Since it seems to be hanging in a write() call invoked by a call to error(), which calls write() via a call to vfprintf(), I think it's most likely hanging trying to write to stderr.

Thanks for suggestion will try at get back with results

Hello,

I tried and was able to recreate issue, i have redirected tar command's stderr and stdout.

tar: home/freebee/work/data/Stress/Stress_SubmitOrderAccounts_UnReg.txt: time stamp 2015-01-06 01:33:50 is 28769.181311346 s in the future
tar: home/freebee/work/data/Stress/Stress1_WebID.txt: time stamp 2015-01-06 01:33:52 is 28771.180911411 s in the future
tar: home/freebee/work/data/Stress/LoggedIn_Account_AddPay.txt: time stamp 2015-01-06 01:33:52 is 28771.180680643 s in the future
tar: home/freebee/work/data/Stress/CatalogId.txt: time stamp 2015-01-06 01:33:48 is 28767.176821988 s in the future
tar: home/freebee/work/data/Stress/Stress_SubmitOrderAccounts_Reg.txt: time stamp 2015-01-06 01:33:50 is 28769.176726251 s in the future
tar: home/freebee/work/data/Stress/Stress1_Prod_SKU.txt: time stamp 2015-01-06 01:33:51 is 28770.176310871 s in the future
tar: home/freebee/work/data/Stress/WebId_SKUID12Sept.txt: time stamp 2015-01-06 01:33:51 is 28770.176042553 s in the future
tar: home/freebee/work/data/Stress/ForgetPass_Account.txt: time stamp 2015-01-06 01:33:52 is 28771.175666481 s in the future
tar: home/freebee/work/data/Stress/WebSku16Oct.txt: time stamp 2015-01-06 01:33:51 is 28770.175545522 s in the future
tar: home/freebee/work/data/Stress/KMCatalogId.txt: time stamp 2015-01-06 01:33:48 is 28767.175477947 s in the future
tar: home/freebee/work/data/Stress/Stress1_SKU.txt: time stamp 2015-01-06 01:33:50 is 28769.175223481 s in the future
tar: home/freebee/work/data/Stress/Stress_LoggedIn_Accounts.txt: time stamp 2015-01-06 01:33:52 is 28771.175149912 s in the future
tar: home/freebee/work/data/Stress/LoggedIn_Account.txt: time stamp 2015-01-06 01:33:52 is 28771.174131207 s in the future
tar: home/freebee/work/data/Stress/Stress_PromoCodes.txt: time stamp 2015-01-06 01:33:50 is 28769.174054509 s in the future
tar: home/freebee/work/data/Stress/PKY_NS1_WebId.txt: time stamp 2015-01-06 01:33:49 is 28768.173991133 s in the future
tar: home/freebee/work/data/Stress/ShipInfo.csv: time stamp 2015-01-06 01:33:50 is 28769.173929333 s in the future
tar: home/freebee/work/data/Stress/LoggedIn_Account_ShipBill.txt: time stamp 2015-01-06 01:33:52 is 28771.173405374 s in the future
tar: home/freebee/work/data/Stress/Stress1_Keywords.txt: time stamp 2015-01-06 01:33:48 is 28767.173143741 s in the future
tar: home/freebee/work/data/Stress/PKY_NS1_SKU.txt: time stamp 2015-01-06 01:33:49 is 28768.173036212 s in the future
tar: home/freebee/work/data/Stress: time stamp 2015-01-06 01:33:52 is 28771.172999897 s in the future
tar: home/freebee/work/data: time stamp 2015-01-06 01:33:48 is 28767.172980362 s in the future
tar: home/freebee/work: time stamp 2015-01-06 01:33:48 is 28767.172961002 s in the future
tar: home/freebee: time stamp 2015-01-06 01:33:48 is 28767.1729435 s in the future
tar: home: Cannot utime: Operation not permitted
tar: home: Cannot change mode to rwxrwxr-x: Operation not permitted
tar: Exiting with failure status due to previous errors

In stderr file these error messages were found

What happens if you try adding the -m option?

$ man tar
-m, --touch
don't extract file modified time

Further to my post#4 have you tried omitting the - from the command line?

 
 tar xf NCSanJose1_req_rep.tar
 

without the minus (-).

Some tar implementations do not treat the inclusion of (-) as optional and the (-) indicates that any flag requiring an argument is immediately followed by that argument.

I'm not expecting this to be a solution but do just try it.