Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › Very Odd Bash Script Behavior
New Posts  All Forums:Forum Nav:

Very Odd Bash Script Behavior

post #1 of 6
Thread Starter 
I have a bash script that loops updating newsgroups for my indexer. Once the index finishes checking that newsgroup, it will print the current time and sleep for 30 minutes before checking the newsgroup again. All output is sent to a plain text file.

Initially, I had it echo "Waiting 30 minutes..." rather than echo the current time. I now have a script that simply checks the end of each text file for each newsgroup and prints either "In Progress" and the amount of articles still in queue, or the current timestamp to show the newsgroup finished and the script is sleeping. It does this by simply cutting the last line, and if it's a timestamp it prints that, otherwise it uses cut to just print the remaining articles.


However, like I said before the time stamp I used "Waiting 30 minutes..." and for some newsgroups the script is still printing "Waiting 30 minutes...". That echo line is nowhere in the script anymore. I have stopped and restarted the script several times, and it still prints Waiting 30 minutes... rather than the time. I have deleted both the target text files and moved the script to a new name, deleted the original and renamed the copy back to the proper name in an effort to see if for some reason it was an underlying FS issue with the inode.

Nothing changes. I am utterly confused because the script is printing messages that are literally nowhere in the script anymore.
    
CPUMotherboardGraphicsRAM
Core i7 970 @ 4.0 GHz 1.22 Vcore Asus Rampage II Gene GTX 260 216SP G.SKILL PI 3x2gb DDR3 1600 @ 7-8-7-24 
Hard DriveOSMonitorPower
2x 500gb Seagates RAID 0, 1x 500gb non-RAID Windows 7 Professional x64 ASUS 24'' VH242H / Spectre 24'' WS Corsair 750TX 
Case
Corsair 300R 
  hide details  
Reply
    
CPUMotherboardGraphicsRAM
Core i7 970 @ 4.0 GHz 1.22 Vcore Asus Rampage II Gene GTX 260 216SP G.SKILL PI 3x2gb DDR3 1600 @ 7-8-7-24 
Hard DriveOSMonitorPower
2x 500gb Seagates RAID 0, 1x 500gb non-RAID Windows 7 Professional x64 ASUS 24'' VH242H / Spectre 24'' WS Corsair 750TX 
Case
Corsair 300R 
  hide details  
Reply
post #2 of 6
Why don't you run it as a cron job set for X intervals? That way you don't have to program wait times.
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
post #3 of 6
Thread Starter 
Quote:
Originally Posted by mushroomboy View Post

Why don't you run it as a cron job set for X intervals? That way you don't have to program wait times.

Because new articles are posted randomly and can be in large bulk.

Look at it this way:

If I cron it to run every hour, and the first hour it goes off fine, but at the second hour a huge amount of articles are posted, which pushes the update over an hour run time - so any articles posted between when the update first starts and hour four are compounded which will push back the updates during the next update, etc..

By having it run a timer after the update finishes, the indexer can push releases quicker and the backlog is better managed.
    
CPUMotherboardGraphicsRAM
Core i7 970 @ 4.0 GHz 1.22 Vcore Asus Rampage II Gene GTX 260 216SP G.SKILL PI 3x2gb DDR3 1600 @ 7-8-7-24 
Hard DriveOSMonitorPower
2x 500gb Seagates RAID 0, 1x 500gb non-RAID Windows 7 Professional x64 ASUS 24'' VH242H / Spectre 24'' WS Corsair 750TX 
Case
Corsair 300R 
  hide details  
Reply
    
CPUMotherboardGraphicsRAM
Core i7 970 @ 4.0 GHz 1.22 Vcore Asus Rampage II Gene GTX 260 216SP G.SKILL PI 3x2gb DDR3 1600 @ 7-8-7-24 
Hard DriveOSMonitorPower
2x 500gb Seagates RAID 0, 1x 500gb non-RAID Windows 7 Professional x64 ASUS 24'' VH242H / Spectre 24'' WS Corsair 750TX 
Case
Corsair 300R 
  hide details  
Reply
post #4 of 6
Quote:
Originally Posted by TurboTurtle View Post

Because new articles are posted randomly and can be in large bulk.

Look at it this way:

If I cron it to run every hour, and the first hour it goes off fine, but at the second hour a huge amount of articles are posted, which pushes the update over an hour run time - so any articles posted between when the update first starts and hour four are compounded which will push back the updates during the next update, etc..

By having it run a timer after the update finishes, the indexer can push releases quicker and the backlog is better managed.

So have the top of the script check to see if the script is already running and exit 1 if it is.

As for while you're getting output that doesn't exist in code, is there old versions of the script that's still running which you've forgotten to sigterm?
post #5 of 6
Quote:
Originally Posted by Plan9 View Post

So have the top of the script check to see if the script is already running and exit 1 if it is.

As for while you're getting output that doesn't exist in code, is there old versions of the script that's still running which you've forgotten to sigterm?

Agree with that. You can capture the PID at startup via $$ and write it to a file, then the script checks to see if the PID in the pidfile is there. If it is you exit.

I also agree that there is probably an old version of the script running somewhere. Make sure the current version of the script isn't running then use pkill to kill anything still hanging out there. Or just reboot the system, whichever you want.
post #6 of 6
I'm running my index updates on a */15 in cron. Really no issues with too many articles coming up and slowing it down.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Linux, Unix
Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › Very Odd Bash Script Behavior