Programma draait niet als crontask

[gepebril]

Hallo,

Ik neem dagelijks automatisch TV programma's op MPEG2-TS via een Dreambox, deze wil ik omzetten naar mpeg4 (h264) via mencoder, een variant op FFmpeg. Dit omdat mencoder overweg kan met duplicated frames, dit in tegenstelling tot FFmeg, die een out of sync file oplevert.

Nu kan ik het van de commandline (linux, Debian) uitvoeren en het werkt, echter zodra ik er een crontask van maak levert het een eindresultaat op van 0 bytes. Het lijkt erop dat Mencoder alleen in een "echte" shell wil draaien. Hoe kan in mencoder om de tuin leiden dat hij denkt dat er iemand handmatig op de commandline commando's intypt? En dat ik via argumenten parameters aan dit commando kan meegeven?

Ik ben de volgende programmas op het spoor (python), pty en pexpect die dit misschien zouden kunnen doen. Maar 100% zeker ben ik niet. Wie weet raad of dit ook de/een oplossing voor mijn probleem is?

Alvast bedankt.

Albert

[ Voor 3% gewijzigd door gepebril op 16-07-2009 16:41 ]

[Woy]

Je vraag heeft niet direct betrekking op programmeren, maar meer met configuratie.

Aangezien het waarschijnlijk om Linux gaat PRG -> Non-Windows Operating Systems

[u_nix_we_all]

Cronjobs worden gestart in een kale shell, zonder alle settings die een normale user heeft, zoals $PATH en allerlei andere variabelen en settings.
Je zult dus een script moeten maken waarin je deze settings en varabelen laadt, of moeten proberen het commando met het volledige path aan te roepen.

[Nick_S]

Als je een bash shell start met

bash -norc

heb je volgens mij de shell te pakken die je programma ook voor z'n kiezen krijgt tijdens het uitvoeren door cron. Als je nu je programma probeert uit te voeren, zie je waarom het fout gaat en kun je een shell script om je programma heen schrijven, die dit allemaal goed zet voordat het je programma uitvoert.

[gepebril]

Er was wat misgegaan met het topic (verplaatst) Er liepen dus twee discussies
HET BELANGRIJKSTE IS EEN OPLOSSING WAARBIJ JE ARGUMENTEN KUNT MEEGEVEN.

De commandline code die werkt.

code:

/usr/bin/mencoder /video/recording_mpg.ts -vf pp=ci,scale=704:400,harddup -ovc x264 -x264encopts bitrate=600 -oac mp3lame -lameopts abr:br=112 -o /video/video_h264.avi

Een vriend van mij kwam tot de volgende code die werkt in de background (in een file). Het grote probleem is dat je geen argumenten kan meegeven. Denk hierbij aan andere sourcefiles en andere video resoluties. En daar gaat het nou net om. Wat ik nu doe ik via een Perl script een file de onderstaande code laten genereren en die laten uitvoeren in een cronjob

code:

set -e
/bin/ksh -c "/usr/bin/mencoder /video/recording_mpg.ts -vf pp=ci,scale=704:400,harddup -ovc x264 -x264encopts bitrate=600 -oac mp3lame -lameopts abr:br=112 -o /video/video_h264.avi"

[ Voor 10% gewijzigd door gepebril op 16-07-2009 16:53 ]

[gepebril]

u_nix_we_all schreef op donderdag 16 juli 2009 @ 14:10:
Cronjobs worden gestart in een kale shell, zonder alle settings die een normale user heeft, zoals $PATH en allerlei andere variabelen en settings.
Je zult dus een script moeten maken waarin je deze settings en varabelen laadt, of moeten proberen het commando met het volledige path aan te roepen.

Dank voor de uitleg. Dat had ik reeds gedaan, zie opmerking (hierboven ergens) met de betreffende code

[u_nix_we_all]

Als je die bovenstaande code nu gewoon in een bestand opslaat en via cron dat bestandje aanroept ? Werkt dat ook niet ? (Moet je wel het bestand even executable maken, met chmod. Of in cron "sh bestand" zetten)
Je parameters en argumenten staan dan gewoon in dat bestand natuurlijk.

[gepebril]

Nick_S schreef op donderdag 16 juli 2009 @ 15:20:
Als je een bash shell start met
[...]
heb je volgens mij de shell te pakken die je programma ook voor z'n kiezen krijgt tijdens het uitvoeren door cron. Als je nu je programma probeert uit te voeren, zie je waarom het fout gaat en kun je een shell script om je programma heen schrijven, die dit allemaal goed zet voordat het je programma uitvoert.

@Nick
Ik heb reeds een oplossing aangereikt gekregen in een bash file vorm. Deze werkt, echter wanneer ik dit in een perl of python script probeer te doen, want ik wil argumenten mee kunnen geven krijg ik weer geen result..... Ook niet als ik argumenten aan het werkende bash script meegeef. zie hier voorbeeld met python

code:

#!/usr/bin/python
import os
cmd = '/usr/bin/mencoder /video/recording_mpg.ts -vf pp=ci,scale=704:400,harddup -ovc x264 -x264encopts bitrate=600 -oac mp3lame -lameopts abr:br=112 -o /video/video_h264.avi'
os.system(cmd)

[gepebril]

u_nix_we_all schreef op donderdag 16 juli 2009 @ 16:48:
Als je die bovenstaande code nu gewoon in een bestand opslaat en via cron dat bestandje aanroept ? Werkt dat ook niet ? (Moet je wel het bestand even executable maken, met chmod. Of in cron "sh bestand" zetten)
Je parameters en argumenten staan dan gewoon in dat bestand natuurlijk.

code 1 werkt niet
code 2 werkt wel. Oplossing twee zou goed zijn maar als ik argumenten meegeef aan de onderste krijg ik weer 0 bytes als resultaat

[u_nix_we_all]

Leg eens uit wat je precies bedoelt met argumenten meegeven ?
Cron is niet interactief, dus hoe en waar wil je wat meegeven dan ?
En, perl ? python ? helemaal niet nodig hoor.
Maak een shell-scriptje waarin die 2e code staat, en roep dat aan vanuit cron ? Als dat niet werkt, kun je dat commando in het scriptje aanvullen met redirection van de standard-out messages door er ">> /path/naar/logfile.txt" aan toe te voegen.

[gepebril]

u_nix_we_all schreef op donderdag 16 juli 2009 @ 17:03:
Leg eens uit wat je precies bedoelt met argumenten meegeven ?
Cron is niet interactief, dus hoe en waar wil je wat meegeven dan ?
En, perl ? python ? helemaal niet nodig hoor.
Maak een shell-scriptje waarin die 2e code staat, en roep dat aan vanuit cron ? Als dat niet werkt, kun je dat commando in het scriptje aanvullen met redirection van de standard-out messages door er ">> /path/naar/logfile.txt" aan toe te voegen.

Wat is wil is heel simpel. Ik wil vanuit een database (MySQL) opnames kunnen scedulen (opnames en encoding). En even uit het hoofd kun je MySQL niet zo aanspreken vanuit Bash, maar dit terzijde. Wat ik in code zou willen, wat dan elke minuut aangeroepen wordt.

code:

<check DB of er opnamen zijn die opgenomen dienen te worden>
if ($ProgrammToBeRecorded == "true")
{ <switch to channel>
  /usr/bin/mencoder /video/name_recording.ts -vf pp=ci,scale=704:400,harddup -ovc x264 -x264encopts bitrate=600 -oac mp3lame -lameopts abr:br=112 -o /video/name_recording.avi
}

waarbij dus name_recording variabelen zijn die ik uit een database haal.
eventueel de transcode settings voor mencoder ook. Mencode is het enige gedeelte dat "niet meewerkt". De rest is allemaal al geprogrammeerd

[BCC]

Volgens mij mis je een gedachte stap:

Je wilt volgens mij:
cron -> scriptje dat db doorzoekt en comanndo's construeert -> memcoder

En je hebt nu:
cron -> memcoder

Eventele parameters voor memcoder wil je in je scriptje hebben. Cron wil je alleen maar gebruiken om iets op een bepaalde tijd een trap te geven.

En mysql is prima aan te spreken vanuit bash. Ik zou het alleen in iets hoger niveau taal doen zoals perl, python of ruby.

[ Voor 20% gewijzigd door BCC op 16-07-2009 17:47 ]

[gertvdijk]

Maak een leuk scriptje dat doet wat het moet doen. Maakt geen kont uit in welke interpreter je dat maakt en gebruik Cron alleen om het op gezette tijden een trap te geven, zoals BCC zegt.

[gepebril]

Dank heren,

BCC en Gertvdijk snappen het helemaal. Alleen het probleem blijft. Als ik mencoder via Perl/Bash vanaf de commandline aanroep. Dus zelf intyp, of via een script uitvoer terwijl ik ingelogd ben gaat alles goed. Zet ik die coderegel in de crontab, zoals hieronder

code:

46 18  * * * /usr/bin/mencoder /video/video.ts -vf pp=ci,scale=1024:576,harddup -ovc x264 -x264encopts bitrate=600 -oac mp3lame -lameopts abr:br=112 -o /home/video.avi &> /home/video/video.log

Dan krijg ik geen video.avi en een logfile van 0kb groot. Wat is er aan de hand? En nog veel beter wat kan ik doen omdat te voorkomen!

[ Voor 4% gewijzigd door gepebril op 16-07-2009 19:05 ]

[gertvdijk]

gepebril schreef op donderdag 16 juli 2009 @ 18:51:
BCC en Gertvdijk snappen het helemaal. Alleen het probleem blijft.

Tja, als jij de aanwijzingen niet opvolgt blijft het probleem ja.

gepebril schreef op donderdag 16 juli 2009 @ 18:51:
Dan krijg ik geen video.avi en een logfile van 0kb groot. Wat is er aan de hand?

Ik zou zeggen, kijk eens wat Cron voor je logt, m.a.w. wat de output is ten tijde van het uitvoeren van het command.

[gepebril]

gertvdijk schreef op donderdag 16 juli 2009 @ 19:06:
[...]

Tja, als jij de aanwijzingen niet opvolgt blijft het probleem ja.

[...]

Ik zou zeggen, kijk eens wat Cron voor je logt, m.a.w. wat de output is ten tijde van het uitvoeren van het command.

Met de eerste passage wilde ik alleen maar zeggen dat zij begrijpen wat voor TOTAAL OPLOSSING ik uiteindelijk wil bouwen. Echter dat is niet het probleem hier. Dus goed dat jullie het totale plaatje begrijpen alleen gaat het om het feit waarom iets niet vanuit de crontask werkt

Je tweede opmerking is reeds beantwoord namelijk het levert een lege logfile op. Tenzij je bedoelt te zeggen dat de cron logging iets anders is dan het redirecten van alle outputs van een commando naar een file

[ Voor 9% gewijzigd door gepebril op 16-07-2009 19:28 ]

[gertvdijk]

gepebril schreef op donderdag 16 juli 2009 @ 19:15:
Met de eerste passage wilde ik alleen maar zeggen dat zij begrijpen wat voor TOTAAL OPLOSSING ik uiteindelijk wil bouwen. Echter dat is niet het probleem hier. Dus goed dat jullie het totale plaatje begrijpen alleen gaat het om het feit waarom iets niet vanuit de crontask werkt

Dan begrijpen wij elkaar allebei verkeerd. Wat we bedoelen is een bash sriptje maken die bestaat uit twee regels:

Bash:

#!/bin/bash
commando

Dus helemaal niet iets om later te doen, maar gewoon iets wat je gelijk kan proberen. Kwestie van copy/paste.

gepebril schreef op donderdag 16 juli 2009 @ 19:15:
Je tweede opmerking is reeds beantwoord namelijk het levert een lege logfile op. Daaruit kan je natuurlijk niet echt veel concluderen, behalve dan dat er wel iets gepoogd wordt uit te voeren.

Lees nog eens. Ik bedoel wat *Cron* logt, niet je eigen stdout logger.

[gepebril]

Ok Gert,

Resumerend.
1) vanaf commandline gaat het goed
2) vanuit de background (&) gaat het goed
3) vanuit een bash script gaat het goed
4) starten we het bashscript vanuit crontab dan levert stdio geen output op, ook stderr etc niet
5) hoe kan ik de logging van de cron bekijken?

Vwb vraag 5, dat blijkt dus in /var/log/syslog te staan. Daarin wordt alleen vermeldt dat hij gestart is, verder niks.....

[ Voor 17% gewijzigd door gepebril op 16-07-2009 19:34 ]

[gertvdijk]

Ik zie dat je Cron commando in de background draait. Dat lijkt me niet handig, aangezien Cron het voor je al op de achtergrond draait.
De output van Cron gaat standaard naar je mail (als je dat hebt geconfigureerd), aangezien het voornamelijk op servers wordt gebruikt. Op desktops wordt voornamelijk anacron gebruikt.

[gepebril]

gertvdijk schreef op donderdag 16 juli 2009 @ 19:43:
Ik zie dat je Cron commando in de background draait. Dat lijkt me niet handig, aangezien Cron het voor je al op de achtergrond draait.
De output van Cron gaat standaard naar je mail (als je dat hebt geconfigureerd), aangezien het voornamelijk op servers wordt gebruikt. Op desktops wordt voornamelijk anacron gebruikt.

Cron in de background, waar kun je dat aan zien ????
Er is op die betreffende Debian machine geen mail geinstalled.
In mijn zoektocht op het Net lijkt niemand hier een oplossing voor te hebben, zie b.v. hier
http://www.linuxquestions...-executed-by-cron-703903/

Ik denk dat ik gewoon een terminal moet zien te faken en de computer moet laten denken dat ik het zelf intyp. Denk dat het een soort beveiliging is. Zal iig niet makkelijk zijn, daar niemand op het Net hier een oplossing voor gevonden heeft.

[blaataaps]

Misschien moet ik dan de eerste zijn die het suggereert op het Net, maar heb je al eens naar screen gekeken?

[BCC]

gepebril schreef op donderdag 16 juli 2009 @ 20:03:
[...]
Cron in de background, waar kun je dat aan zien ????
Er is op die betreffende Debian machine geen mail geinstalled.

Je commado is anders, want je doet iets in de trand van "&>". Dat redirect error levels, ik denk dat hij in de war is met "& >". Wat zegt je server als je als root "mail" intikt?

In mijn zoektocht op het Net lijkt niemand hier een oplossing voor te hebben, zie b.v. hier
http://www.linuxquestions...-executed-by-cron-703903/

Dat gaat over het capturen van video (dus hardware ingeratie). Dat is zeer waarschijnlijk een ander probleem.

Ik denk dat ik gewoon een terminal moet zien te faken en de computer moet laten denken dat ik het zelf intyp.

Wat ons weer terugbrengt naar een van de eerste posts: onder welke shell draait je cron. sh of bash?

[ Voor 46% gewijzigd door BCC op 16-07-2009 21:39 ]

[Verwijderd]

Heb je de cronjob aangemaakt met crontab -e, of heb je /etc/crontab aangepast?

In het laaste geval moet je ook nog de gebruikersnaam vermelden:

code:

46 18  * * * video /usr/bin/mencoder /video/video.ts -vf pp=ci,scale=1024:576,harddup -ovc x264 -x264encopts bitrate=600 -oac mp3lame -lameopts abr:br=112 -o /home/video.avi >/home/video/video.log 2>&1

Hier draait de cronjob als user "video".

[gepebril]

BCC schreef op donderdag 16 juli 2009 @ 21:31:
[...]


Je commado is anders, want je doet iets in de trand van "&>". Dat redirect error levels, ik denk dat hij in de war is met "& >". Wat zegt je server als je als root "mail" intikt?

Indien ik mail intik krijg ik dit:
The program 'mail' can be found in the following packages:
* mailx
* mailutils
Try: apt-get install <selected package>
-bash: mail: command not found
&> heb ik ipv & > dat volgens http://www.faqs.org/docs/...ash-Prog-Intro-HOWTO.html sectie 3.6 alles naar een file zou routen. Blijkbaar verkeerd geinterpreteerd
[/quote]

[...]

Dat gaat over het capturen van video (dus hardware ingeratie). Dat is zeer waarschijnlijk een ander probleem.

Ik gebruik een file als input hij een videokaart. Wie weet is het iets anders, het was maar een van de voorbeelden die ik aanhaalde


[...]

Wat ons weer terugbrengt naar een van de eerste posts: onder welke shell draait je cron. sh of bash?

Bedoel je mijn proces of het de gehele cron (alle opdrachten in het systeem)?

[gepebril]

Verwijderd schreef op donderdag 16 juli 2009 @ 21:38:
Heb je de cronjob aangemaakt met crontab -e, of heb je /etc/crontab aangepast?

In het laaste geval moet je ook nog de gebruikersnaam vermelden:

code:

46 18  * * * video /usr/bin/mencoder /video/video.ts -vf pp=ci,scale=1024:576,harddup -ovc x264 -x264encopts bitrate=600 -oac mp3lame -lameopts abr:br=112 -o /home/video.avi >/home/video/video.log 2>&1

Hier draait de cronjob als user "video".

Werk altijd met crontab -e

[blaataaps]

Heb je de foutmelding die je zelf paste ook gelezen? Heb je mijn berichtje ook gelezen?

[gepebril]

Ik denk dat we het anders moeten proberen, anders gaat er niks nuttigs uitkomen waarom werk code example 1 wel en example 2 niet. Beide als file met executable rechten gestart

code:

#!/bin/bash
set -e
/bin/bash -c "nohup /usr/bin/mencoder /video/video.ts -vf pp=ci,scale=1024:576,harddup -ovc x264 -x264encopts bitrate=600 -oac mp3lame -lameopts abr:br=112 -o /video/video.avi"

code:

#!/bin/bash
STRING="nohup /usr/bin/mencoder /video/video.ts -vf pp=ci,scale=1024:576,harddup -ovc x264 -x264encopts bitrate=600 -oac mp3lame -lameopts abr:br=112 -o /video/video.avi"
set -e
/bin/bash -c $STRING

Als ik hier heb ik ook iets waar mee ik verder kan

[gepebril]

blaataaps schreef op donderdag 16 juli 2009 @ 22:25:
Heb je de foutmelding die je zelf paste ook gelezen? Heb je mijn berichtje ook gelezen?

Welke foutmelding?

Screen heb ik gelezen. Alleen blijf ik dan het probleem houden als ik iets in een nieuwe shell start hoe krijg ik daar informatie in? Zal eens kijken of ik voorbeelden met bash en screen vind.

[BCC]

Waarom nu ineens weer nohup?

[gepebril]

BCC schreef op donderdag 16 juli 2009 @ 22:40:
Waarom nu ineens weer nohup?

Toen ik met dit projectje startte zat er een unix guru naast me die even wat snel inelkaar hackte wat werkte. Waarom hij het zo deed weet ik niet, alleen dat het werkte. Meende me te herinneren dat het zonder de nohup ook niet werkte en mencoder er zo maar na een paar seconden coderen mee stopte

Ik meende dat het toen een bug was in Mencoder die het ons niet mogelijk maakte om het in de cron te starten. Aangezien eigenlijk alles zo werkte was ik tevreden. Maar nu wil ik uitbreiden en moet het probleem toch oplossen.

[gepebril]

gepebril schreef op donderdag 16 juli 2009 @ 22:34:
[...]

Welke foutmelding?

Screen heb ik gelezen. Alleen blijf ik dan het probleem houden als ik iets in een nieuwe shell start hoe krijg ik daar informatie in? Zal eens kijken of ik voorbeelden met bash en screen vind.

screen werkt ook heel goed op de commandline, alleen hetzelfde verhaal als je dat vanaf de cron doet

We geven nog niet op, pffffffff

[gepebril]

Het probleem is opgelost, het is geen nette oplossing in mijn ogen, maar goed

in crontab

code:

33 00 * * * /usr/bin/screen -d -m -s /home/video/encode_video

En als encode_video

code:

#!/bin/bash
STRING=" /usr/bin/nohup /usr/bin/mencoder /video/video_bron.ts -vf pp=ci,scale=1024:576,harddup -ovc x264 -x264encopts bitrate=600 -oac mp3lame -lameopts abr:br=112 -o /home/video/video_result.avi"
set -e
/bin/ksh -c "$STRING"

Indien er niet met screen gestart werd, werd gelijk bij het begin van het coderen gestopt. Dank u wel voor alle hulp zover

Nu nog een executable/bash script zien te vinden dat een query kan doen op een database...

Verbeteringen zijn natuurlijk altijd welkom

[ Voor 6% gewijzigd door gepebril op 17-07-2009 00:42 ]

[Rainmaker]

Nu zorgen cron, screen en nohup er alle 3 voor dat het scriptje in de achtergrond draait.

Lijkt me wat overkill, maar als het werkt, werkt het... Mooi.

[sam.vimes]

Vervang je cron-regel

code:

46 18  * * * /usr/bin/mencoder /video/video.ts -vf pp=ci,scale=1024:576,harddup -ovc x264 -x264encopts bitrate=600 -oac mp3lame -lameopts abr:br=112 -o /home/video.avi &> /home/video/video.log

door

code:

46 18  * * * /usr/bin/mencoder /video/video.ts -vf pp=ci,scale=1024:576,harddup -ovc x264 -x264encopts bitrate=600 -oac mp3lame -lameopts abr:br=112 -o /home/video.avi

(dus verwijder die FOUTIEVE redirect) en lees na uitvoering je mail.
Alles wat in een cron-job naar stdout en stderr gaat wordt door cron opgevangen en naar de eigenaar van de cronjob gemaild.

De tekens '&>' hebben afhankelijk van de gebruikte shell verschillende betekenis. In bash (waarschijnlijk de shell die je interactief gebruikt), is

code:

commando &> logfile

hetzelfde als

code:

commando > logfile 2>&1

waarmee dus stdout en stderr naar dezelfde logfile worden gestuurd.

In cronjobs is de gebruikte shell echter /bin/sh, en daarin betekent '&>' wat anders.
De constructie commando &>logfile zoals jij gebruikt, doet dan het volgende:

1. de door cron gestarte shell (default /bin/sh) start 'commando' als subproces. Dat is in dit geval mencoder. Dit commando wordt vanwege de '&' in asynchrone modus (in de achtergrond) gestart, dus de shell wacht niet tot het klaar is maar gaat door met het volgende commando na de '&'.
2. de shell voert een 'leeg' commando uit met stdout geredirect naar 'logfile'. Dit creëert een logfile van 0 bytes.
3. nu is het script afgelopen. Voordat de shell exit, krijgen alle nog lopende achtergrondprocessen (in dit geval dus mencoder) een SIGTERM.

Resultaat is dus een lege logfile en een mencoder die (schat ik) ongeveer 0.01 seconde heeft gedraaid.
Niettemin zou er log-info van mencoder in je mail moeten staan, al was het maar de melding 'Terminated' vanwege de SIGTERM.

[ Voor 11% gewijzigd door sam.vimes op 17-07-2009 11:35 . Reden: Verschillende &> in bash en sh ]