Debian (pi) - Cron entry maakt zeer veel processen

[Mattie112]

Hallo,

Ik heb het volgende "probleem": Ik heb een raspberry pi met daarop Debian wheezy 7. Ik heb met serverstats (soort van cacti) een zooi grafieken gegenereerd en daarvoor gebruik ik onder andere een cron entry welke de output van een command in een textfile zet:

Cron:

code:

* * * * * sh /root/temperatuur.sh >> /root/temp_log
* * * * * vcgencmd measure_clock arm > /usr/share/serverstats/results/freq_arm
* * * * * vcgencmd measure_clock core > /usr/share/serverstats/results/freq_core
* * * * * vcgencmd measure_clock h264 > /usr/share/serverstats/results/freq_h264

Je zou zeggen: wat kan er hier fout gaan, nou dat vraag ik me ook af. Het grafiek met het aantal processen ziet er zo uit:



Als ik reboot staat hij weer op "laag" maar loopt daarna op. Dit lijkt me toch echt niet te kloppen! Waarom worden er zoveel processen gemaakt?
Wanneer ik in ps aux kijk zie ik heel vaak dus dat "script" staan. Aangezien dit niet "blijft" draaien (het is alleen 1 command parsen naar een text_file) vraag ik me toch echt af hoe dit kan.

ps aux:

code:

[..]
root      4043  0.0  0.2   4884  1176 ?        S    14:53   0:00 /USR/SBIN/CRON
root      4047  0.0  0.1   1752   516 ?        Ss   14:53   0:00 /bin/sh -c vcgencmd measure_clock arm > /usr/share/serverstat
root      4054  0.0  0.1  10228   684 ?        Sl   14:53   0:00 vcgencmd measure_clock arm
root      4925  0.2  0.2   4884  1176 ?        S    14:57   0:00 /USR/SBIN/CRON
root      4929  0.1  0.1   1752   516 ?        Ss   14:57   0:00 /bin/sh -c vcgencmd measure_clock arm > /usr/share/serverstat
root      4934  0.1  0.1  10228   684 ?        Sl   14:57   0:00 vcgencmd measure_clock arm
root      5009  0.0  0.2   4444  1116 pts/0    R+   14:57   0:00 ps aux
[..]

Mijn vraag dus: heeft iemand enig idee hoe dit kan en wat er aan te doen is? Ik heb geen idee of het problemen gaat opleveren maar het klopt niet in elk geval!

root@raspberrypi ~ # uname -a
Linux raspberrypi.mattie-systems.nl 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux

root@raspberrypi ~ # cat /etc/*-release
PRETTY_NAME="Debian GNU/Linux 7.0 (wheezy)"
NAME="Debian GNU/Linux"
VERSION_ID="7.0"
VERSION="7.0 (wheezy)"
ID=debian
ANSI_COLOR="1;31"
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support/"
BUG_REPORT_URL="http://bugs.debian.org/"

[Sendy]

Als je die processen met de hand draait stoppen ze dan na een tijdje of gaan ze niet dood?

[Mattie112]

Dat is een goeie, ik zal even herstarten en de command's handmatig uitvoeren. Ik laat het over 5 minuutjes weten

edit:

Het lijkt er op dat ze dan niet blijven draaien. Ik kan ze in elk geval niet terugvinden in de ps aux!

[ Voor 33% gewijzigd door Mattie112 op 21-03-2013 15:19 ]

[Hero of Time]

En hoe lang duurt het voordat het script klaar is? Als je namelijk een script elke minuut uit gaat voeren, die er 2 over doet om z'n werk te doen, dan krijg je vanzelf een grote backlog van processen die worden aangemaakt totdat het max is bereikt, of je systeem vast loopt. Beetje als een fork-bomb, maar dan niet door forken maar cron.

[Mattie112]

Astu:

root@raspberrypi ~ # time sh /root/temperatuur.sh >> /root/temp_log

real 0m0.056s
user 0m0.000s
sys 0m0.000s
root@raspberrypi ~ # time vcgencmd measure_clock arm > /usr/share/serverstats/results/freq_arm

real 0m0.013s
user 0m0.000s
sys 0m0.000s
root@raspberrypi ~ # time vcgencmd measure_clock core > /usr/share/serverstats/results/freq_core

real 0m0.030s
user 0m0.000s
sys 0m0.010s
root@raspberrypi ~ # time vcgencmd measure_clock h264 > /usr/share/serverstats/results/freq_h264

real 0m0.017s
user 0m0.000s
sys 0m0.010s

Dat eerste script is puur het "vcgencmd measure_temp" command maar dan als losse batch file
Ik geloof nooit dat het mogelijk is voor deze commands om langer dan een minuut te duren!

[Orion84]

Je zou de cron job eens op elke 5 minuten kunnen zetten, om te zien wat er dan gebeurt. Groeit het dan nog steeds, maar langzamer, dan heeft dat niets geholpen, groeit het dan niet meer, dan kwamen de commands blijkbaar toch te snel na elkaar.

[Mattie112]

Dat is een goed idee, had hem net weer op 1 minuut gezet om ff de log in de gaten te houden of er error's voorbij komen. Ik zal m zo rebooten en de cron op 5 minuten gooien!

[Orion84]

De bestanden waar naartoe geschreven wordt, wat gebeurt daarmee? Die zijn zeker weer input voor een ander tooltje dat die grafiekjes genereert?

Kan het niet zijn dat die tool die de grafiekjes genereert bij het lezen van het bestand daar een lock op zet, waardoor het schrijven naar dat bestand mislukt als het andere script in de tussentijd weer nieuwe data er naartoe wil schrijven?

[Mattie112]

Pfoe daar zeg je me wat zeg.....

Het wordt op deze manier uitgelezen:

PHP:

[..]
$this->arm_freq_command = 'cat /usr/share/serverstats/results/freq_arm';
[..]
if (!($arm_output = exec(escapeshellcmd($this->arm_freq_command))))
{
  throw new Exception('Could not execute "' . $this->arm_freq_command . '"');
}
//doe iets met $arm_output

Een "cat" zou naar mijn mening geen lock op een bestand (mogen) leggen?

hm bij nader inzien:

/var/log/user.log:

Mar 21 15:08:38 raspberrypi shutdown[7491]: shutting down for system reboot
Mar 21 15:58:03 raspberrypi Serverstats[13090]: exception 'Exception' with message 'Could not execute "cat /usr/share/serverstats/results/freq_arm"' in /usr/share/serverstats/sources/frequency.php:31#012Stack trace:#012#0 /usr/share/serverstats/update.php(64): frequency->refreshData()#012#1 {main}
Mar 21 16:03:03 raspberrypi Serverstats[14218]: exception 'Exception' with message 'Could not execute "cat /usr/share/serverstats/results/freq_h264"' in /usr/share/serverstats/sources/frequency.php:40#012Stack trace:#012#0 /usr/share/serverstats/update.php(64): frequency->refreshData()#012#1 {main}
Mar 21 16:08:05 raspberrypi Serverstats[15364]: exception 'Exception' with message 'Could not execute "cat /usr/share/serverstats/results/freq_arm"' in /usr/share/serverstats/sources/frequency.php:31#012Stack trace:#012#0 /usr/share/serverstats/update.php(64): frequency->refreshData()#012#1 {main}
Mar 21 16:16:02 raspberrypi Serverstats[17175]: exception 'Exception' with message 'Could not execute "cat /usr/share/serverstats/results/freq_core"' in /usr/share/serverstats/sources/frequency.php:36#012Stack trace:#012#0 /usr/share/serverstats/update.php(64): frequency->refreshData()#012#1 {main}
Mar 21 16:19:03 raspberrypi Serverstats[17845]: exception 'Exception' with message 'Could not execute "cat /usr/share/serverstats/results/freq_core"' in /usr/share/serverstats/sources/frequency.php:36#012Stack trace:#012#0 /usr/share/serverstats/update.php(64): frequency->refreshData()#012#1 {main}
Mar 21 16:20:03 raspberrypi Serverstats[18068]: exception 'Exception' with message 'Could not execute "cat /usr/share/serverstats/results/freq_core"' in /usr/share/serverstats/sources/frequency.php:36#012Stack trace:#012#0 /usr/share/serverstats/update.php(64): frequency->refreshData()#012#1 {main}
Mar 21 16:22:03 raspberrypi Serverstats[18527]: exception 'Exception' with message 'Could not execute "cat /usr/share/serverstats/results/freq_arm"' in /usr/share/serverstats/sources/frequency.php:31#012Stack trace:#012#0 /usr/share/serverstats/update.php(64): frequency->refreshData()#012#1 {main}

Toch maar even kijken of ik wat meer details boven water kan krijgen

[ Voor 72% gewijzigd door Mattie112 op 21-03-2013 16:23 ]

[Orion84]

Dat php script wordt ook gescheduled neem ik aan? Is het dan niet handiger om dat cat command gewoon te vervangen door rechtstreeks het vcgencmd commando? Dan sluit je in elk geval uit dat het ene geschedulede command ergens naar probeert te schrijven, terwijl een ander gescheduled command datzelfde bestand probeert te lezen.

Bovenstaande errors zouden wellicht ook kunnen komen door PHP security settings die het verbieden om exec te doen of iets aan te roepen buiten de directory waar dat PHP bestand staat.

Sowieso is het natuurlijk bijzonder lelijk om een exec te doen van cat, ipv. gewoon via PHP functies de bestand te lezen.

[ Voor 52% gewijzigd door Orion84 op 21-03-2013 16:46 ]

[Mattie112]

Mja het kan zijn dat ze botsen, maar dat doen ze dan wel vaak....

De php "update" file is door serverstats zelf aangemaakt en wordt door de nobody user uitgevoerd in de cron ook elke minuut:

if [ -x /usr/bin/php5 ] && [ -f /usr/share/serverstats/update.php ]; then /usr/bin/php5 /usr/share/serverstats/update.php > /dev/null; fi

Er zijn eigenlijk 2 redenen waarom ik het command zelf niet uitvoer:

1. de user nobody heeft standaard geen rechten tot dat "geavanceerde" vcgencmd, het liefst houd ik dat zo
2. zodra het script draait wordt het systeem automatisch op 900mhz geclocked omdat er veel performance nodig is, mijn grafiek zal dus altijd op 900mhz staan en ik wil juist het verschil kunnen zien tussen "normaal" en "drukke" tijden. Het opvragen van de cpu speed kost niet veel kracht dus blijft de frequency laag, wanneer een paar sec later de file uitgelezen wordt dan ziet hij dus de "echte" snelheid en niet zozeer de verhoogde omdat het updaten veel processorkracht vraagt.

<tl;dr>
Met andere woorden: wanneer ik het script zelf de gegevens laat opvragen dan krijg ik een "verkeerde" cpu speed terug. Het is namelijk altijd "hoog" op dat moment omdat er op dát moment veel processorkracht nodig is!

[Orion84]

Check, helder. Snap ik nog steeds niet waarom ze zo'n lelijke exec cat doen, ipv een simpele read file functie aanroepen, maar goed, daar kan jij verder ook weinig aan doen

Dan zou het natuurlijk dus nog wel kunnen zijn dat er iets botst, of dat dat grafiek script dusdanig veel CPU trekt dat er daardoor dingen vertraagd worden en zaken op een hoop lopen. De boel op 5 minuten intervals testen lijkt me een goede stap. Dat zou je zelfs zo kunnen inregelen dat het vcgencmd een minuut eerder draait dan het grafiekscript.

Je hebt dan wel wat minder nauwkeurige grafiekjes natuurlijk, aangezien je pieken die minder dan 5 minuten duren kan missen als ze net tussen twee meetmomenten vallen.

[Mattie112]

Mja die php file kan ik zelf aanpassen natuurlijk :-) bedankt in elk geval voor het meedenken. Ik laat hem ff tot morgen ochtend op 1 minuut staan, kijken wat er gebeurd met zoveel processen. Daarna test ik 5 min, werkt dat niet dan kan ik kijken naar een php file read functie.

[Anoniem: 26306]

Gebruik flock om maar één proces tegelijkertijd toe te staan!

[Mattie112]

Pft ondertussen ziet ie er zo uit:



Ik kan er in elk geval vanuit gaan dat het probleem niet uit zichzelf opgelost wordt

Bedankt voor de tip cheatah, ik ga even kijken wat ik daar mee kan!

[deadinspace]

Mattie112 schreef op donderdag 21 maart 2013 @ 14:59:
Ik heb het volgende "probleem": Ik heb een raspberry pi met daarop Debian wheezy 7.

Het is een beetje nitpicken, maar het is pas Debian 7 als het gereleased wordt, en dat is nog niet zover

Wanneer ik in ps aux kijk zie ik heel vaak dus dat "script" staan. Aangezien dit niet "blijft" draaien (het is alleen 1 command parsen naar een text_file) vraag ik me toch echt af hoe dit kan.

Nou, blijkbaar blijven die commando's wel draaien, anders... Bleven ze niet draaien!

De grote vraag is natuurlijk: waarom blijven ze draaien als dat blijkbaar niet de bedoeling is?

Als die processen foutmeldingen geven, dan mailt cron dat. Krijg je mails van cron? Zo ja, wat staat daar in?

ps aux:

code:

[..]
root      4043  0.0  0.2   4884  1176 ?        S    14:53   0:00 /USR/SBIN/CRON
root      4047  0.0  0.1   1752   516 ?        Ss   14:53   0:00 /bin/sh -c vcgencmd measure_clock arm > /usr/share/serverstat
root      4054  0.0  0.1  10228   684 ?        Sl   14:53   0:00 vcgencmd measure_clock arm
root      4925  0.2  0.2   4884  1176 ?        S    14:57   0:00 /USR/SBIN/CRON
root      4929  0.1  0.1   1752   516 ?        Ss   14:57   0:00 /bin/sh -c vcgencmd measure_clock arm > /usr/share/serverstat
root      4934  0.1  0.1  10228   684 ?        Sl   14:57   0:00 vcgencmd measure_clock arm
root      5009  0.0  0.2   4444  1116 pts/0    R+   14:57   0:00 ps aux
[..]

Process 4054 draait duidelijk al minstens 4 minuten met 0 seconden CPU-tijd en status "sleeping". Die processen die blijven hangen wachten dus ergens op.

Installeer eens strace, en doe eens

strace -p 4054

om te kijken wat dat proces precies uitspookt? (afbreken met ctrl-C)

Ik heb geen idee of het problemen gaat opleveren maar het klopt niet in elk geval!

Het aantal processen dat je kunt spawnen is beperkt, dus als die processen nooit weggaan dan gaat dit zeker problemen opleveren ja.

Hero of Time schreef op donderdag 21 maart 2013 @ 15:36:
En hoe lang duurt het voordat het script klaar is? Als je namelijk een script elke minuut uit gaat voeren, die er 2 over doet om z'n werk te doen, dan krijg je vanzelf een grote backlog van processen

Hangt er vanaf waarom die processen 2 minuten duren natuurlijk. Als je elke minuut een process start dat 2 minuten slaapt, dan krijg je natuurlijk geen problemen. Als je elke minuut een process start dat 2 minuten CPU-tijd nodig heeft krijg je wel een probleem, maar dat lijkt niet het geval te zijn (zie mijn interpretatie van de ps output).

Beetje als een fork-bomb, maar dan niet door forken maar cron.

Cron start natuurlijk zijn processen ook door te forken

Sterker nog, elk process op je systeem is afkomstig van een fork (of nouja, eigenlijk van de onderliggende system call clone()).

Orion84 schreef op donderdag 21 maart 2013 @ 16:09:
Kan het niet zijn dat die tool die de grafiekjes genereert bij het lezen van het bestand daar een lock op zet, waardoor het schrijven naar dat bestand mislukt als het andere script in de tussentijd weer nieuwe data er naartoe wil schrijven?

Korte antwoord: nee, niet echt

Lang antwoord: er vindt standaard geen file locking plaats. Zelfs als processen wel locks aanbrengen dan zijn dit advisory locks waar processen expliciet op moeten checken. Linux kent wel mandatory locking, maar staat standaard uit.

En al zouden het locks zijn, dan zou het proces simpelweg niet uitgevoerd worden.

Orion84 schreef op donderdag 21 maart 2013 @ 17:06:
Check, helder. Snap ik nog steeds niet waarom ze zo'n lelijke exec cat doen, ipv een simpele read file functie aanroepen, maar goed, daar kan jij verder ook weinig aan doen

Inderdaad. En dat, in combinatie met het wegschrijven van variabele data in /usr, geeft mij weinig vertrouwen in dat serverstats programma eigenlijk.

Anoniem: 26306 schreef op donderdag 21 maart 2013 @ 21:19:
Gebruik flock om maar één proces tegelijkertijd toe te staan!

Alleen als alle processen die de file benaderen ook flock gebruiken, want die locking is advisory, niet mandatory.

[leuk_he]

Draai het script eens op de achtergrond vanuit de shell.

code:

time vcgencmd measure_clock arm > /usr/share/serverstats/results/freq_arm &

en ook de aanroep van update.php op een zelfde manier. een "& "er achter.

Als hij namelijk om een of andere rede stdin leest zou hij daarop blijven kunnen blijven hangen.

Een ander verschil met de interactieve shell is dat cron de .profile niet draait. Als daarin iets relevants gezet wordt.

[ Voor 9% gewijzigd door leuk_he op 22-03-2013 14:12 ]

[Mattie112]

deadinspace schreef op vrijdag 22 maart 2013 @ 13:58:
[...]

Het is een beetje nitpicken, maar het is pas Debian 7 als het gereleased wordt, en dat is nog niet zover

[...]

Haha ok point taken Bedankt voor je antwoord ik zal proberen ze zo goed mogelijk te beantwoorden:

Nou, blijkbaar blijven die commando's wel draaien, anders... Bleven ze niet draaien!

De grote vraag is natuurlijk: waarom blijven ze draaien als dat blijkbaar niet de bedoeling is?

Als die processen foutmeldingen geven, dan mailt cron dat. Krijg je mails van cron? Zo ja, wat staat daar in?

Zo'n idee had ik ook maargoed ik zie geen reden waarom ze blijven draaien . Ik heb even de cron log geactiveerd en dit krijg ik te zien:

code:

Mar 22 14:21:01 raspberrypi /USR/SBIN/CRON[23834]: (root) CMD (vcgencmd measure_clock arm > /usr/share/serverstats/results/freq_arm)
Mar 22 14:21:01 raspberrypi /USR/SBIN/CRON[23835]: (root) CMD (vcgencmd measure_clock core > /usr/share/serverstats/results/freq_core)
Mar 22 14:21:01 raspberrypi /USR/SBIN/CRON[23836]: (root) CMD (vcgencmd measure_clock h264 > /usr/share/serverstats/results/freq_h264)
Mar 22 14:21:01 raspberrypi /USR/SBIN/CRON[23838]: (root) CMD (sh /root/temperatuur.sh >> /root/temp_log)
Mar 22 14:21:01 raspberrypi /USR/SBIN/CRON[23837]: (nobody) CMD (if [ -x /usr/bin/php5 ] && [ -f /usr/share/serverstats/update.php ]; then /usr/bin/php5 /usr/share/serverstats/update.php > /dev/null; fi)

Verder geen foutmeldingen voor zover ik kan zien.

Process 4054 draait duidelijk al minstens 4 minuten met 0 seconden CPU-tijd en status "sleeping". Die processen die blijven hangen wachten dus ergens op.

Installeer eens strace, en doe eens

strace -p 4054

om te kijken wat dat proces precies uitspookt? (afbreken met ctrl-C)

Ik heb even een proces gepakt:

code:

root     23830  0.0  0.2   4884  1180 ?        S    14:21   0:00 /USR/SBIN/CRON
root     23838  0.0  0.1   1752   516 ?        Ss   14:21   0:00 /bin/sh -c sh /root/temperatuur.sh >> /root/temp_log
root     23841  0.0  0.1   1752   512 ?        S    14:21   0:00 sh /root/temperatuur.sh
root     23844  0.0  0.1  10228   684 ?        Sl   14:21   0:00 /opt/vc/bin/vcgencmd measure_temp

en vervolgens de strace:

root@raspberrypi ~ # strace -p 23844
Process 23844 attached - interrupt to quit
futex(0x1290c, FUTEX_WAIT_PRIVATE, 0, NULL

Geen idee wat je hier aan kan zien maar ik hoop dat je er wat aan hebt

Het aantal processen dat je kunt spawnen is beperkt, dus als die processen nooit weggaan dan gaat dit zeker problemen opleveren ja.

Ok, dan moet ik dit zeker op gaan lossen somehow...

Hangt er vanaf waarom die processen 2 minuten duren natuurlijk. Als je elke minuut een process start dat 2 minuten slaapt, dan krijg je natuurlijk geen problemen. Als je elke minuut een process start dat 2 minuten CPU-tijd nodig heeft krijg je wel een probleem, maar dat lijkt niet het geval te zijn (zie mijn interpretatie van de ps output).

Ik heb een hele zooi keer het command handmatig gedraaid en hij is eig altijd in een "paar" ms klaar dat 1 minuut echt nooit haalbaar is.

Korte antwoord: nee, niet echt

Lang antwoord: er vindt standaard geen file locking plaats. Zelfs als processen wel locks aanbrengen dan zijn dit advisory locks waar processen expliciet op moeten checken. Linux kent wel mandatory locking, maar staat standaard uit.

En al zouden het locks zijn, dan zou het proces simpelweg niet uitgevoerd worden.

Ok, in eerste instantie leek het mij ook vreemd dat dit hier door kon.... weet k in elk geval dat ik niet in die richting hoef te zoeken.

Inderdaad. En dat, in combinatie met het wegschrijven van variabele data in /usr, geeft mij weinig vertrouwen in dat serverstats programma eigenlijk.

De locatie heb ik er zelf in gezet, het is niet zo dat ze dit standaard doen Maargoed ik had idd net zo goed /home of /temp of /whatever kunnen pakken ;p


-------

Zou het niet een optie zijn om wanneer het proces na xx sec (bijv 10) nog steeds draait dit te killen? Misschien een beetje nasty maar is het mogelijk een soort timeout op te geven ?

[Mattie112]

leuk_he schreef op vrijdag 22 maart 2013 @ 14:05:
Draai het script eens op de achtergrond vanuit de shell.

code:

time vcgencmd measure_clock arm > /usr/share/serverstats/results/freq_arm &

en ook de aanroep van update.php op een zelfde manier. een "& "er achter.

Als hij namelijk om een of andere rede stdin leest zou hij daarop blijven kunnen blijven hangen.

Een ander verschil met de interactieve shell is dat cron de .profile niet draait. Als daarin iets relevants gezet wordt.

code:

root@raspberrypi ~ # time vcgencmd measure_clock arm > /usr/share/serverstats/results/freq_arm &
[1] 31281
root@raspberrypi ~ #
real    0m0.896s
user    0m0.010s
sys     0m0.000s

en de .profile

code:

# ~/.profile: executed by Bourne-compatible login shells.

if [ "$BASH" ]; then
  if [ -f ~/.bashrc ]; then
    . ~/.bashrc
  fi
fi

mesg n

[Sendy]

Mattie112 schreef op vrijdag 22 maart 2013 @ 14:49:
[...]
Ik heb even een proces gepakt:

code:

root     23830  0.0  0.2   4884  1180 ?        S    14:21   0:00 /USR/SBIN/CRON
root     23838  0.0  0.1   1752   516 ?        Ss   14:21   0:00 /bin/sh -c sh /root/temperatuur.sh >> /root/temp_log
root     23841  0.0  0.1   1752   512 ?        S    14:21   0:00 sh /root/temperatuur.sh
root     23844  0.0  0.1  10228   684 ?        Sl   14:21   0:00 /opt/vc/bin/vcgencmd measure_temp

en vervolgens de strace:

root@raspberrypi ~ # strace -p 23844
Process 23844 attached - interrupt to quit
futex(0x1290c, FUTEX_WAIT_PRIVATE, 0, NULL

Volgens http://meenakshi02.wordpr.../strace-hanging-at-futex/ betekent dit dat je een parent process hebt gekozen, dat alleen wacht op zijn kinderen. Zijn er processen met PPID deze parent?

Zo ja, doe eens een strace op die processen?

[Mattie112]

Thx, heb daar ook even de output van genoteerd:

code:

ps -efL
root     32074 32070 32078  0    2 14:58 ?        00:00:00 /opt/vc/bin/vcgencmd measure_temp

en dan de PID's stracen:

root@raspberrypi ~ # strace -p 32070
Process 32070 attached - interrupt to quit
wait4(-1, ^C <unfinished ...>
Process 32070 detached
root@raspberrypi ~ # strace -p 32078
Process 32078 attached - interrupt to quit
ioctl(3, 0xc014c407^C <unfinished ...>
Process 32078 detached
root@raspberrypi ~ # strace -p 32074
Process 32074 attached - interrupt to quit
futex(0x1290c, FUTEX_WAIT_PRIVATE, 0, NULL^C <unfinished ...>
Process 32074 detached
root@raspberrypi ~ #

Ik zie nog niet echt iets van belang....

edit:
misschien ook nuttig:

code:

root@raspberrypi ~ # strace -f -p 32074
Process 32074 attached with 2 threads - interrupt to quit
pid 32078 stray syscall exit
[pid 32078] restart_syscall(pid 32078 stray syscall entry
0, 0)       = 3
[pid 32074] futex(0x1290c, FUTEX_WAIT_PRIVATE, 0, NULL

[ Voor 18% gewijzigd door Mattie112 op 22-03-2013 15:09 ]

[leuk_he]

Mattie112 schreef op vrijdag 22 maart 2013 @ 15:08:
Process 32078 attached - interrupt to quit
ioctl(3, 0xc014c407^C <unfinished ...>
Process 32078 detached

Daar zit hij op te wachten, waarschijnlijk de file die hij probeert te cat'ten? Weet ik niet zeker, als je een volledite trace doet door "strace cat bla bla" te doen, en daarvan de stderr op te vangen dan zie welke filedescriptor er aan ioctl wordt meegegeven.

[Mattie112]

Het begint voor mij toch wel een beetje chocola te worden zo

Hoop dat dit is wat je bedoelt:

root@raspberrypi ~ # strace cat /usr/share/serverstats/results/freq_arm
execve("/bin/cat", ["cat", "/usr/share/serverstats/results/f"...], [/* 16 vars */]) = 0
brk(0) = 0x726000
uname({sys="Linux", node="raspberrypi.mattie-systems.nl", ...}) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f8f000
access("/etc/ld.so.preload", R_OK) = 0
open("/etc/ld.so.preload", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
mmap2(NULL, 44, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0xb6f8e000
close(3) = 0
open("/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\260\4\0\0004\0\0\0"..., 512) = 512
lseek(3, 5716, SEEK_SET) = 5716
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 920) = 920
lseek(3, 5468, SEEK_SET) = 5468
read(3, "A0\0\0\0aeabi\0\1&\0\0\0\0056\0\6\6\10\1\t\1\n\2\22\4\24\1\25"..., 49) = 49
fstat64(3, {st_mode=S_IFREG|0644, st_size=6636, ...}) = 0
mmap2(NULL, 38240, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6f62000
mprotect(0xb6f64000, 28672, PROT_NONE) = 0
mmap2(0xb6f6b000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb6f6b000
close(3) = 0
munmap(0xb6f8e000, 44) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=41396, ...}) = 0
mmap2(NULL, 41396, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f57000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\214y\1\0004\0\0\0"..., 512) = 512
lseek(3, 1194784, SEEK_SET) = 1194784
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1360) = 1360
lseek(3, 1194348, SEEK_SET) = 1194348
read(3, "A.\0\0\0aeabi\0\1$\0\0\0\0056\0\6\6\10\1\t\1\n\2\22\4\24\1\25"..., 47) = 47
fstat64(3, {st_mode=S_IFREG|0755, st_size=1196144, ...}) = 0
mmap2(NULL, 1238312, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e28000
mprotect(0xb6f4a000, 28672, PROT_NONE) = 0
mmap2(0xb6f51000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x121) = 0xb6f51000
mmap2(0xb6f54000, 9512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f54000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f8e000
set_tls(0xb6f8e4c0, 0xb6f8eb98, 0xb6f92048, 0xb6f8e4c0, 0xb6f92048) = 0
mprotect(0xb6f51000, 8192, PROT_READ) = 0
mprotect(0x19000, 4096, PROT_READ) = 0
mprotect(0xb6f91000, 4096, PROT_READ) = 0
munmap(0xb6f57000, 41396) = 0
brk(0) = 0x726000
brk(0x747000) = 0x747000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1534656, ...}) = 0
mmap2(NULL, 1534656, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6cb1000
close(3) = 0
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
open("/usr/share/serverstats/results/freq_arm", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0777, st_size=24, ...}) = 0
fadvise64_64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
read(3, "frequency(45)=700000000\n", 32768) = 24
write(1, "frequency(45)=700000000\n", 24frequency(45)=700000000
) = 24
read(3, "", 32768) = 0
close(3) = 0
close(1) = 0
close(2) = 0
exit_group(0) = ?

[Gomez12]

Gooi eens simpelweg 2 van die crons weg? Heb je het dan nog steeds?

Ik dacht namelijk dat cron niet aan uitgebreide scheduling deed, op het moment dat de cron-tijd aangekomen is dan start hij 3x je vcgencmd parallel.
Op het moment dat vcgencmd dan zelf bijv een timeout van 30 seconden genereert op het moment dat hij ergens niet direct bij kan komen (omdat bijv een andere vcgencmd een lock ergens op gezet heeft) dan ben je de bietenbrug op. Dan blijf je namelijk in een eeuwige lus zitten op het moment dat die eenmaal gestart is.

Dit zou ook te verhelpen moeten zijn door idd 1x per 5 minuten je script te draaien (of door te kijken of vcgencmd niet alledrie de outputs in 1x kan genereren)

[Orion84]

leuk_he schreef op vrijdag 22 maart 2013 @ 16:09:
[...]


Daar zit hij op te wachten, waarschijnlijk de file die hij probeert te cat'ten? Weet ik niet zeker, als je een volledite trace doet door "strace cat bla bla" te doen, en daarvan de stderr op te vangen dan zie welke filedescriptor er aan ioctl wordt meegegeven.

Dat cat command zat in het php script, niet in die vcgencmd die blijft hangen hè.

[Mattie112]

Gomez12 schreef op vrijdag 22 maart 2013 @ 16:37:
Gooi eens simpelweg 2 van die crons weg? Heb je het dan nog steeds?

Ik dacht namelijk dat cron niet aan uitgebreide scheduling deed, op het moment dat de cron-tijd aangekomen is dan start hij 3x je vcgencmd parallel.
Op het moment dat vcgencmd dan zelf bijv een timeout van 30 seconden genereert op het moment dat hij ergens niet direct bij kan komen (omdat bijv een andere vcgencmd een lock ergens op gezet heeft) dan ben je de bietenbrug op. Dan blijf je namelijk in een eeuwige lus zitten op het moment dat die eenmaal gestart is.

Dit zou ook te verhelpen moeten zijn door idd 1x per 5 minuten je script te draaien (of door te kijken of vcgencmd niet alledrie de outputs in 1x kan genereren)

Ik kan het even testen door er 2 weg te halen maar dit is natuurlijk geen oplossing :-) 1x per 5 minuten eigenlijk ook niet.....

Voor zover ik weer is het niet mogelijk meerdere gevens in 1 command op te vragen dus helaas.

Zou het een oplossing zijn om een sh scipt te maken met :

Command 1
Sleep 10
Command 2
Sleep 10
Command 3
Sleep 10

Aangezien 1 command zo`n 0.038sec nodig heeft moet dat tijd genoeg zijn imo :-)

[Orion84]

Lijkt me zeker het proberen waard

Die sleeps zijn dan volgens mij zelfs overbodig, omdat dat shell script pas naar de volgende regel gaat als het vorige command is afgerond.

[Gomez12]

Mattie112 schreef op vrijdag 22 maart 2013 @ 23:04:
[...]
Ik kan het even testen door er 2 weg te halen maar dit is natuurlijk geen oplossing :-) 1x per 5 minuten eigenlijk ook niet.....

Eerst het probleem achterhalen dan pas kijken naar een oplossing.

Dus eerst een werkende situatie krijgen en dan kan je die uitbreiden.

Straks blijkt misschien wel dat 1x dat vcgencmd al niet werkt in cron (omdat die bijv niet omgevingsvariabelen zet), dan kan je je helemaal blindstaren op 3 die niet werken...

[Mattie112]

@Gomez12 dat is ook weer waar....

Ik heb hem nu even als volgt:
1 cron entry die een sh script uitvoert met daar gewoon
command1
command2
command3

ik kijk dit even aan om te zien of het werkt en anders moet ik toch verder zoeken waar het aan kan liggen....