gratifiant > linux.debian.user.french

Anouk LE CLOEREC (01/06/2019, 13h40)
Bonjour,
J?essaie de programmer un registrement de l?entrée ligne de ma carte son.Pour
l?enregistrement j?utilise arecord. La commande fonctionne bien en direct :
arecord -f cd -d 10 /mnt/dd1/Musique/test.wav

Par contre je voudrais pouvoir la programmer via crontab et là çacoince. J?ai essayer
plusieurs configuration mais rien :
>14 11 * * * /usr/bin/arecord -f cd -d 10 /mnt/dd1/Musique/test.wav


ne se passe. Idem si je met un user (moi ou root)
J?ai essayer en créant un script *.sh avec la commande et de lancer le script via crontab,
rien non plus. Même en copiant le script dans /usr/local/bin

Ci-dessous le fichier crontab :

># Edit this file to introduce tasks to be run by cron. # # Each task to run has to be defined

through a single line # indicating with different fields when the task willbe run # and what
command to run for the task # # To define the time you can provide concrete values for #
minute (m), hour (h), day of month (dom), month (mon), # and day of week (dow) or use '*'
in these fields (for 'any'). # # Notice that tasks will be started based on the cron's system #
daemon's notion of time and timezones. # # Output of the crontab jobs (including errors)
is sent through # email to the user the crontab file belongs to (unless redirected). # # For
example, you can run a backup of all your user accounts # at 5 a.m every week with: # 0 5
* * 1 tar -zcf /var/backups/home.tgz /home/ # # For more information see the manual
pages of crontab(5) and cron(8) # # m h dom mon dow command 14 11 * * */usr/bin/
arecord -f cd -d 10 /mnt/dd1/Musique/test.wav

Merci
Florian Blanc (01/06/2019, 13h50)
Tous les jours à 11h14 il exécute ceci : usr/bin/arecord -f cd -d10
/mnt/dd1/Musique/test.wav

est-ce correct ?
Que te répond le terminal quand tu exécutes ceci manuellement ?

Cordialement

On Sat, Jun 1, 2019, 13:33 Anouk LE CLOEREC <tulum> wrote:
[..]
Ph. Gras (01/06/2019, 14h10)
Salut !

> Ci-dessous le fichier crontab :
> ># Edit this file to introduce tasks to be run by cron.

> #
> # Each task to run has to be defined through a single line


> # m h dom mon dow command
> 14 11 * * * /usr/bin/arecord -f cd -d 10 /mnt/dd1/Musique/test.wav
> Merci


# service cron restart

Bonne réception,

Ph. Gras
Francois Lafont (01/06/2019, 15h00)
Bonjour,

On 6/1/19 12:51 PM, Anouk LE CLOEREC wrote:

> 14 11 * * * /usr/bin/arecord -f cd -d 10 /mnt/dd1/Musique/test.wav


C'est peut-être un problème d'environnement d'exécution. Par exemple
quand tu lances la commande de manière interactive, il y a une variable
d'environnement définie dont la commande a besoin mais qui n'est pas
définie lorsque c'est cron qui lance la commande...

Pour avoir une chance d'obtenir un message d'erreur (qui puisse te
mettre sur une piste), insère tout ça dans un script bash (ou sh)
avec quelque chose comme ça :

exec >/tmp/arecord.log 2>&1
echo begin
/usr/bin/arecord -f cd -d 10 /mnt/dd1/Musique/test.wav
echo end

Si, dans l'environnement de ton cron, la commande arecord affiche
un message d'erreur ou autre, il sera inscrit dans le fichier
/tmp/arecord.log entre la ligne "begin" et la ligne "end" (tu peux
bien sûr prendre un autre chemin de fichier de log mais il faudra
juste être sûr que le compte Unix qui lance le cron est en mesure
d'écrire dans ce fichier de log, ce qui est a priori le cas dans
/tmp/).

Si en revanche, il n'y a aucun message d'erreur ou autre, ça va
être compliqué... Regarder alors dans les logs de la distribution
éventuellement.

À+
Tulum (01/06/2019, 16h10)
Le samedi 1 juin 2019, 14:58:56 CEST Francois Lafont a écrit :
[..]
> ALSA lib pcm_dsnoop.c:638:(snd_pcm_dsnoop_open) unable to open slave
> arecord: main:828: erreur à l'ouverture audio: Périphérique ou ressource
> occupé end


Je sais donc qu'il y a un problème d'accès à la carte son via une tâche cron,
mais je ne sais pas le résoudre.
Tulum (01/06/2019, 16h10)
Le samedi 1 juin 2019, 14:04:23 CEST Ph. Gras a écrit :
[..]
ajh-valmer (01/06/2019, 16h20)
Bonjour,

J'ai le même problème avec cette commande :
30 8 * * * e2fsck /dev/sda2

même avec un script binaire,
#!/bin/bash
e2fsck /dev/sda2

Rien à faire, crontab ne fait rien.

Ajh Valmer
yamo' (01/06/2019, 17h30)
Salut,
ajh-valmer a tapoté le 01/06/2019 16:20:

> J'ai le même problème avec cette commande :
> 30 8 * * * e2fsck /dev/sda2
> même avec un script binaire,
> #!/bin/bash
> e2fsck /dev/sda2
> Rien à faire, crontab ne fait rien.


Et avec le chemin complet?

/sbin/e2fsck
ajh-valmer (01/06/2019, 19h20)
On Saturday 01 June 2019 17:08:28 yamo' a tapoté
> ajh-valmer a tapoté le 01/06/2019 16:20:


> Et avec le chemin complet ? :
> /sbin/e2fsck


J'ai modifié, je vais voir...

Il n'y aurait pas un autre élément à ajouter,
comme dans l'autre cas "/usr/bin/arecord",
(qui a résolu le problème),
voire une option à mettre après la commande e2fsck ?

Merci.
Florian Blanc (01/06/2019, 21h50)
Essayez votre commande ou script à partir de l'utilisateur et quand ça
fonctionne, "crontab -e" puis ajoutez le. De cette manière je n'ai jamais
eu de problèmes. Et chaque user a ses crons

On Sat, Jun 1, 2019, 19:11 ajh-valmer <ajh.valmer> wrote:
[..]
Francois Lafont (02/06/2019, 10h50)
On 6/1/19 5:33 PM, Tulum wrote:

> En rajoutant : XDG_RUNTIME_DIR=/run/user/1000 dans ma commande crontab cela fonctionne :
> 30 17 1 6 * XDG_RUNTIME_DIR=/run/user/1000 /usr/bin/arecord -f cd -d 10 /mnt/dd1/Musique/test.wav


Ok, c'était donc bien un souci d'environnement d'exécution.

> Ce que je comprends pas c'est que j'avais testé mettant le user (à la place de XDG_RUNTIME_DIR) et ça e marchait. Il aurait charger toutes les variables de l'utilisateur, non ?


Je ne suis pas sûr d'avoir compris la question mais cron a tendance à
avoir une liste de variables d'environnement très limitée par rapport à
un shell interactif. Tu peux ouvrir un shell interactif avec ton compte
perso et voir toutes les variables d'environnement avec la commande "env".

Si tu lances cette même commande (env > /tmp/env.log) dans un script lancé
via un cron (avec le même compte Unix), tu verras qu'il y a beaucoup moins de
variables d'environnement.

J'imagine que XDG_RUNTIME_DIR était bien définie dans un shell interactif
mais pas dans le contexte d'une exécution via cron.

À+
Tulum (02/06/2019, 12h20)
Le dimanche 2 juin 2019, 10:45:24 CEST Francois Lafont a écrit :
[..]
> J'imagine que XDG_RUNTIME_DIR était bien définie dans un shell interactif
> mais pas dans le contexte d'une exécution via cron.
> À+ Merci,


En fait j'avais trouver sur G**gle que l'on pouvait ajouter le user à
l'emplacement où j'ai mis la variable XDG_RUNTIME_DIR. Mais là ça ne marchait
pas. J'aurai pensé qu'en mettant le user, cron aurait chargé l'ensembledes
variables d'environnement de l'user mentionné.
Erwann Le Bras (04/06/2019, 15h00)
Le 02/06/2019 à 10:45, Francois Lafont a écrit :
[..]
> variables d'environnement.
> J'imagine que XDG_RUNTIME_DIR était bien définie dans un shell interactif
> mais pas dans le contexte d'une exécution via cron.


bonjour

Le CRON lance un shell utilisateur en chargeant l'environnement par défaut.
Ce qui signifie que l'environnement chargé par le .profile/.bashrc ou
autre à la connexion utilisateur n'est pas chargé.
Donc la bonne pratique est de lancer un shell qui commence par charger
l'environnement dans le shell courant, défini la log puis lance les
commandes à réaliser.

amitiés,
Florian Blanc (08/06/2019, 21h20)
grep CRON /var/log/syslog

Le sam. 8 juin 2019 à 19:15, G2PC <g2pc> a écrit :
[..]
Florian Blanc (08/06/2019, 22h50)
la tâche cron s'est bien lancée alors regardes tes logs du logiciel

Le sam. 8 juin 2019 à 21:34, G2PC <g2pc> a écrit :
[..]

Discussions similaires