Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Acties:
  • 0Henk 'm!

  • demichel
  • Registratie: december 2009
  • Laatst online: 19-09 13:56
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...

There are only two rules in life. #1. There always is a loser. #2. Don't be the loser.


Acties:
  • 0Henk 'm!

  • mace
  • Registratie: juni 2003
  • Laatst online: 20-10 23:38

mace

Sapere Aude

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]


Acties:
  • 0Henk 'm!

  • demichel
  • Registratie: december 2009
  • Laatst online: 19-09 13:56
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]

There are only two rules in life. #1. There always is a loser. #2. Don't be the loser.


Acties:
  • 0Henk 'm!

  • mace
  • Registratie: juni 2003
  • Laatst online: 20-10 23:38

mace

Sapere Aude

Bash:
1
2
3
4
5
6
7
#!/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]


Acties:
  • 0Henk 'm!

  • Big Womly
  • Registratie: oktober 2007
  • Laatst online: 11-07 20:42

Big Womly

Live forever, or die trying

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

When you talk to God it's called prayer, but when God talks to you it's called schizophrenia


Acties:
  • 0Henk 'm!

  • RemcoDelft
  • Registratie: april 2002
  • Laatst online: 13:14
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 8) ) 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]


Acties:
  • 0Henk 'm!

  • croontje
  • Registratie: april 2004
  • Laatst online: 27-09 20:19
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...

Acties:
  • 0Henk 'm!

  • demichel
  • Registratie: december 2009
  • Laatst online: 19-09 13:56
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"...

There are only two rules in life. #1. There always is a loser. #2. Don't be the loser.


Acties:
  • 0Henk 'm!

  • mace
  • Registratie: juni 2003
  • Laatst online: 20-10 23:38

mace

Sapere Aude

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


Briljant! Heel wat beter dan mijn quick&dirty "oplossing"...
Loopje is toch wat netter. ;)

Acties:
  • 0Henk 'm!

  • demichel
  • Registratie: december 2009
  • Laatst online: 19-09 13:56
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 ;)

There are only two rules in life. #1. There always is a loser. #2. Don't be the loser.


Acties:
  • 0Henk 'm!

  • Paul
  • Registratie: september 2000
  • Laatst online: 13:46
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

:)

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock


Acties:
  • 0Henk 'm!

  • mace
  • Registratie: juni 2003
  • Laatst online: 20-10 23:38

mace

Sapere Aude

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. :>

Acties:
  • 0Henk 'm!

  • demichel
  • Registratie: december 2009
  • Laatst online: 19-09 13:56
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]

There are only two rules in life. #1. There always is a loser. #2. Don't be the loser.


Acties:
  • 0Henk 'm!

  • croontje
  • Registratie: april 2004
  • Laatst online: 27-09 20:19
Of een loopje van 12 met een sleep van 5 in 1 cronjob :p

Acties:
  • 0Henk 'm!

  • mace
  • Registratie: juni 2003
  • Laatst online: 20-10 23:38

mace

Sapere Aude

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:
1
2
3
4
5
6
7
#!/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 :p
Met stom. (Ik mis steeds posts).

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


Acties:
  • 0Henk 'm!

  • Sendy
  • Registratie: september 2001
  • Niet online
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.

Acties:
  • 0Henk 'm!

  • demichel
  • Registratie: december 2009
  • Laatst online: 19-09 13:56
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??

There are only two rules in life. #1. There always is a loser. #2. Don't be the loser.


Acties:
  • 0Henk 'm!

  • Paul
  • Registratie: september 2000
  • Laatst online: 13:46
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...

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock


Acties:
  • 0Henk 'm!

  • swbr
  • Registratie: maart 2009
  • Laatst online: 06-10 16:47
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?

If you try and take a cat apart to see how it works, the first thing you have on your hands is a non-working cat. -DNA


Acties:
  • 0Henk 'm!

  • sam.vimes
  • Registratie: januari 2007
  • Laatst online: 14-10 15:47
mace schreef op vrijdag 25 mei 2012 @ 09:25:
[...]
Dan kun je zoiets doen:

code:
1
2
3
4
5
6
7
#!/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:
1
2
3
4
5
6
7
#!/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]


Acties:
  • 0Henk 'm!

  • Sendy
  • Registratie: september 2001
  • Niet online
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:
1
2
3
4
date >>/home/oracle/chmod.log
sleep 5
chmod -R 777 /var5/users/app
./chmod_app.sh

en
code:
1
2
3
4
5
6
7
#!/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:
1
2
3
4
5
6
7
8
9
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:
1
2
3
4
5
6
7
8
9
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 :)

Acties:
  • 0Henk 'm!

  • demichel
  • Registratie: december 2009
  • Laatst online: 19-09 13:56
En natuurlijk, dank voor jullie hulp!

There are only two rules in life. #1. There always is a loser. #2. Don't be the loser.


Acties:
  • 0Henk 'm!

  • Mijzelf
  • Registratie: september 2004
  • Niet online
Je kunt je oude script ook gewoon gebruiken, met een kleine aanpassing:
code:
1
2
3
4
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 ...

Acties:
  • 0Henk 'm!

  • mdartu
  • Registratie: januari 2005
  • Laatst online: 10-10 14:11
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]


Acties:
  • 0Henk 'm!

  • w.l
  • Registratie: mei 2007
  • Laatst online: 18-10 22:53
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:
1
2
3
4
5
6
7
8
9
10
#!/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.)

Acties:
  • 0Henk 'm!

  • Hero of Time
  • Registratie: oktober 2004
  • Laatst online: 11:07

Hero of Time

Moderator NOS

There is only one Legend

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.

Commandline FTW | Tweakt met mate


Acties:
  • 0Henk 'm!

  • Rainmaker
  • Registratie: augustus 2000
  • Laatst online: 30-09 21:59
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:
1
2
#!/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:
1
2
3
4
5
6
7
8
9
10
#!/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]

We are pentium of borg. Division is futile. You will be approximated.


  • H!GHGuY
  • Registratie: december 2002
  • Niet online

H!GHGuY

Try and take over the world...

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:
1
2
#!/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:
1
2
3
4
5
6
7
8
9
10
#!/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:
1
2
3
4
5
6
7
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:
1
2
3
4
5
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]

ASSUME makes an ASS out of U and ME


  • demichel
  • Registratie: december 2009
  • Laatst online: 19-09 13:56
Server is vannacht niet down gegaan!

There are only two rules in life. #1. There always is a loser. #2. Don't be the loser.

Pagina: 1


Microsoft Xbox Series X LG CX Google Pixel 5 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True