Kan dit quick & dirty script een server laten freezen?

[demichel]

Ik heb een Red Hat Linux server staan. Hier wordt onder /var5/users/app een file geschreven vanuit Oracle. Die file moet opgepikt worden door een machine in de fabriek, die deze file moet gaan aanpassen.

Lang verhaal kort: de rechten moeten 777 zijn, en doordat de file door user oracle geschreven werd, is die niet zo. Nu kan ik dat wellicht met umask regelen maar heb dit nog nooit gedaan, had geen tijd om dit uit te zoeken (want "ze" staan te wachten in de fabriek om te werken) dus heb ik maar snel een quick & dirty scriptje geschreven als volgt (naam scirpt is chmod_app.sh):

date >>/home/oracle/chmod.log
sleep 5
chmod -R 777 /var5/users/app
./chmod_app.sh

... en laat dit een terminal venster op de server draaien...

Niet bepaald de mooiste code die ik ooit geschreven heb en ik ben er niet echt trots op, maar maandag was dit voldoende om de machine werkende te krijgen. ... met in het achterhoofd, "ik los dat straks wel proper op met umask", maar deze week de tijd niet gevonden.

So far so good... of niet...

Nu begint deze server iedere nacht vast te lopen. Hij "bevriest" gewoon. Begonnen met alle crontabs uit te schakelen, alle automatische Oracle jobs,... tot er voor zover ik weet niks meer draait op deze machine op het chmod_app.sh script na. Toch "bevriest" ze iedere nacht en een hard shutdown is het enige wat werkt.

Tot vanmorgen had ik de link nog niet gelegd naar het chmod_app.sh script, dat dus wel nog draaide gedurende de nacht. Nu ben ik de logfile met de datums die ik laat bijhouden eens gaan bestuderen. Daar zou om de 5 seconden een tijdstempel moeten in staan. Daar vind ik echter iets onverwachts:

-gisteren gedurende de hele dag verschijnen de tijdstempels om de 5 seconden.
-om 01.30 vannacht begint er 7 seconden tussen te zitten (alhoewel er een sleep 5 in het script staat)
-om 01.50 is dat al 11 seconden
-om 01.52 duurt het 4 minuten voor de volgende tijdstempel verschijnt
-om 02.06 duurt het 8 minuten voor de volgende tijdstempel verschijnt
-gaat naar interval van 12 minuten tot de loggings helemaal stoppen rond 03.30
-deze morgen was de server opnieuw "bevroren" en hielp enkel maar een hard shutdown

Is inderdaad een dirty script, maar kan dit de oorzaak zijn van de problemen? Door het continue zichzelf oproepen, kunnen daardoor system ressources "verloren" gaan zodat het tenslotte plots helemaal stopt?

Ik zoek in ieder geval vandaag de correcte oplossing met umask...

[mace]

777 is nooit de correcte oplossing......

En als de je umask van de oracle user aanpast gaan ALLE files die oracle aanmaakt 777 worden, en dat wil je écht niet.

En dit soort dingen los je dus gewoon op met cron, en niet een scriptje wat zichzelf recursief aanroept.

Je start een proces binnen een proces binnen een proces binnen een proces etc....

[ Voor 37% gewijzigd door mace op 25-05-2012 09:10 ]

[demichel]

mace schreef op vrijdag 25 mei 2012 @ 09:08:
777 is nooit de correcte oplossing......

En als de je umask van de oracle user aanpast gaan ALLE files die oracle aanmaakt 777 worden, en dat wil je écnt niet.

Dank voor je antwoord!

Heb je gelijk in, 777 is quick&dirty maar nog niet de tijd gehad om alles proper te regelen. Prioriteit #1 nu is zorgen dat a) die machine die aangestuurd moet worden, kan blijven functioneren en b) te vermijden dat de server 's nachts freezes... daarna kan ongetwijfeld wel een betere oplossing gevonden worden om die ene file de nodige rechten te geven.

mace schreef op vrijdag 25 mei 2012 @ 09:08:
En dit soort dingen los je dus gewoon op met cron, en niet een scriptje wat zichzelf recursief aanroept.

Je start een proces binnen een proces binnen een proces binnen een proces etc....

En daar heb je ook gelijk in. Had dit eerst met een crontab opgelost, maar voor zover ik begrepen heb, is het minimum interval 1 minuut en zo lang kunnen ze niet wachten bij de machine. De verwerking wordt in een Oracle form aangevraagd en binnen de paar seconden (5 nu, dus) moet de machine in werking treden.

[ Voor 32% gewijzigd door demichel op 25-05-2012 09:12 ]

[mace]

Bash:

#!/bin/bash

while true; do
  date >>/home/oracle/chmod.log
  chmod -R 777 /var5/users/app
  sleep 5
done

Zoiets. Loops zijn er niet voor niks.

[ Voor 157% gewijzigd door mace op 25-05-2012 09:17 ]

[Big Womly]

Zoek eens op of probeer eens uit of een script verder loopt wanneer het een ander script opstart?
Indien niet, dan blijft elke keer je script nog actief totdat het de herstart heeft afgewerkt, wat dus nooit gebeurd...

Het lijkt me trouwens sowieso handiger om een while(true) lusje erin te steken

[RemcoDelft]

Big Womly schreef op vrijdag 25 mei 2012 @ 09:12:
Zoek eens op of probeer eens uit of een script verder loopt wanneer het een ander script opstart?

Dit lijkt me inderdaad de oorzaak. Teveel processen, daardoor traag om nieuwe te starten, vervolgens gaat het mis.

Het lijkt me trouwens sowieso handiger om een while(true) lusje erin te steken

while test 1
do echo 'Hello world'
done

Klaar
Of zet een &-tekentje achter de aanroep van het scriptje zelf.

*Edit*: in mijn ervaring is een van de beste manieren om een Tux compleet non-responsive te krijgen hem out of memory te laten lopen, zelfs als user. Mijn Skype doet dat (sinds de overname door MS, heel toevallig ) bijvoorbeeld regelmatig op m'n laptop. De kernel gaat dan uiteindelijk een proces uitkiezen om te killen, maar pas na zeer lang swappen waarbij er geen enkele reactie komt op keyboard-input.

[ Voor 27% gewijzigd door RemcoDelft op 25-05-2012 09:16 ]

[croontje]

ALs je een cron laat lopen elke minuut met volgende regels 12 keer in je script:

date >>/home/oracle/chmod.log
sleep 5

Dan heb je toch via cron om de 5 seconden je output en je moet je script niet zichzelf laten oproepen...

[demichel]

croontje schreef op vrijdag 25 mei 2012 @ 09:15:
ALs je een cron laat lopen elke minuut met volgende regels 12 keer in je script:

date >>/home/oracle/chmod.log
sleep 5

Dan heb je toch via cron om de 5 seconden je output en je moet je script niet zichzelf laten oproepen...

Briljant! Heel wat beter dan mijn quick&dirty "oplossing"...

[mace]

demichel schreef op vrijdag 25 mei 2012 @ 09:16:
[...]


Briljant! Heel wat beter dan mijn quick&dirty "oplossing"...

Loopje is toch wat netter.

[demichel]

mace schreef op vrijdag 25 mei 2012 @ 09:17:
[...]

Loopje is toch wat netter.

Sorry mace, had je post niet gezien met de loop. Die is inderdaad netter.

Ik moet dringend eens die opfrissingscursus Unix/Linux gaan volgen... mijn IT-schooltijd op dat vlak is heeeuuul lang geleden en dus grijp ik naar dergelijke oplossingen... Op Oracle vlak kom ik meestal wel wat sterker uit de hoek

[Paul]

Een cron-job boven een loopje heeft als voordeel dat
1) Als het om wat voor reden dan ook stopt wordt het vlak daarna toch weer uitgevoerd
2) Je hoeft geen terminal (of screen-sessie) open te laten staan

[mace]

demichel schreef op vrijdag 25 mei 2012 @ 09:19:
[...]


Sorry mace, had je post niet gezien met de loop. Die is inderdaad netter.

Ik moet dringend eens die opfrissingscursus Unix/Linux gaan volgen... mijn IT-schooltijd op dat vlak is heeeuuul lang geleden en dus grijp ik naar dergelijke oplossingen... Op Oracle vlak kom ik meestal wel wat sterker uit de hoek

Ja begrijp me niet verkeerd maar dat kun je wel gebruiken.

[demichel]

mace schreef op vrijdag 25 mei 2012 @ 09:21:
[...]

Ja begrijp me niet verkeerd maar dat kun je wel gebruiken.

Is reeds actief as we speak!

Paul heeft dan wel ook weer een punt over de voordelen van een crontab.

[ Voor 15% gewijzigd door demichel op 25-05-2012 09:22 ]

[croontje]

Of een loopje van 12 met een sleep van 5 in 1 cronjob

[mace]

demichel schreef op vrijdag 25 mei 2012 @ 09:21:
[...]


Is reeds actief as we speak!

Paul heeft dan wel ook weer een punt over de voordelen van een crontab.

Is inderdaad wat voor te zeggen. Dan kun je zoiets doen:

code:

#!/bin/bash

for $i in $seq (1 12); do
  date >>/home/oracle/chmod.log
  chmod -R 777 /var5/users/app
  sleep 5
done

En dat dan elke minuut in de crontab.

e:

croontje schreef op vrijdag 25 mei 2012 @ 09:24:
Of een loopje van 12 met een sleep van 5 in 1 cronjob

Met stom. (Ik mis steeds posts).

[ Voor 18% gewijzigd door mace op 25-05-2012 09:26 ]

[Sendy]

Dit is ook gek. Want er zitten misschien wel 12 * 5 seconden in een minuut, maar het schrijven van "date", en de chmod kosten ook tijd. Het script gaat vroeg of laat scheef lopen, en zullen er soms twee scripts tegelijkertijd draaien.

[demichel]

Sendy schreef op vrijdag 25 mei 2012 @ 09:34:
Dit is ook gek. Want er zitten misschien wel 12 * 5 seconden in een minuut, maar het schrijven van "date", en de chmod kosten ook tijd. Het script gaat vroeg of laat scheef lopen, en zullen er soms twee scripts tegelijkertijd draaien.

Je bedoelt dan als dit in een crontab draait??

[Paul]

Tenzij 12x date en 12x chmod meer dan 5 seconden duurt Duurt het 4 seconde dan zit er tussen de 12e en 13e keer maar één seconde, maar als één date (plus stdout redirect to file) en één chmod meer dan 330 ms duurt dan heb je mijns inziens een groter probleem op je databaseserver...

[swbr]

Is het niet veel veiliger om te zorgen dat of Oracle die file wegschrijft met de juiste permissies of ownership, of om te zorgen dat de machine die het bestand ophaalt dat gewoon kan?

Welk mechanisme wordt er gebruikt om die file op te halen? NFS, ftp, scp, iets anders?

[sam.vimes]

mace schreef op vrijdag 25 mei 2012 @ 09:25:
[...]
Dan kun je zoiets doen:

code:

#!/bin/bash

for i in $seq (1 12); do
  date >>/home/oracle/chmod.log
  chmod -R 777 /var5/users/app
  sleep 5
done

[...]

Volgens mij bedoel je:

code:

#!/bin/bash

for $i in $(seq 1 12); do
  date >>/home/oracle/chmod.log
  chmod -R 777 /var5/users/app
  sleep 5
done

(regel 3)

Maar afhankelijk van de grootte van /var5/users/app duurt de recursieve chmod mogelijk langer dan 5/12 seconde en dan krijg je dat na een minuut steeds twee cronjobs elkaar gaan overlappen omdat de eerste nog niet klaar is terwijl de tweede al begint.

[ Voor 0% gewijzigd door sam.vimes op 07-02-2014 16:26 . Reden: copy/paste error ]

[Sendy]

Paul schreef op vrijdag 25 mei 2012 @ 09:40:
Tenzij 12x date en 12x chmod meer dan 5 seconden duurt Duurt het 4 seconde dan zit er tussen de 12e en 13e keer maar één seconde, maar als één date (plus stdout redirect to file) en één chmod meer dan 330 ms duurt dan heb je mijns inziens een groter probleem op je databaseserver...

Klopt, het lijkt in dit script niet zozeer een probleem. Het is wel een probleem als je iets voor en iets na de sleep uitvoert.

Vergelijk hiervoor het script in de topicstart en de gesuggereerde oplossingen:

code:

date >>/home/oracle/chmod.log
sleep 5
chmod -R 777 /var5/users/app
./chmod_app.sh

en

code:

#!/bin/bash

for $i in $(seq 1 12); do
  date >>/home/oracle/chmod.log
  chmod -R 777 /var5/users/app
  sleep 5
done

Het verschil is dat het eerste script doet (effectief)

code:

date >>/home/oracle/chmod.log
sleep 5
chmod -R 777 /var5/users/app
date >>/home/oracle/chmod.log
sleep 5
chmod -R 777 /var5/users/app
date >>/home/oracle/chmod.log
sleep 5
chmod -R 777 /var5/users/app

en de nieuwe scripts

code:

date >>/home/oracle/chmod.log
chmod -R 777 /var5/users/app
sleep 5
date >>/home/oracle/chmod.log
chmod -R 777 /var5/users/app
sleep 5
date >>/home/oracle/chmod.log
chmod -R 777 /var5/users/app
sleep 5

Na ja, alles kan altijd beter

[demichel]

En natuurlijk, dank voor jullie hulp!

[Mijzelf]

Je kunt je oude script ook gewoon gebruiken, met een kleine aanpassing:

code:

date >>/home/oracle/chmod.log
sleep 5
chmod -R 777 /var5/users/app
exec ./chmod_app.sh

Die 'exec' zorgt dat voor het 'nieuwe' script geen nieuw proces wordt aangemaakt, maar hij gaat inplaats van het oude script draaien.
Dat is wel minder efficient dan een loop, aangezien wel een nieuwe shell wordt gestart en de oude wordt beeindigd, en het script wordt iedere keer weer geparsed, en ...

[mdartu]

Wellicht is het anders een idee om te kijken naar een inotify-based cron systeem. Dit kan opdrachten uitvoeren op basis van filesystem events in plaats van tijd. Zoiets bijvoorbeeld

[ Voor 0% gewijzigd door mdartu op 25-05-2012 15:51 . Reden: typo ]

[w.l]

Als die sleep 5 in de laatste iteratie van de for loop een probleem is, dan voeg je toch gewoon een if statement toe?

code:

#!/bin/bash

for $i in $(seq 1 12); do
  date >>/home/oracle/chmod.log
  chmod -R 777 /var5/users/app
  if [$i -ne 12]
  then
    sleep 5
  fi
done

(Ik ben niet zeker of de syntax volledig klopt.)

[Hero of Time]

Als het zo specifiek 777 moet zijn op de bestanden ipv 666 (wat maakt de execute bit voor verschil? Het is toch niet zo dat de machine de bestanden moet uitvoeren?), kan je de map net zo goed mask 2777 geven, ben je van 't hele script gedonder af. Of had je dat al geprobeerd, want dat zeg je niet.

[Rainmaker]

Loopt root op deze manier niet gewoon uit zn filedescriptors? Want op die manier krijg je inderdaad een server ge-freezed met een ogenschijnlijk onschuldig scriptje.

Als <script> wordt aangeroepen, blijft <parent van script> ook nog draaien. Op een gegeven moment heb je 1000'en processen.

Beter is in cron inderdaad

* * * * * /app_chmod.sh

met als content:

code:

#!/bin/bash
chmod 777 /file

Wat je nu eigenlijk hebt, is een vertraagde fork bomb.

*edit: ik zie al wat betere scriptjes dan bovenstaande staan in het topic.

Maar feit blijft; niet recursief aanroepen. Eventueel met at werken als je meer dan 1 keer per minuut moet werken:

(quick & dirty)

code:

#!/bin/bash
if [ ! -f /var/run/lock.script.chmod ]; then
  touch /var/run/lock.script.chmod
  chmod -R 777 /directory
  echo "/path/to/script.sh" | at now
  rm /var/run/lock.script
  exit 0
fi
logger "Hmm, hier klopt iets niet"
exit 1

[ Voor 59% gewijzigd door Rainmaker op 25-05-2012 20:31 ]

[H!GHGuY]

Rainmaker schreef op vrijdag 25 mei 2012 @ 20:17:
Loopt root op deze manier niet gewoon uit zn filedescriptors? Want op die manier krijg je inderdaad een server ge-freezed met een ogenschijnlijk onschuldig scriptje.

File descriptors zijn per-process.

Als <script> wordt aangeroepen, blijft <parent van script> ook nog draaien. Op een gegeven moment heb je 1000'en processen.

Beter is in cron inderdaad

* * * * * /app_chmod.sh

met als content:

code:

#!/bin/bash
chmod 777 /file

Wat je nu eigenlijk hebt, is een vertraagde fork bomb.

*edit: ik zie al wat betere scriptjes dan bovenstaande staan in het topic.

Maar feit blijft; niet recursief aanroepen. Eventueel met at werken als je meer dan 1 keer per minuut moet werken:

(quick & dirty)

code:

#!/bin/bash
if [ ! -f /var/run/lock.script.chmod ]; then
  touch /var/run/lock.script.chmod
  chmod -R 777 /directory
  echo "/path/to/script.sh" | at now
  rm /var/run/lock.script
  exit 0
fi
logger "Hmm, hier klopt iets niet"
exit 1

Je locking is fout.
De juiste manier om locks te maken in shellscripts:

Bash:

touch /var/run/$0.$$
while ! ln /var/run/$0.$$ /var/run/$0
do
  echo "Waiting for lock..."
  sleep 1
done
trap "rm /var/run/$0.$$ /var/run/$0" EXIT

Dit mag je echter niet doen op een NFS mount...

Bovendien kun je met ionice er ook voor zorgen dat je I/O in de background draait.

Het script zou ik echter toch anders schrijven:

Bash:

while true
do
  find /var5/users/app -type f ! -perm 777 | xargs -n 100 -- chmod -R 777
  sleep 5
done

en dan eenmalig opstarten met
nohup ./chmod_script.sh &

[ Voor 8% gewijzigd door H!GHGuY op 26-05-2012 09:03 ]

[demichel]

Server is vannacht niet down gegaan!