May 22, 200917 yr You could also try modifying the find command to add the -ls switch (which would be the same as the ls -R).
May 22, 200917 yr Rather than guess about what is happening to spin up our disks, check out this post and install inotifywatch. It will tell us what is being accessed: http://lime-technology.com/forum/index.php?topic=3759.msg33490#new I'm currently testing version 1.5 of cache_dirs. It has an improved calculation of a weighted average of scan intervals with far more weight given to recent scans. It also has the explicit scan of the root directories of the share hierarchies. This, I think, is the cause of the spin-ups we are seeing that are not expected. This addition is as of the result of the post made by RobJ a few days ago. I'll post the new version of cache_dirs later today. In the interim, play with inotifywatch. Joe L.
May 22, 200917 yr I'm currently testing version 1.5 of cache_dirs. It has an improved calculation of a weighted average of scan intervals with far more weight given to recent scans. Is version 1.5 of cache_dirs available for download somewhere? The latest version I could find was version 1.4.1 back on page 8. JT
May 22, 200917 yr I'm currently testing version 1.5 of cache_dirs. It has an improved calculation of a weighted average of scan intervals with far more weight given to recent scans. Is version 1.5 of cache_dirs available for download somewhere? The latest version I could find was version 1.4.1 back on page 8. JT Yes... it is attached to this post. Edit: attachment to this post was removed... A much newer version is now available with many improvements and fixes here: http://lime-technology.com/forum/index.php?topic=4500.0 The changes in Version 1.5 are: Added -V to print version number. Added explicit cache of root directories on disks and cache drive Modified "average" scan time statistic to be weighted average of a window of 20 recent scans. Added -a "args" option to allow entry of args to commands after dir/file name example: cache_dirs -a "-ls" -d 3 This will execute "find disk/share -ls -maxdepth 3" The biggest reason for this release is to properly scan the root directories on the disks each time through the scan loop. Previously, it was only scanned once when the cache_dirs commands was started when initially looking for user-share directories. The new "-a" option allows use of additional options to the find command that positionally need to be after the disk/folder name. It allows you to experiment with options to the find command. The "-ls" option to find might give us the same benefit of the "ls -R" with the ability to control the scan depth. The "-noleaf" option might be enough to read in the blocks describing the files into cache. Both of these will slow down the scan times... but you can now experiment and report back your findings to this thread. You would invoke the -a option with its argument in quotes, as follows: cache_dirs -a "-noleaf" -d 5 -e "data" It would execute "find disk/share -noleaf -maxdepth 5" You might want to try either and/or both the "-ls" and "-noleaf" options to the find command. (to use both, do it like this: cache_dirs -a "-noleaf -ls" ) The argument needs to be quoted, otherwise, cache_dirs would try to use it for its own options. The "average" scan time is now weighted, with more recent scans having a much higher weight than older scan times. It uses a sliding window of 20 scan times. This should make it much easier to deal with a long duration initial scan of your directory tree. Lastly, to make it easier cache_dirs -V will print the version number. Have fun. And check out the inotifywatch program I tried in this thread It will let us know EXACTLY which files and folders are being accessed and which might be causing disks to spin up when we thought they were being cached. Warning: I'm adding this note everywhere I made a post regarding this technique of repeatedly accessing directory entries to keep them in the cache. When accessing the disks, using "ls" or "find" or anything else, they are "busy" and unable to be un-mounted. If even one disk is unable to be un-mounted you will not be able to "stop" the array without being caught by a surprise... If what I describe here happens to you, do not panic. What will happen when you press "Stop" is those disks that can be un-mounted will be... the "busy" disk will not be able to be un-mounted. (normally all disks are un-mounted) When unRAID is unable to un-muont all the drives then management interface will not stop the array. Instead, it will show all the disks that could be un-mounted (incorrectly) as Unformatted. The "busy" disk will show as normal. This is frightening when you first encounter it as the management interface even presents a "format" button (whatever you do, do NOT press it). All you need do is press "Stop" once more (or as needed) to catch the added script between its scans when it is sleeping and not accessing a disk. As I said, whatever you do, do not press the "Format" button, as it would try to re-format all the disks it incorrectly thinks are unformatted. (they are not unformatted, just un-mounted, so their file-systems not visible. This is a bug in the display logic of the management interface.) As some point in the future the unRAID interface will be enhanced to terminate these add-on scripts prior to stopping the array, but as of 4.5-beta6 it does not, and you will see the unformatted display in error if you catch a script in the middle of a scan. Again, all you need do is press "Stop" once more (or as needed) to catch the added script between its scans when it is sleeping and not accessing a disk. Joe L. Joe L.
May 22, 200917 yr Joe excellent work. I think this tool either needs a dedicated forum thread so your OP or a project page on Google code or the like as its was beyond a ls -R loop now.
May 22, 200917 yr Excellent tool working great (now that I sorted out my bugs lol)... now if only we could get a usershare/cache transfer speeds back I'll be all set!
May 24, 200917 yr Just got a chance to get this up and running and I have to say this is pretty nice. With that said I seem to be having one problem. I am trying to exclude a couple of directories with spaces in the name. I see that is possible by putting the name of the directory in quotes so that is what I did. When I booted the server back up I received a message about that directory not existing. Now the only thing I can think of that would cause this is if the share is set to hidden. I have both of the user shares that are giving me problems set to export read-write, hidden. Any insight is appreciated. P.S. Great tool Joe.L
May 24, 200917 yr Just got a chance to get this up and running and I have to say this is pretty nice. With that said I seem to be having one problem. I am trying to exclude a couple of directories with spaces in the name. I see that is possible by putting the name of the directory in quotes so that is what I did. When I booted the server back up I received a message about that directory not existing. Now the only thing I can think of that would cause this is if the share is set to hidden. I have both of the user shares that are giving me problems set to export read-write, hidden. Any insight is appreciated. P.S. Great tool Joe.L This tool does not care or use any of the samba permissions,,, so it would not care if it was hidden via samba or not. Joe L.
May 25, 200917 yr I am now satisfied that the "find -noleaf" combination provides exactly what we needed, with the best performance. I would like to ask Joe to consider making it the default, not just an option. I also added it to the find in the root dir scan loop, not because I proved it was necessary (in my preliminary testing), but because it makes sense to me there too. [Technical discussion!] The -noleaf option appears to add back to the find command what was lacking for file browsing, equivalent to the "ls -R" command but with better speed. The -ls option was a good idea, but in my research, it appears to only affect the *output* side of the find command, providing an ls-like styling to what find produces. Although I did NOT test this, nothing I read makes it appear to affect the *input* side of find, affecting what might get cached. In addition to that, the -noleaf option does seem to completely provide what was lacking in the find command, compared to the ls command. And nowhere in the -ls option discussion is any mention of the -noleaf option, or of the stat calls it adds. The -noleaf option was primarily designed for file systems that did not properly set the directory hardlink count. The find command was optimized to quit doing stat calls on entries once it thought it had found all of the directory entries in a folder, and this option was added to force it to assume the count might be wrong and always call stat for each entry. For now, we don't care about that particular problem, although we will when we start using NTFS more as a file system. What we do want cached, for full file browser support, is all entries with all of their stat info, and this option forces it for us. The result appears to be the same as doing an "ls -R" on all folders, but much faster, and of course, find provides the depth options. As to performance changes, my scan times with find alone have been taking about .030 seconds, while "ls -R" takes about .048 seconds. The find command with -noleaf takes about .031 to .032 seconds, a measurable increase, but very small, especially compared with the "ls -R" times. And that is why I recommend making it the default for cache_dirs. Thank you Joe, for all of the changes, that made it easy to run so many tests. I have not yet had a chance to play with inotify. If I had more time, that would probably have provided more definitive results, but I am quite satisfied with how cache_dirs is running right now. I did add a few tweaks to my copy of cache_dirs, not completely necessary, but I'll mention them in a followup post, for your consideration.
May 25, 200917 yr I did add a few tweaks to my copy of cache_dirs, not completely necessary, but I'll mention them here for Joe's consideration. * Allow min = max seconds if [ $max_seconds -lt $min_seconds ] then echo "error: max number of seconds must be greater than or equal min number of seconds." >&2 * Add noleaf to root dir scan for i in /mnt/disk* /mnt/cache $user_share_dir do find $i -maxdepth 1 -noleaf >/dev/null 2>/dev/null done * More concise syslog entries (I prefer no-frills), and add version echo "command args=$commandargs, version=$version max_seconds=$max_seconds, min_seconds=$min_seconds, max_depth=$maxdepth, command=$command $args $log_list" | logger -t$program_name [Rant!] I spent many hours trying to strip the linefeeds out of log_list, using many many variations of sed, tr, "log_list=${dir_list//"\n"/,}", etc, but bash and most or all of these tools are completely married to text management and line editing ONLY. Any byte with a value of 10 is treated as almighty! Bash has some C-like syntax, mostly arithmetic expressions, but is severely deficient in true buffer and byte level string management. I'm not expecting pointers (although they would be great!), but there must be some way to convert all string bytes of one value to another value! All I wanted to do was replace all linefeeds with commas, to get the list on one line only. I could have done this in just a few assembler statements, and it would run on the order of 10 to 20 nanoseconds. I could have used a tiny bit of C, and it would compile mostly to the same register usage but a little more setup and loop cost, and it would run in maybe 100 nanoseconds, but to have to try something like an awk or perl routine means establishing a code segment, a data segment, a stack segment, transfer of control, program initialization, interpretive parsing of the passed commands and args, very inefficient loop execution and memory allocation handling, tear down and return. It's easy to imagine it taking 100's of thousands of nanoseconds! I know most people don't care when it's still a fraction of a second. Since they can't see how much longer it took, it doesn't matter to them. But it does matter to me, and I find it hard to swallow, having to do something that is going to take 10,000 to 100,000 times as long as it could have taken.[/Rant] * Add a crude logging capability. I needed a way to 'look in' on what was currently happening, especially to check the timings, while it is running in the background. After playing with various ideas of how to communicate with a 'disowned' loop, I came up with this simple but crude method. (delete the red, add the blue) [ $background = "no" ] && a=`awk "BEGIN{ printf \\"%f seconds, weighted avg=%f\n\\", ($elapsed_time/1000000000), ($avg_elapsed_time/1000000000) ; }"` [ $background = "no" ] && echo "Executed $command in $a seconds, now sleeping $num_seconds seconds" if [ -f "/var/log/cache_dirs.log" ] then echo "Executed $command in $a seconds, now sleeping $num_seconds seconds" >>/var/log/cache_dirs.log fi I 'turn' logging on by running the following script, called cache_dirs_logon: echo cache_dirs >/var/log/cache_dirs.log tail -f /var/log/cache_dirs.log I turn logging off by Ctl-C, then running the following script, called cache_dirs_logoff: rm /var/log/cache_dirs.log Obviously, it is not something you would want running a long time, but allows a quick monitoring. It could use some optimizing, since it now always runs the awk line, whether the result will be used or not. Crude but works ... This could be turned into a pair of cache_dirs options, perhaps -l to turn logging on, and -L to turn logging off.
May 26, 200917 yr I did add a few tweaks to my copy of cache_dirs, not completely necessary, but I'll mention them here for Joe's consideration. * Allow min = max seconds if [ $max_seconds -lt $min_seconds ] then echo "error: max number of seconds must be greater than or equal min number of seconds." >&2 That woeks for me * Add noleaf to root dir scan for i in /mnt/disk* /mnt/cache $user_share_dir do find $i -maxdepth 1 -noleaf >/dev/null 2>/dev/null done I can see where that might help too * More concise syslog entries (I prefer no-frills), and add version echo "command args=$commandargs, version=$version max_seconds=$max_seconds, min_seconds=$min_seconds, max_depth=$maxdepth, command=$command $args $log_list" | logger -t$program_name [Rant!] I spent many hours trying to strip the linefeeds out of log_list, using many many variations of sed, tr, "log_list=${dir_list//"\n"/,}", etc, but bash and most or all of these tools are completely married to text management and line editing ONLY. Any byte with a value of 10 is treated as almighty! Bash has some C-like syntax, mostly arithmetic expressions, but is severely deficient in true buffer and byte level string management. I'm not expecting pointers (although they would be great!), but there must be some way to convert all string bytes of one value to another value! All I wanted to do was replace all linefeeds with commas, to get the list on one line only. I could have done this in just a few assembler statements, and it would run on the order of 10 to 20 nanoseconds. I could have used a tiny bit of C, and it would compile mostly to the same register usage but a little more setup and loop cost, and it would run in maybe 100 nanoseconds, but to have to try something like an awk or perl routine means establishing a code segment, a data segment, a stack segment, transfer of control, program initialization, interpretive parsing of the passed commands and args, very inefficient loop execution and memory allocation handling, tear down and return. It's easy to imagine it taking 100's of thousands of nanoseconds! I know most people don't care when it's still a fraction of a second. Since they can't see how much longer it took, it doesn't matter to them. But it does matter to me, and I find it hard to swallow, having to do something that is going to take 10,000 to 100,000 times as long as it could have taken.[/Rant] Try this: root@Tower:/boot# echo "this > is > a > test" | tr "\012" "," this,is,a,test, Or, if you do not like the trailing comma, try this echo "this >is >a >test" | paste -s -d "," - this,is,a,test or this slightly more intuitive version, if you insist on using "sed" echo "this >is >a >test >of >joining >lines >of >text" | sed -e :a -e '/$/N' -e 's/\n/,/' -e ta this,is,a,test,of,joining,lines,of,text They all have the capability of dealing with newline characters. * Add a crude logging capability. I needed a way to 'look in' on what was currently happening, especially to check the timings, while it is running in the background. After playing with various ideas of how to communicate with a 'disowned' loop, I came up with this simple but crude method. (delete the red, add the blue) [ $background = "no" ] && a=`awk "BEGIN{ printf \\"%f seconds, weighted avg=%f\n\\", ($elapsed_time/1000000000), ($avg_elapsed_time/1000000000) ; }"` [ $background = "no" ] && echo "Executed $command in $a seconds, now sleeping $num_seconds seconds" if [ -f "/var/log/cache_dirs.log" ] then echo "Executed $command in $a seconds, now sleeping $num_seconds seconds" >>/var/log/cache_dirs.log fi I 'turn' logging on by running the following script, called cache_dirs_logon: echo cache_dirs >/var/log/cache_dirs.log tail -f /var/log/cache_dirs.log I turn logging off by Ctl-C, then running the following script, called cache_dirs_logoff: rm /var/log/cache_dirs.log Obviously, it is not something you would want running a long time, but allows a quick monitoring. It could use some optimizing, since it now always runs the awk line, whether the result will be used or not. Crude but works ... This could be turned into a pair of cache_dirs options, perhaps -l to turn logging on, and -L to turn logging off. Let me think about how that can be most efficiently done. Obviously, your method works. Joe L..
May 26, 200917 yr > test" | tr "\012" "," This worked! I obviously did something wrong when I tried various forms of tr before, although I *thought* I had tried something similar. When I have time, I'll explore and learn from your paste and sed examples. I still have much to learn here.
June 1, 200917 yr Joe any chance of a new version with the new defauls and changes?. (trying not to sound pushy
June 3, 200917 yr Is the command "cache-dirs -q" working for others to terminate this process? It isn't working for me. When I execute this command once I get a message saying that the process is terminating. When I run it again I get a message saying that the process is not currently running. However, if I run "top" I see that the process is still there.
June 3, 200917 yr As far as I know, it has always worked for me, and I have used it a lot(!), while testing.
June 3, 200917 yr Is the command "cache-dirs -q" working for others to terminate this process? It isn't working for me. When I execute this command once I get a message saying that the process is terminating. When I run it again I get a message saying that the process is not currently running. However, if I run "top" I see that the process is still there. You were right... if you use the -q option when it was not running, then it started itself up... It is missing an "exit" statement. around line 130, add the "exit 0" after the line that echos that the program is not currently running. else echo "$program_name ${lock_pid} not currently running " <-- Existing line exit 0 [glow=red,2,300]<-- Line to be added [/glow] fi I'll fix it in the next version.
June 3, 200917 yr OK, maybe I'm doing something wrong then. I added the 'exit 0' line to my cache_dirs and it is working from the command line now. However, I can't get the 'cache_dirs -q' to run from a script. This is my script that I have running as a cron job to notify me of duplicate files and to stop the cache_dirs process to prevent log explosion: #!/bin/bash #http://lime-technology.com/forum/index.php?topic=2306.msg17809#msg17809 DATESTRING=`date '+%b %d %X'` if ! grep "DUPLICATE FILE Email Sent" /var/log/syslog >/dev/null # Only send one notification then halt ls then DUPECOUNT=`grep "duplicate object" /var/log/syslog | cut -d" " -f8- | sed -e "s/^\/\([^\/]*\)\/\([^\/]*\)\/\(.*\)/ls -l \/*\/*\/'\3'/" | sort -u | wc -l` DUPEOBJECT=`grep -m1 "duplicate object" /var/log/syslog | sed -e 's/^.*: \///'` # We're sending and SMS so only show the first duplicate found. if [ "$DUPECOUNT" != "0" ] then # Send SMS Notification echo "unRaid Share Contains Duplicate File: " $DUPEOBJECT | /boot/custom/bin/sms.sh --rcpt [email protected] echo "$DATESTRING UNRAID dupefilelist.sh: DUPLICATE FILE Email Sent" >> /var/log/syslog # Disable cache_dirs if it is running... /boot/custom/bin/cache_dirs -q fi fi To test, I manually created a duplicate file across disks of the share being monitored by cache_dirs. I get notified of the duplicate file, a syslog entry is created recording the fact that an email has been sent, I'm assuming then that the next command to stop the cache_dirs process is then executed. However, the cache_dirs process is still running. I know I'm running the same command in the script as I am at the command line because I copied/pasted from the script when I tested at the command line. Any thoughts?
June 3, 200917 yr I know I'm running the same command in the script as I am at the command line because I copied/pasted from the script when I tested at the command line. Any thoughts? Did you start the original cache_dis from the command line while the array was stopped? Or did you start it from a line in your "go" script upon array reboot? Type the following two commands: cat /var/lock/cache_dirs.LCK ps -efx | grep cache_dirs | grep -v cache_dirs Is the process ID on the first line in the .LCK file the same as in the process list? Lastly, to capture the output of the -q option in your script, change the line to be... /boot/custom/bin/cache_dirs -q >>/var/log/syslog 2>&1 The resulting output might provide a clue. I think I see what is happening... but I want to see what is happening on your system first before attempting a fix. I'm suspecting the lock file has a different process ID than your currently running process. Edit: fixed typo Joe L.
June 3, 200917 yr I start cache_dirs from the unMenu Go Script Manager upon reboot. Here is the contents of my cache_dirs-unmenu-goscript.conf PACKAGE_NAME Start cache_dirs.sh PACKAGE_DESCR Script Start Joe L.'s 'cache_dirs' script Executes /boot/custom/bin/cache_dirs with specific parameters configured to my likeing. PACKAGE_INSTALLATION # Usage: $program_name [-m min_seconds] [-M max_seconds] [-F] [-d maxdepth] [-c command] [-e exclude_dir] [-i include_dir] [-w] PACKAGE_INSTALLATION # $program_name -q PACKAGE_INSTALLATION # -w = wait for array to come online before start of cache scan of directories PACKAGE_INSTALLATION # -m NN = minimum seconds to wait between directory scans (default=1) PACKAGE_INSTALLATION # -M NN = maximum seconds to wait between directory scans (default=10) PACKAGE_INSTALLATION # -F = do NOT run in background, run in Foreground and print statistics as it loops and scans PACKAGE_INSTALLATION # -v = when used with -F, verbose statistics are printed as directories are scanned PACKAGE_INSTALLATION # -s = shorter-log - print count of directories scanned to syslog instead of their names PACKAGE_INSTALLATION # -d NN = use \find -maxdepth NN\ instead of \find -maxdepth 999\ PACKAGE_INSTALLATION # -c command = use command instead of \find\ PACKAGE_INSTALLATION # -u = also scan /mnt/user (scan user shares) PACKAGE_INSTALLATION # (command should be quoted if it has embedded spaces) PACKAGE_INSTALLATION # -e exclude_dir (may be repeated as many times as desired) PACKAGE_INSTALLATION # -i include_dir (may be repeated as many times as desired) PACKAGE_INSTALLATION # -q = terminate any background instance of cache_dirs PACKAGE_INSTALLATION /boot/custom/bin/cache_dirs -w -i "Media" cat /var/lock/cache_dirs.LCK returns: 29969 ps -efx | grep cache_dirs | grep -v cache_dirs returns: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html From what I can tell the problem with the command is with the -v switch. Here are the syslog entries from starting and stopping cache_dirs: Jun 3 08:07:47 UNRAID cache_dirs: ============================================== Jun 3 08:07:47 UNRAID cache_dirs: command-args=-w -i Media Jun 3 08:07:47 UNRAID cache_dirs: max_seconds=10, min_seconds=1 Jun 3 08:07:47 UNRAID cache_dirs: max_depth=9999 Jun 3 08:07:47 UNRAID cache_dirs: command=find Jun 3 08:07:47 UNRAID cache_dirs: ---------- caching directories --------------- Jun 3 08:07:47 UNRAID cache_dirs: Media Jun 3 08:07:47 UNRAID cache_dirs: ---------------------------------------------- Jun 3 08:07:47 UNRAID cache_dirs: cache_dirs process ID 29969 started, To terminate it, type: cache_dirs -q killing cache_dirs process 29969 Jun 3 08:15:50 UNRAID cache_dirs: killing cache_dirs process 29969
June 3, 200917 yr 29969 ps -efx | grep cache_dirs | grep -v cache_dirs returns: I see... it is the length of the returned lines I think, not the -v option, as it is valid the "x" option to ps results in very long lines.... Instead, just type ps -ef | grep cache_dirs
June 4, 200917 yr OK, Just now received an emaiil notifying me that I have a duplicate file in a user share. Executing "ps -ef | grep cache_dirs" yields: root 15080 1 0 13:25 pts/2 00:00:12 /bin/bash /boot/custom/bin/cache_dirs -w -i Media root 32418 32339 59 17:55 ? 00:01:18 /bin/bash -c /boot/custom/bin/cache_dirs My script (see above) should have killed this process. I can't figure out "cache-dirs -q" on the command line works, but run from within a script has no effect. I'm OK with feeling stupid if someone can point out what obvious thing I'm missing. I'd just like to get this to work.
June 4, 200917 yr OK, Just now received an emaiil notifying me that I have a duplicate file in a user share. Executing "ps -ef | grep cache_dirs" yields: root 15080 1 0 13:25 pts/2 00:00:12 /bin/bash /boot/custom/bin/cache_dirs -w -i Media root 32418 32339 59 17:55 ? 00:01:18 /bin/bash -c /boot/custom/bin/cache_dirs My script (see above) should have killed this process. I can't figure out "cache-dirs -q" on the command line works, but run from within a script has no effect. I'm OK with feeling stupid if someone can point out what obvious thing I'm missing. I'd just like to get this to work. And what is in the .LCK file right now. Joe L.
June 4, 200917 yr You have two entirely un-related cache_dirs processes running. One has a parent process ID of 1. It is the one that was detached from the terminal. The other has a parent process ID of 32339. I'll hoping that one you started on the command line, if not, it is an artifact of attempting to put a process in the background and detach it using the goscript manager. It is not the first time an "&" in a script did not work using the goscript manager. In fact, depending on your answer, we might find it is the underlying problem. The lock file will only ever have one process ID in its first line.. and that is the only one it will attempt to kill with the -q option. Since you have two running, there is no way to kill both... at least not with a single "kill" command. What do you see with ps -fp 32339 Joe L.
June 4, 200917 yr I only know enough about this stuff to know that this is interesting: root@UNRAID:~# ps -fp 32339 UID PID PPID C STIME TTY TIME CMD root 32339 32338 0 17:55 ? 00:00:00 /bin/bash /tmp/dupefiletest.sh dupefiletest.sh is the script that contains the command to stop the cache_dirs process (see above). None of this (yet, anyhow) should have anything to do with the Go Script Manager since my most recent instance of cache_dirs was started from the command line.
June 4, 200917 yr It is not the first time an "&" in a script did not work using the goscript manager. In fact, depending on your answer, we might find it is the underlying problem. I must politely disagree... First, the go script manger started the cache_dirs process just like it should have... The script trying to stop the process (dupefiletest.sh) failed to stop the process with the correct command. Secondly, in reference the the previous problems, in the past when I ran just the goscript manager without the TPBA, the uu script to start unmenu presented no problems in the boot sequence. I booted that way many times with no problems. The script execution order on boot was as follows: go file -> individual goscript files... when I added the TPBA, I was having the same problems with the boot sequence hanging at the uu script as others were reporting. The script execution order was: go file -> startup.sh ->S10-custom_install -> individual goscript files. Additionally, the uu script is not the only script to have problems with booting in the TPBA. We have cleaverly (thank you Joe L) added the | at now + 1 minute to deal with these problems without actually looking for the root of the cause. I did some further testing and found that the problem still existed with an execution order of: go file -> startup.sh -> script to invoke uu. this leads me to believe that the issue is either in how the go file invokes the startup.sh script or in how the startup.sh in turn invokes the individual scripts. At that point I just added the | at now + 1 minute to the line to invoke uu and have not had an issue since. Getting back to this individual problem, it seems that the dupefiletest.sh script, instead of initiating a killing of the cache_dirs process and removal of the .LCK file(with the line: /boot/custom/bin/cache_dirs -q), it reports that it is killing the cache_dirs (in the syslog) but does not and hangs. This leaves the original process 15080 (/boot/custom/bin/cache_dirs -w -i Media) running as well as the process started to kill the first, 32418 (/boot/custom/bin/cache_dirs). I hope this will help diagnose the problem. Cheers, Matt
Archived
This topic is now archived and is closed to further replies.