[RESOLU] Re: Coupures OpenVPN (Inactivity timeout)

[Olivier]

Je me sens un peu bête mais j'avais deux instances du client OpenVPN
qui "tournaient en parallèle". En supprimant l'une des deux instances,
tout est rentré dans l'ordre.

Merci pour votre aide !



Le jeu. 27 janv. 2022 à 16:54, NoSpam  a écrit :
>
> Bonjour
>
> Le 27/01/2022 à 16:41, Olivier a écrit :
> > Bonjour,
> >
> > J'ai un serveur OpenVPN sur Debian 9, sur une machine fournie par un
> > hébergeur Internet.
> > À ce serveur, j'ai une cinquantaine de clients OpenVPN sur machine
> > Debian de toutes les générations (Jessie, à Bullseye).
> > Depuis quelques mois, j'observe des déconnexions temporaires.
> >
> > Sur une nouvelle machine dotée de Bullseye, j'ai décidé d'investiguer.
> >
> > Dans les logs du client, j'ai la séquence ci-après répétée toutes les
> > 230 sec.2022-01-27 15:41:24 [server] Inactivity timeout
> > (--ping-restart), restarting
> > 2022-01-27 15:41:24 SIGUSR1[soft,ping-restart] received, process restarting
> > 2022-01-27 15:41:29 WARNING: No server certificate verification method
> > has been enabled.  See http://openvpn.net/howto.html#mitm for more
> > info.
> > 2022-01-27 15:41:29 TCP/UDP: Preserving recently used remote address:
> > [AF_INET]1.2.3.4:1194
> > 2022-01-27 15:41:29 UDP link local: (not bound)
> > 2022-01-27 15:41:29 UDP link remote: [AF_INET]1.2.3.4:1194
> > 2022-01-27 15:41:29 [server] Peer Connection Initiated with
> > [AF_INET]1.2.3.4:1194
> > 2022-01-27 15:41:30 Preserving previous TUN/TAP instance: tun0
> > 2022-01-27 15:41:30 Initialization Sequence Completed
> >
> > Voici la config du client:
> > client
> > dev tun
> > proto udp
> > remote 1.2.3.4 1194
> > resolv-retry infinite
> > nobind
> > user nobody
> > group nogroup
> > persist-key
> > persist-tun
> > ca /etc/openvpn/client/ca.crt
> > cert /etc/openvpn/client/client_vie.crt
> > key /etc/openvpn/client/client_vie.key
> > comp-lzo
> > verb 1
> > ping 30
>
>
> Je remplacerai ping 30 par keep-alive 10 60 et rajouterai tun-mtu 1500,
> sur le serveur également. Pas de mssfix ?
>
>
> >
> >
> > Voici la config du serveur:
> > port 1194
> > proto udp
> > dev tun
> > topology subnet
> > ca /etc/openvpn/easy-rsa/keys/ca.crt
> > cert /etc/openvpn/easy-rsa/keys/server.crt
> > key /etc/openvpn/easy-rsa/keys/server.key
> > dh /etc/openvpn/easy-rsa/keys/dh1024.pem
> > server 10.19.0.0 255.255.254.0
> > ifconfig-pool-persist /etc/openvpn/server1/ipp.txt
> > client-to-client
> > keepalive 10 120
> > comp-lzo
> > user nobody
> > group nogroup
> > persist-key
> > persist-tun
> > status /etc/openvpn/server1/openvpn-status.log
> > verb 1
> >
> > Je lance en parallèle deux séries de ping:
> > ping -c120 -q 1.2.3.4
> > ping -c120 -q 10.19.0.1
> >
> > Aucune perte, sur la première. des pertes significatives sur la deuxième.
> >
> > Naivement, je pensais que le ping 10.19.0.1 a lieu seul, génère de
> > l'activité OpenVPN qui interdit en retour le inactivity Timeout.
> >
> > Qu'en pensez-vous ?
> > Dans quelle direction chercher ?
> >
> > Slts
>

Re: Coupures OpenVPN (Inactivity timeout)

[NoSpam]

Bonjour

Le 27/01/2022 à 16:41, Olivier a écrit :

Bonjour,

J'ai un serveur OpenVPN sur Debian 9, sur une machine fournie par un
hébergeur Internet.
À ce serveur, j'ai une cinquantaine de clients OpenVPN sur machine
Debian de toutes les générations (Jessie, à Bullseye).
Depuis quelques mois, j'observe des déconnexions temporaires.

Sur une nouvelle machine dotée de Bullseye, j'ai décidé d'investiguer.

Dans les logs du client, j'ai la séquence ci-après répétée toutes les
230 sec.2022-01-27 15:41:24 [server] Inactivity timeout
(--ping-restart), restarting
2022-01-27 15:41:24 SIGUSR1[soft,ping-restart] received, process restarting
2022-01-27 15:41:29 WARNING: No server certificate verification method
has been enabled.  See http://openvpn.net/howto.html#mitm for more
info.
2022-01-27 15:41:29 TCP/UDP: Preserving recently used remote address:
[AF_INET]1.2.3.4:1194
2022-01-27 15:41:29 UDP link local: (not bound)
2022-01-27 15:41:29 UDP link remote: [AF_INET]1.2.3.4:1194
2022-01-27 15:41:29 [server] Peer Connection Initiated with
[AF_INET]1.2.3.4:1194
2022-01-27 15:41:30 Preserving previous TUN/TAP instance: tun0
2022-01-27 15:41:30 Initialization Sequence Completed

Voici la config du client:
client
dev tun
proto udp
remote 1.2.3.4 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/client_vie.crt
key /etc/openvpn/client/client_vie.key
comp-lzo
verb 1
ping 30



Je remplacerai ping 30 par keep-alive 10 60 et rajouterai tun-mtu 1500, 
sur le serveur également. Pas de mssfix ?






Voici la config du serveur:
port 1194
proto udp
dev tun
topology subnet
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 10.19.0.0 255.255.254.0
ifconfig-pool-persist /etc/openvpn/server1/ipp.txt
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /etc/openvpn/server1/openvpn-status.log
verb 1

Je lance en parallèle deux séries de ping:
ping -c120 -q 1.2.3.4
ping -c120 -q 10.19.0.1

Aucune perte, sur la première. des pertes significatives sur la deuxième.

Naivement, je pensais que le ping 10.19.0.1 a lieu seul, génère de
l'activité OpenVPN qui interdit en retour le inactivity Timeout.

Qu'en pensez-vous ?
Dans quelle direction chercher ?

Slts

Coupures OpenVPN (Inactivity timeout)

[Olivier]

Bonjour,

J'ai un serveur OpenVPN sur Debian 9, sur une machine fournie par un
hébergeur Internet.
À ce serveur, j'ai une cinquantaine de clients OpenVPN sur machine
Debian de toutes les générations (Jessie, à Bullseye).
Depuis quelques mois, j'observe des déconnexions temporaires.

Sur une nouvelle machine dotée de Bullseye, j'ai décidé d'investiguer.

Dans les logs du client, j'ai la séquence ci-après répétée toutes les
230 sec.2022-01-27 15:41:24 [server] Inactivity timeout
(--ping-restart), restarting
2022-01-27 15:41:24 SIGUSR1[soft,ping-restart] received, process restarting
2022-01-27 15:41:29 WARNING: No server certificate verification method
has been enabled.  See http://openvpn.net/howto.html#mitm for more
info.
2022-01-27 15:41:29 TCP/UDP: Preserving recently used remote address:
[AF_INET]1.2.3.4:1194
2022-01-27 15:41:29 UDP link local: (not bound)
2022-01-27 15:41:29 UDP link remote: [AF_INET]1.2.3.4:1194
2022-01-27 15:41:29 [server] Peer Connection Initiated with
[AF_INET]1.2.3.4:1194
2022-01-27 15:41:30 Preserving previous TUN/TAP instance: tun0
2022-01-27 15:41:30 Initialization Sequence Completed

Voici la config du client:
client
dev tun
proto udp
remote 1.2.3.4 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/client_vie.crt
key /etc/openvpn/client/client_vie.key
comp-lzo
verb 1
ping 30


Voici la config du serveur:
port 1194
proto udp
dev tun
topology subnet
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 10.19.0.0 255.255.254.0
ifconfig-pool-persist /etc/openvpn/server1/ipp.txt
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /etc/openvpn/server1/openvpn-status.log
verb 1

Je lance en parallèle deux séries de ping:
ping -c120 -q 1.2.3.4
ping -c120 -q 10.19.0.1

Aucune perte, sur la première. des pertes significatives sur la deuxième.

Naivement, je pensais que le ping 10.19.0.1 a lieu seul, génère de
l'activité OpenVPN qui interdit en retour le inactivity Timeout.

Qu'en pensez-vous ?
Dans quelle direction chercher ?

Slts

Re: Exit le timeout de 1min 30s

[Pierre ESTREM]

Bonsoir,

Oui, si vous mentionnez une UUID dans /etc/fstb, ne pas mettre les '"' :
# exemple
UUID=abcde...   

On peut aussi remplacer celles-ci par les labels des partitions...

Mais à vous lire, j'ai cru comprendre que certains n'avaient pas ce 
timeout de 90s alors qu'ils auraient un fstab "avec UUID", exact ?

Dans ce cas comme suggéré j'aurais des erreurs dans un "log".

pierre estrem


Le 10/11/2018 à 16:15, Gaëtan Perrier a écrit :

Le samedi 10 novembre 2018 à 08:40 +0100, Pascal Hambourg a écrit :

Le 09/11/2018 à 22:54, Pierre ESTREM a écrit :

Avec AccessDV Linux base Debian Jessie je constatais un compte à rebours
de 1'30'' avant d'arriver au LightDM.
Comme pour moi certains devaient trouver cela pénible.

Après une bévue, j'ai remplacé les UUID qui figuraient dans /etc/fstab
par leurs fichiers de périphériques (/dev/sdxn).

C'est une mauvaise idée. Les noms de périphériques /dev/sd* ne sont pas
stables.

Oui c'est pour ça que je n'ai pas trop envie de remettre les sdx ...


Quelle ne fut pas ma surprise de découvrir que ce décompte de 90s avait
disparu ! :)

Si quelqu'un peut me (nous) expliquer la raison du compteur et sa
disparition qu'il me (nous) l'apprenne.

Un des UUID dans /etc/fstab était erroné. Assez souvent, c'est celui du
swap qui a été modifié par une autre installation.



Je viens de vérifier mon fstab et ce ne sont pas les UUID qui sont utilisées
mais les PARTUUID. Mais j'ai vérifié et par rapport à ce qu'indique blkid tout
est bon.

Gaëtan

Re: Exit le timeout de 1min 30s

[Gaëtan Perrier]

Le samedi 10 novembre 2018 à 08:12 +0100, Michel a écrit :
> 
> Bonjour,
> 
> Peut-être l'UUID de la swap qui a changé. Le mettre à jour dans
> /etc/initramfs-tools/conf.d/resume.
> 
> Il doit contenir:
> 
> RESUME=UUID=---
> 
> Remplacer les 0 par UUID de la partition de swap.
> 

Merci ! Dans mon cas c'était bien celui là qui posait problème !!! 
Maintenant c'est nickel :)

Gaëtan


signature.asc
Description: This is a digitally signed message part

Re: Exit le timeout de 1min 30s

[Gaëtan Perrier]

Le samedi 10 novembre 2018 à 08:40 +0100, Pascal Hambourg a écrit :
> Le 09/11/2018 à 22:54, Pierre ESTREM a écrit :
> > Avec AccessDV Linux base Debian Jessie je constatais un compte à rebours 
> > de 1'30'' avant d'arriver au LightDM.
> > Comme pour moi certains devaient trouver cela pénible.
> > 
> > Après une bévue, j'ai remplacé les UUID qui figuraient dans /etc/fstab 
> > par leurs fichiers de périphériques (/dev/sdxn).
> 
> C'est une mauvaise idée. Les noms de périphériques /dev/sd* ne sont pas 
> stables.

Oui c'est pour ça que je n'ai pas trop envie de remettre les sdx ...

> 
> > Quelle ne fut pas ma surprise de découvrir que ce décompte de 90s avait 
> > disparu ! :)
> > 
> > Si quelqu'un peut me (nous) expliquer la raison du compteur et sa 
> > disparition qu'il me (nous) l'apprenne.
> 
> Un des UUID dans /etc/fstab était erroné. Assez souvent, c'est celui du 
> swap qui a été modifié par une autre installation.
> 
> 

Je viens de vérifier mon fstab et ce ne sont pas les UUID qui sont utilisées
mais les PARTUUID. Mais j'ai vérifié et par rapport à ce qu'indique blkid tout
est bon.

Gaëtan


signature.asc
Description: This is a digitally signed message part

Re: Exit le timeout de 1min 30s

[Pierre L.]

Au passage,
petite commande pour choper les UUIDs actuellement présentes dans son
système, via le compte root :

blkid

Il semblerait qu'il faut retirer les guillemets entre chaque UUIDs
affichées par cette commande, et la syntaxe à inscrire dans /etc/fstab
(jamais testé avec ceci dit...).

Bon w-end



signature.asc
Description: OpenPGP digital signature

Re: Exit le timeout de 1min 30s

[Michel]

Le 10/11/2018 à 08:40, Michel a écrit :
> Le 09/11/2018 à 23:00, Pierre ESTREM a écrit :
>> Bonjour,
>>
>> Avec AccessDV Linux base Debian Jessie je constatais un compte à rebours 
>> de 1'30'' avant d'arriver au LightDM.
>> Comme pour moi certains devaient trouver cela pénible.
>>
>> Après une bévue, j'ai remplacé les UUID qui figuraient dans /etc/fstab 
>> par leurs fichiers de périphériques (/dev/sdxn).
>> Quelle ne fut pas ma surprise de découvrir que ce décompte de 90s avait 
>> disparu ! :)
>>
>> Si quelqu'un peut me (nous) expliquer la raison du compteur et sa 
>> disparition qu'il me (nous) l'apprenne.
>>
>> Merci
>> pierre estrem
>>
> 
> Bonjour,
> 
> Peut-être l'UUID de la swap qui a changé. Le mettre à jour dans
> /etc/initramfs-tools/conf.d/resume.
> 
> Il doit contenir:
> 
> RESUME=UUID=---
> 
> Remplacer les 0 par UUID de la partition de swap.
> 
> Michel
> 

J'oubliais, il faudra mettre à jour initramfs par:

update-initramfs -u

Re: Exit le timeout de 1min 30s

[Pascal Hambourg]

Le 09/11/2018 à 22:54, Pierre ESTREM a écrit :


Avec AccessDV Linux base Debian Jessie je constatais un compte à rebours 
de 1'30'' avant d'arriver au LightDM.

Comme pour moi certains devaient trouver cela pénible.

Après une bévue, j'ai remplacé les UUID qui figuraient dans /etc/fstab 
par leurs fichiers de périphériques (/dev/sdxn).


C'est une mauvaise idée. Les noms de périphériques /dev/sd* ne sont pas 
stables.


Quelle ne fut pas ma surprise de découvrir que ce décompte de 90s avait 
disparu ! :)


Si quelqu'un peut me (nous) expliquer la raison du compteur et sa 
disparition qu'il me (nous) l'apprenne.


Un des UUID dans /etc/fstab était erroné. Assez souvent, c'est celui du 
swap qui a été modifié par une autre installation.


(PS : Je n'ai pas reçu le message via linux-31)

Re: Exit le timeout de 1min 30s

[Michel]

Le 09/11/2018 à 23:00, Pierre ESTREM a écrit :
> Bonjour,
> 
> Avec AccessDV Linux base Debian Jessie je constatais un compte à rebours 
> de 1'30'' avant d'arriver au LightDM.
> Comme pour moi certains devaient trouver cela pénible.
> 
> Après une bévue, j'ai remplacé les UUID qui figuraient dans /etc/fstab 
> par leurs fichiers de périphériques (/dev/sdxn).
> Quelle ne fut pas ma surprise de découvrir que ce décompte de 90s avait 
> disparu ! :)
> 
> Si quelqu'un peut me (nous) expliquer la raison du compteur et sa 
> disparition qu'il me (nous) l'apprenne.
> 
> Merci
> pierre estrem
> 

Bonjour,

Peut-être l'UUID de la swap qui a changé. Le mettre à jour dans
/etc/initramfs-tools/conf.d/resume.

Il doit contenir:

RESUME=UUID=---

Remplacer les 0 par UUID de la partition de swap.

Michel

Re: Exit le timeout de 1min 30s

[Haricophile]

Le Fri, 9 Nov 2018 22:54:28 +0100,
Pierre ESTREM  a écrit :

> Si quelqu'un peut me (nous) expliquer la raison du compteur et sa 
> disparition qu'il me (nous) l'apprenne.

dans ce cas précis je ne sais pas, mais le compteur d'1mn30 ça ressemble
fortement a systemd qui attend quelque chose qui ne vient pas avant de passer
en "fallback". Est-ce un problème d'ordre de lancement ou autre chose qui met
le truc en échec, je ne sais pas. Il faudrait regarder les journaux de
démarrage. 

Re: Exit le timeout de 1min 30s

[Gaëtan Perrier]

Le vendredi 09 novembre 2018 à 22:54 +0100, Pierre ESTREM a écrit :
> Bonjour,
> 
> Avec AccessDV Linux base Debian Jessie je constatais un compte à rebours 
> de 1'30'' avant d'arriver au LightDM.
> Comme pour moi certains devaient trouver cela pénible.
> 
> Après une bévue, j'ai remplacé les UUID qui figuraient dans /etc/fstab 
> par leurs fichiers de périphériques (/dev/sdxn).
> Quelle ne fut pas ma surprise de découvrir que ce décompte de 90s avait 
> disparu ! :)
> 
> Si quelqu'un peut me (nous) expliquer la raison du compteur et sa 
> disparition qu'il me (nous) l'apprenne.
> 
> Merci
> pierre estrem

Intéressant ce que tu dis parce que effectivement je trouve ça super pénible.
Mais avant ça ne le faisait pas.
Donc si quelqu'un peut effectivement nous expliquer le pourquoi du comment ça
m'intéresse aussi.

Gaëtan



signature.asc
Description: This is a digitally signed message part

Exit le timeout de 1min 30s

[Pierre ESTREM]

Bonjour,

Avec AccessDV Linux base Debian Jessie je constatais un compte à rebours 
de 1'30'' avant d'arriver au LightDM.

Comme pour moi certains devaient trouver cela pénible.

Après une bévue, j'ai remplacé les UUID qui figuraient dans /etc/fstab 
par leurs fichiers de périphériques (/dev/sdxn).
Quelle ne fut pas ma surprise de découvrir que ce décompte de 90s avait 
disparu ! :)


Si quelqu'un peut me (nous) expliquer la raison du compteur et sa 
disparition qu'il me (nous) l'apprenne.


Merci
pierre estrem

Re: Login impossible/ startx ne demarre pas/Xauth timeout

[Denis Fertin]

Bonjour,

Je ne suis pas sur de savoir quelle action a resolu le probleme.
J 'ai cree le fichier .Xauthority dans mon repertoire home en tant que
root. Puis j'ai changé le propritaire et le group, je me suis rendu compte
que mon répertoire home appartenait a nobody/nogroup, j'ai changé cela
aussi.
Startx ne fonctionnait toujours pas mais avec un message different: user
not authorized to start X... ( ou qqchose du genre) du coup j'ai reessaye
le login et cela a marché.

Cordialement
Le 14 févr. 2016 12:04, "Jean-Michel OLTRA" 
a écrit :

>
> Bonjour,
>
>
> Le samedi 13 février 2016, dfertin a écrit...
>
>
> > Résolu
>
> Mais encore…?
>
>
> --
> jm
>
>

Re: Login impossible/ startx ne demarre pas/Xauth timeout

[Jean-Michel OLTRA]

Bonjour,


Le samedi 13 février 2016, dfertin a écrit...


> Résolu

Mais encore…?


-- 
jm

Login impossible/ startx ne demarre pas/Xauth timeout

[Denis Fertin]

Bonjour,

Je viens d'installer debian sur un pc lap top neuf.
Tout fonctionnaitnickel mais j'ai laisser le Pcen veille la nuit.
Depuis je ne peux plus me logger normalement.
En mode recovery, root peut executer startx.
Lorsque l'utilisateur dfertin essaye de lancer startx, j'obtiens le message
suivant:
Xauth : time out inlocking authority file /home/dfertin/.Xauthority
X: user not authorized to run Xserver, aborting ...

Le fichier /home/dfertin/.Xauthority n
'existe pas et je ne peux pas le creer en utilisant touch.
Ma conclusion: xauthotity n'arrive pas a creer ce fichier parce qu'il a ete
mal fermé lors de l'extinction du système.
Que faire?
Merci d'avance.

Re: Login impossible/ startx ne demarre pas/Xauth timeout

[dfertin]

Résolu

Re: Lenteur mailq et bizarrerie sudo + timeout

[Soliman Hindy]

On Wed, Aug 19, 2015 at 01:06:59PM +0200, Grégory Bulot wrote:
 Bonjour,

Bonjour,

 - avez-vous exécuter la commande strace sur le process mailq ?
 
 Non je ne l'avais pas fait. Par contre j'avais hier un tty qui
 consommais 20% de cpu, après un kill de ce tty (ouais, je suis un peu
 bourrin), plus de latence mailq

Merci pour l'information, j'aurais pas pensé que c'était un tty qui aurait
posé problème.

 
 D'autre part même si ce n'est pas en rapport direct, il existe un
 plugin nagios qui permet de monitorer une file d'attente
 (check_mailq) :
 http://www.linuxjournal.com/content/monitoring-email-nagios
 
 
 Je regarderais pour l'utiliser sous xymon :-)

Bon hack ;)

-- 
Soliman Hindy


signature.asc
Description: Digital signature

Re: Lenteur mailq et bizarrerie sudo + timeout

[Grégory Bulot]

Bonjour,


Le Tue, 18 Aug 2015 22:11:10 +0200,
Soliman Hindy hi...@lovetux.net a écrit :



Quelques pistes :
- avez-vous de l'iowait sur votre serveur ?


Je viens de m'apercevoir que je ne monitor pas encore cela, je vais
l'ajouter. néamoins iostat ne semble pas afficher des problèmes dans ce
sens :

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   0,440,050,180,450,00   98,88

Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
sda   5,1336,7253,7517392542545874
sdb   5,1335,2253,7516680202545874
md1   1,18 3,94 4,50 186667 213008
md2   8,4967,9146,5332161782203922
dm-0  0,00 0,01 0,00377 18
dm-1  8,3467,8946,5332154412203904




- avez-vous exécuter la commande strace sur le process mailq ?


Non je ne l'avais pas fait. Par contre j'avais hier un tty qui
consommais 20% de cpu, après un kill de ce tty (ouais, je suis un peu
bourrin), plus de latence mailq



D'autre part même si ce n'est pas en rapport direct, il existe un
plugin nagios qui permet de monitorer une file d'attente
(check_mailq) :
http://www.linuxjournal.com/content/monitoring-email-nagios



Je regarderais pour l'utiliser sous xymon :-)

Re: Lenteur mailq et bizarrerie sudo + timeout

[Soliman Hindy]

On Mon, Aug 17, 2015 at 07:21:44PM +0200, Grégory Bulot wrote:
 Bonjour,

Bonjour,

 Je tente de superviser les mails systèmes que génèrent mes serveurs,
 pour cela j'ai un script qui tourne (en simple user) toutes les 5
 minutes et qui fait en résumé :

[snip, je supprime tous les outputs donnés]

 1/ Pourquoi timeout ne semble pas efficace ?
 2/ Pourquoi mailq dure aussi longtemps ?

Quelques pistes :
- avez-vous de l'iowait sur votre serveur ?
- avez-vous exécuter la commande strace sur le process mailq ?

D'autre part même si ce n'est pas en rapport direct, il existe un plugin
nagios qui permet de monitorer une file d'attente (check_mailq) :
http://www.linuxjournal.com/content/monitoring-email-nagios

-- 
Soliman Hindy


signature.asc
Description: Digital signature

Lenteur mailq et bizarrerie sudo + timeout

[Grégory Bulot]

Bonjour, 

Je tente de superviser les mails systèmes que génèrent mes serveurs,
pour cela j'ai un script qui tourne (en simple user) toutes les 5
minutes et qui fait en résumé : 

  timeout 5s sudo mailq

De temps en temps, j'ai un truc bizarre :
 - timeout ne semble pas faire son travail
 - mailq dure longtemps 

exemple 
time timeout 5s sudo mailq ; echo $?

real0m12.246s
user0m0.000s
sys 0m0.000s
124

~ 10secondes après 
==
time timeout 5s sudo mailq ; echo $?

real0m6.404s
user0m0.004s
sys 0m0.004s
124

plus tard (temps de générer ce mail)

time timeout 5s sudo mailq ; echo $?

real0m0.013s
user0m0.000s
sys 0m0.004s
0



un peu avant pour rigoler :
=
time mailq ; echo $?
exim: permission denied

real0m12.059s
user0m0.000s
sys 0m0.004s
1


La machine 
 - passe son temps à ne rien faire (kimsuffi, 4cpu Intel(R)
Xeon(R) CPU E3-1225 V2 @ 3.20GHz)
 - un top ou quasiment rien ne dépasse 1%CPU 
 - ram 16G, avec un top tranquille (tri ascendant conso ram):

top - 19:16:37 up 403 days,  4:45,  8 users,  load average: 0,02, 0,07,
0,27 Tasks: 326 total,   1 running, 325 sleeping,   0 stopped,   0
zombie %Cpu(s):  0,1 us,  0,1 sy,  0,0 ni, 99,4 id,  0,4 wa,  0,0 hi,
0,0 si,  0,0 st KiB Mem:  16380392 total, 15832216 used,   548176
free,  1006832 buffers KiB Swap:  1050616 total,0 used,
1050616 free, 12696044 cached

  PID USER  PR  NI  VIRT  RES  SHR S  %CPU %MEMTIME+
  COMMAND 
9384 sshd  20   0  506m 215m 8696 S   0,3  1,3  24:59.68
  mysqld 
5411 root  20   0 96740  35m 3168 S   0,0  0,2   0:01.00
  python2.7 
5412 root  20   0 96748  35m 3168 S   0,0  0,2
  0:00.86 python2.7 
5410 root  20   0 96728  35m 3168 S   0,0
  0,2   0:00.68 python2.7 


1/ Pourquoi timeout ne semble pas efficace ?
2/ Pourquoi mailq dure aussi longtemps ?

Merci de m'avoir lu :-)

Message udevd[374]: timeout: killing '/sbin/modprobe -b dans syslog

[Olivier]

Bonjour,

Depuis que j'ai passé une machine de Squeeze à Wheezy, j'ai toutes les
secondes dans /var/log/syslog, ce message :

 udevd[374]: timeout: killing '/sbin/modprobe -b
x86cpu:vendor:0002:family:0014:model:0002:feature:,,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0017,0018,0019,001A,001C,0020,0021,0022,0023,0024,0025,0026,0027,0028,0029,002B,002C,002D,002E,002F,0030,0031,0034,0036,0037,0038,0039,003A,003B,003D,0064,0068,006A,0071,0078,007A,007C,0080,0083,0089,008D,0097,00C0,00C1,00C2,00C3,00C4,00C5,00C6,00C7,00C8,00CA,00CC,00CD,00E1,00E8,0105,0106,0107,0108,010D#012'
[447]

Que signifie-t-il ?
Qu'est ce x86cpu:vendor:0002:family:0014:model:0002:feature ?

Une idée ?

Slts

Re: wheezy apache2 user timeout sur lamp stack

[ralf kaiser]

Bonjour Greg,

Merci. 
Le chemin est celui supposé, 
le tail indique deux anomalies répétées:

[Mon Jul 23 22:43:09 2012] [notice] caught SIGTERM, shutting down
[Mon Jul 23 22:44:44 2012] [notice] Apache/2.2.22 (Debian) PHP/5.4.4-2
configured -- resuming normal operations

[Mon Jul 23 23:12:27 2012] [error] [client 127.0.0.1] PHP Notice:  Array
to string conversion in /var/www/crm/modules/Users/User.php on line 677,
referer: [...]

La ligne php en dit: $GLOBALS['log']-debug(additional detail query
results: $row);


 Message initial 
De: Grégoire COUTANT gregoire.cout...@gmail.com
Reply-to: gregoire.cout...@gmail.com
À: debian-user-french@lists.debian.org
Sujet: Re: wheezy apache2 user timeout sur lamp stack
Date: Tue, 24 Jul 2012 00:31:29 +0200

Bonjour,

Le 23/07/2012 23:42, ralf kaiser a écrit :
 Merci,

 je suis sur la config par défaut et n'ai rien touché à apache, donc
 c'est bien /etc/php5/apache2/php.ini ? Les valeurs timeout sont les
 mêmes entre wheezy et squeeze, donc c'est pas ça?!

Pour savoir quel php.ini modifier, le plus simple reste un fichier avec :
? phpinfo();

Ca te donnera le chemin de l'ini utilisé.

Ensuite, apache a également un timeout, j'ai aussi du l'augmenter dans 
certains cas, mais ce n'est pas une bonne pratique.
Dans mon cas je tourne en fastcgi avec php-fpm, il te suffit alors 
d'ajouter dans ton vhost :
FastCgiExternalServer /var/www/monsite/cgi-bin/php5.external -socket 
/var/www/.socks/monsite.sock -idle-timeout 400

Enfin tout ça n'est à faire bien sur qu'une fois que tu aura lu les logs 
d'apache et de php qui te diront clairement qui est responsable de ce 
timeout ou plantage...
Tu trouveras les logs dans /var/log/...
Un simple : tail -f -n 100 apache2/error.log te donneras déjà des 
infos juste après un timeout

Greg



-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/1343113518.4949.9.camel@debian.localdomain

Re: wheezy apache2 user timeout sur lamp stack

[Grégoire COUTANT]

Bonjour,

Le 24/07/2012 09:05, ralf kaiser a écrit :

Bonjour Greg,
Merci.
Le chemin est celui supposé,
le tail indique deux anomalies répétées:

[Mon Jul 23 22:43:09 2012] [notice] caught SIGTERM, shutting down
[Mon Jul 23 22:44:44 2012] [notice] Apache/2.2.22 (Debian) PHP/5.4.4-2
configured -- resuming normal operations


Le niveau de log est important à regarder, ci dessus ce sont des 
notice, c'est normal et pas une erreur.



[Mon Jul 23 23:12:27 2012] [error] [client 127.0.0.1] PHP Notice:  Array
to string conversion in /var/www/crm/modules/Users/User.php on line 677,
referer: [...]


Là on a une erreur, mais c'est PHP qui le met au niveau notice, rien de 
grave, cela n’empêche normalement pas du tout un programme de fonctionner.


Tu devrait aller voir les logs PHP si ce n'est pas apache qui cause 
problème (as-tu bien regardé les logs apache de ton vhost ?) et tu peux 
aussi aller voir les logs de SugarCRM, de mémoire tu as un fichier log à 
la racine qui s'appelle sugarcrm.log


Greg

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/500e4c00.50...@gmail.com

Re: wheezy apache2 user timeout sur lamp stack

[ralf kaiser]

Hello,

C'est réglé, merci! 

J'avais mis côte-â-côte deux crm (deux répertoires sous /var/www/ et
deux sgbdr distincts) sans passer par les vhosts pensant que le
filesystem du bazar suffit. Ta remarque sur leur config m'a fait penser
qu'il fallait régler çà, j'ai donc créé deux domaines propres,
maintenant c'est bon. Il faut donc créer un environnement entier-propre
dès qu'on plus d'un système...?!

j'espère que ton php-fpm est bien réglé chez toi; je suis au premier
étage et tu es au 10ème, i cannot help...

RK

Le mardi 24 juillet 2012 à 09:17 +0200, Grégoire COUTANT a écrit :
 Bonjour,
 
 Le 24/07/2012 09:05, ralf kaiser a écrit :
  Bonjour Greg,
  Merci.
  Le chemin est celui supposé,
  le tail indique deux anomalies répétées:
 
  [Mon Jul 23 22:43:09 2012] [notice] caught SIGTERM, shutting down
  [Mon Jul 23 22:44:44 2012] [notice] Apache/2.2.22 (Debian) PHP/5.4.4-2
  configured -- resuming normal operations
 
 Le niveau de log est important à regarder, ci dessus ce sont des 
 notice, c'est normal et pas une erreur.
 
  [Mon Jul 23 23:12:27 2012] [error] [client 127.0.0.1] PHP Notice:  Array
  to string conversion in /var/www/crm/modules/Users/User.php on line 677,
  referer: [...]
 
 Là on a une erreur, mais c'est PHP qui le met au niveau notice, rien de 
 grave, cela n’empêche normalement pas du tout un programme de fonctionner.
 
 Tu devrait aller voir les logs PHP si ce n'est pas apache qui cause 
 problème (as-tu bien regardé les logs apache de ton vhost ?) et tu peux 
 aussi aller voir les logs de SugarCRM, de mémoire tu as un fichier log à 
 la racine qui s'appelle sugarcrm.log
 
 Greg
 


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/1343134542.4482.13.camel@debian.localdomain

Re: wheezy apache2 user timeout sur lamp stack

[Bzzz]

On Mon, 23 Jul 2012 22:41:54 +0200
ralf kaiser rsvcakai...@gmail.com wrote:

 J'utilise depuis peu debian wheezy. Je suis perdu car les fichiers
 de configuration se démultiplient / changent de localisation

Pas vraiment.

 crm local (sugar sur lamp): une fois loggé, j'ai env. 30 sec. pour
 rentrer les données, puis il m'éjecte. Ca ne vient pas du crm car
 j'utilise la même version depuis ququ années et ça marche sous
 squeeze et ailleurs...

Ça n'a pas à voir avec le svr http mais avec php, et ça se
règle dans le fichier de conf voulu en fonction de l'interpréteur
php utilisé (mod_machin d'apache ou fpm ou autre).

-- 
* Julie passe de en couple à c'est compliqué
Marc : Ah merde Théo t'as dis qu'il avait couché avec ta soeur :/ ?
* Julie passe de c'est compliqué à célibataire
Marc : Merde...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120723225304.184bbc67@anubis.defcon1

Re: wheezy apache2 user timeout sur lamp stack

[ralf kaiser]

Merci,

je suis sur la config par défaut et n'ai rien touché à apache, donc
c'est bien /etc/php5/apache2/php.ini ? Les valeurs timeout sont les
mêmes entre wheezy et squeeze, donc c'est pas ça?!

-- 
ralf kaiser rsvcakaiser at gmail.com

 Message initial 
De: Bzzz lazyvi...@gmx.com
À: debian-user-french@lists.debian.org
Sujet: Re: wheezy apache2 user timeout sur lamp stack
Date: Mon, 23 Jul 2012 22:53:04 +0200

On Mon, 23 Jul 2012 22:41:54 +0200
ralf kaiser rsvcakai...@gmail.com wrote:

 J'utilise depuis peu debian wheezy. Je suis perdu car les fichiers
 de configuration se démultiplient / changent de localisation

Pas vraiment.

 crm local (sugar sur lamp): une fois loggé, j'ai env. 30 sec. pour
 rentrer les données, puis il m'éjecte. Ca ne vient pas du crm car
 j'utilise la même version depuis ququ années et ça marche sous
 squeeze et ailleurs...

Ça n'a pas à voir avec le svr http mais avec php, et ça se
règle dans le fichier de conf voulu en fonction de l'interpréteur
php utilisé (mod_machin d'apache ou fpm ou autre).

-- 
* Julie passe de en couple à c'est compliqué
Marc : Ah merde Théo t'as dis qu'il avait couché avec ta soeur :/ ?
* Julie passe de c'est compliqué à célibataire
Marc : Merde...


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/1343079740.4570.7.camel@debian.localdomain

Re: wheezy apache2 user timeout sur lamp stack

[Grégoire COUTANT]

Bonjour,

Le 23/07/2012 23:42, ralf kaiser a écrit :

Merci,

je suis sur la config par défaut et n'ai rien touché à apache, donc
c'est bien /etc/php5/apache2/php.ini ? Les valeurs timeout sont les
mêmes entre wheezy et squeeze, donc c'est pas ça?!


Pour savoir quel php.ini modifier, le plus simple reste un fichier avec :
? phpinfo();

Ca te donnera le chemin de l'ini utilisé.

Ensuite, apache a également un timeout, j'ai aussi du l'augmenter dans 
certains cas, mais ce n'est pas une bonne pratique.
Dans mon cas je tourne en fastcgi avec php-fpm, il te suffit alors 
d'ajouter dans ton vhost :
FastCgiExternalServer /var/www/monsite/cgi-bin/php5.external -socket 
/var/www/.socks/monsite.sock -idle-timeout 400


Enfin tout ça n'est à faire bien sur qu'une fois que tu aura lu les logs 
d'apache et de php qui te diront clairement qui est responsable de ce 
timeout ou plantage...

Tu trouveras les logs dans /var/log/...
Un simple : tail -f -n 100 apache2/error.log te donneras déjà des 
infos juste après un timeout


Greg


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/500dd0c1.60...@gmail.com

Re: timeout de shutdown?

[thomas]

2010/2/18 Jean-Yves F. Barbier 12u...@gmail.com:
 Louis Roché a écrit :

 Si j'ai de bons souvenirs, ton 10 veut dire que le message d'extinction
 va apparaitre pendant 10 secondes. Mais comme tu indiques now, les
 programmes sont coupés au moment de la commande.
 Il est hautement possible que je me trompe.

 non non tu ne te trompes pas :)

Merci, c'est très clair!
Thomas

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2753bafa1002180054u26acafa0o8681d42d1398d...@mail.gmail.com

timeout de shutdown?

[thomas]

Hello,

Il y a sûrement quelque chose qui m'échappe: quand je fais
/sbin/shutdown -t10 -r now, shutdown termine tous les processus
immédiatement au lieu d'attendre dix secondes. Y a-t-il une subtilité
que je n'aurais pas vue à l'option -t?

Merci de vos lumières...

Thomas

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2753bafa1002171426i51fb147eo4a9570b60290a...@mail.gmail.com

Re: timeout de shutdown?

[E. Prom]

On Wednesday, 17 February 2010, 23:26:48 +0100,
thomas thomas@gmail.com wrote:
 Hello,
 
 Il y a sûrement quelque chose qui m'échappe: quand je fais
 /sbin/shutdown -t10 -r now, shutdown termine tous les processus
 immédiatement au lieu d'attendre dix secondes. Y a-t-il une subtilité
 que je n'aurais pas vue à l'option -t?

Je pense que -t doit être pour le temps entre les SIGTERM et les
SIGKILL. Tes programmes doivent se fermer gentiment à la première
sommation.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100217235102.gc5...@pc

Re: timeout de shutdown?

[Louis Roché]

Le jeudi 18 févr. 2010 à 00:51:02 (+0100), E. Prom a écrit :
 On Wednesday, 17 February 2010, 23:26:48 +0100,
 thomas thomas@gmail.com wrote:
  Hello,
  
  Il y a sûrement quelque chose qui m'échappe: quand je fais
  /sbin/shutdown -t10 -r now, shutdown termine tous les processus
  immédiatement au lieu d'attendre dix secondes. Y a-t-il une subtilité
  que je n'aurais pas vue à l'option -t?
 
 Je pense que -t doit être pour le temps entre les SIGTERM et les
 SIGKILL. Tes programmes doivent se fermer gentiment à la première
 sommation.
 
 -- 
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists
 
 Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
 vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 Archive: http://lists.debian.org/20100217235102.gc5...@pc
 

Bonjour

Si j'ai de bons souvenirs, ton 10 veut dire que le message d'extinction
va apparaitre pendant 10 secondes. Mais comme tu indiques now, les
programmes sont coupés au moment de la commande.
Il est hautement possible que je me trompe.

Louis

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp14ff804413708296ccc0d5c9...@phx.gbl

Re: timeout de shutdown?

[Jean-Yves F. Barbier]

Louis Roché a écrit :

 Si j'ai de bons souvenirs, ton 10 veut dire que le message d'extinction
 va apparaitre pendant 10 secondes. Mais comme tu indiques now, les
 programmes sont coupés au moment de la commande.
 Il est hautement possible que je me trompe.

non non tu ne te trompes pas :)

-- 
Diet Mountain Dew has the same pH and density of urine.
-- Newsweek, 31 July, 1989

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4b7c962a.8070...@gmail.com

Re: fetchmail (procmail mutt) : timeout socket error

[serge]

Le Wednesday 29 July 2009 18:46:21 Michaël Pierson, vous avez écrit :
[...]
  
   Voici un extrait de '~.fetchmail.log' avec dépassement de délai et
   erreur socket et 10' plus tard la réception du mail pour ce compte.
   ...
   fetchmail: démarrage de fetchmail 6.3.9-rc2 en tâche de fond
   fetchmail: mise en sommeil à mer 29 jui 2009 12:17:16 CEST pour 300
   secondes fetchmail: réveillé à mer 29 jui 2009 12:22:16 CEST
   fetchmail: 1 message pour x...@gmail.com dans pop.gmail.com (464589
   octets). fetchmail: lecture du message
   x...@gmail.com@gmail-pop.l.google.com:1 parmi 1 (464589 octets) éliminé
   fetchmail: mise en sommeil à mer 29 jui 2009 12:22:18 CEST pour 300
   secondes fetchmail: réveillé à mer 29 jui 2009 12:27:18 CEST
   fetchmail: délai dépassé après 300 secondes d'attente du serveur
   mail.voo.be. fetchmail: erreur socket durant la réception de
   y...@voo.be@mail.voo.be fetchmail: État de la requête=2 (SOCKET)
   fetchmail: mise en sommeil à mer 29 jui 2009 12:32:20 CEST pour 300
   secondes fetchmail: réveillé à mer 29 jui 2009 12:37:20 CEST
   fetchmail: 1 message pour y...@voo.be dans mail.voo.be (470460 octets).
   fetchmail: lecture du message y...@voo.be@mrouterout.brutele.be:1 parmi
   1 (470460 octets) éliminé fetchmail: mise en sommeil à mer 29 jui 2009
   12:37:22 CEST pour 300 secondes ...
 
  Tu pourrais montrer la configuration du compte avec  'mail.voo.be' ?
  C'est un compte imap , pop3 , ... ?

 Voici l'intégrale de '~/.fetchmailrc':

 # compte FAI:
 poll mail.voo.be
 protocol pop3
 username y...@voo.be
 password aa

 # 1er compte gmail:
 poll pop.gmail.com
 protocol pop3
 port 995
 username x...@gmail.com
 password b
 ssl

 # 2eme compte gmail:
 poll pop.gmail.com
 protocol pop3
 port 995
 username z...@gmail.com
 password c
 ssl

  Et par la suite, tu utilises 'sendmail', 'procmail' ou un serveur SMTP ?

 Pour les mails entrants, j'utilise procmail afin de trier, SpamAssassin
 pour filtrer et enfin Mutt comme lecteur.

Pour fixer l'utilisation de procmail avec fetchmail, il est possible d'ajouter 
cette ligne au début et avant les comptes:

defaults mda '/usr/bin/procmail -Y -d %T'

sans cette ligne, les messages seront réexpédiés via SMTP vers le serveur 
localhost (par défaut). Tu as un serveur SMTP actif sur le port 25 qui 
accepte les messages sans authentification ?

D'ailleurs, un excellent moyen pour 'visualiser' comment les paramètres de ton 
fichier de configuration est interprété est d'utiliser l'option '-V' de 
fetchmail :

% fetchmail -V -f ~/.fetchmailrc


 Pour les envois, j'utilise Mutt et msmtp pour me connecter à un serveur
 smtp gmail 'host smtp.gmail.com'.

 Postfix pour les mails en local.

C'est excessif ! Tu as déjà msmtp qui rempli cette tâche !!


  Pour l'erreur socket, le man de fetchmail dit:
 
  An error was encountered when attempting to open a socket to retrieve
  mail. If you don't know what a socket is, don't worry about it -- just
  treat this as an 'unrecoverable error'. This error can also be because a
  protocol fetchmail wants to use is not listed in /etc/services.

 POP3 est bien un protocole définit dans /etc/services. Nous voilà alors
 avec une erreur irrécupérable.  :(

Non. L'erreur pourrait venir par le fait que tu n'utilises pas le 
paramètre 'mda' en réexpédiant les messages de fetchmail par SMTP au lieu 
d'utiliser directement procmail.

Dans ce cas de figure, il est possible d'utiliser une variable d'environnement 
an lançant fetchmail de cette manière:

% env SOCKS_CONF=/dev/null /usr/bin/fetchmail \
 --daemon 300 \
 --logfile ~/.fetchmail.log \
 --pidfile ~/.fetchmail.pid

Il faudrait aussi regarder les logs de Postfix quand fetchmail réinjecte les 
messages sur le serveur SMTP localhost:25

  Tu renvois les messages sur un compte SMTP ?

 Non.

Si il n'y a pas de paramètre mda fixer sur par exemple procmail, les messages 
sont réexpédies sur ton compte local de ton serveur SMTP. Donc oui.

 @+
-- 
(o_
(/)_
S e r g e

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: fetchmail (procmail mutt) : timeout socket error

[Michaël Pierson]

Le jeudi 30 juillet 2009 à 08:11:22, se...@srv0.ath.cx a écrit :
 Le Wednesday 29 July 2009 18:46:21 Michaël Pierson, vous avez écrit :
 [...]
   
Voici un extrait de '~.fetchmail.log' avec dépassement de délai et
erreur socket et 10' plus tard la réception du mail pour ce compte.
...
fetchmail: démarrage de fetchmail 6.3.9-rc2 en tâche de fond
fetchmail: mise en sommeil à mer 29 jui 2009 12:17:16 CEST pour 300
secondes fetchmail: réveillé à mer 29 jui 2009 12:22:16 CEST
fetchmail: 1 message pour x...@gmail.com dans pop.gmail.com (464589
octets). fetchmail: lecture du message
x...@gmail.com@gmail-pop.l.google.com:1 parmi 1 (464589 octets) éliminé
fetchmail: mise en sommeil à mer 29 jui 2009 12:22:18 CEST pour 300
secondes fetchmail: réveillé à mer 29 jui 2009 12:27:18 CEST
fetchmail: délai dépassé après 300 secondes d'attente du serveur
mail.voo.be. fetchmail: erreur socket durant la réception de
y...@voo.be@mail.voo.be fetchmail: État de la requête=2 (SOCKET)
fetchmail: mise en sommeil à mer 29 jui 2009 12:32:20 CEST pour 300
secondes fetchmail: réveillé à mer 29 jui 2009 12:37:20 CEST
fetchmail: 1 message pour y...@voo.be dans mail.voo.be (470460 octets).
fetchmail: lecture du message y...@voo.be@mrouterout.brutele.be:1 parmi
1 (470460 octets) éliminé fetchmail: mise en sommeil à mer 29 jui 2009
12:37:22 CEST pour 300 secondes ...
  
   Tu pourrais montrer la configuration du compte avec  'mail.voo.be' ?
   C'est un compte imap , pop3 , ... ?
 
  Voici l'intégrale de '~/.fetchmailrc':
 
  # compte FAI:
  poll mail.voo.be
  protocol pop3
  username y...@voo.be
  password aa
 
  # 1er compte gmail:
  poll pop.gmail.com
  protocol pop3
  port 995
  username x...@gmail.com
  password b
  ssl
 
  # 2eme compte gmail:
  poll pop.gmail.com
  protocol pop3
  port 995
  username z...@gmail.com
  password c
  ssl
 
   Et par la suite, tu utilises 'sendmail', 'procmail' ou un serveur SMTP ?
 
  Pour les mails entrants, j'utilise procmail afin de trier, SpamAssassin
  pour filtrer et enfin Mutt comme lecteur.
 
 Pour fixer l'utilisation de procmail avec fetchmail, il est possible 
 d'ajouter 
 cette ligne au début et avant les comptes:
 
 defaults mda '/usr/bin/procmail -Y -d %T'
 
 sans cette ligne, les messages seront réexpédiés via SMTP vers le serveur 
 localhost (par défaut).

oui:  % fetchmail -V -f ~/.fetchmailrc
 Les messages seront réexpédiés via SMTP vers : localhost (par défaut)

après modification:
 Les messages seront acheminés avec /usr/bin/procmail -Y -d %T.

 Tu as un serveur SMTP actif sur le port 25 qui accepte les messages sans 
 authentification ?

Comment le savoir?

 
 D'ailleurs, un excellent moyen pour 'visualiser' comment les paramètres de 
 ton 
 fichier de configuration est interprété est d'utiliser l'option '-V' de 
 fetchmail :
 
 % fetchmail -V -f ~/.fetchmailrc
 
 
  Pour les envois, j'utilise Mutt et msmtp pour me connecter à un serveur
  smtp gmail 'host smtp.gmail.com'.
 
  Postfix pour les mails en local.
 
 C'est excessif ! Tu as déjà msmtp qui rempli cette tâche !!

Oui et je souhaites aborder plusieurs points:

1-Tout d'abord un éclairage:
Le MTA Postfix gère le mail en local et l'envoi des mails.
Msmtp transmet le mail à un server smtp (ici gmail) qui lui s'occupe de
la livraison. Msmtp dit au MUA Mutt de l'appeler à la place du MTA Postfix.
Je comprend donc bien que Msmtp fait le job à la place de postfix en ce
qui concerne l'envoi des mails. Quid du mail en local? Qui s'en occupe
dans ce cas?

2-Revenons une étape en arrière: Msmtp n'est pas installé et je
cherche à contacter le server smtp gmail à partir de Mutt.
Dans '~/.muttrc' j'utilise la ligne 
set smtp_url='smtps://x...@gmail.com:z...@smtp.gmail.com:465'
qui provoque le message : authentificateurs non disponibles
Je ne résoudrait pas ce point mais je le contourne en installant msmtp.
J'aimerai revenir sur cette erreur pour comprendre.

3-Revenons encore une étape plus en arrière: J'utilise un seul
compte mail: celui de mon FAI. Postfix gère les mails via smtp.voo.be
J'adapte le champ From fonction du destinataire avec dans '~/muttrc':
send-hook '~C ^...@lists\.debian\.org$''my_hdr From: Michaël Pierson
x...@gmail.com'
Ces envois sont considérés comme du spam par mon Fai. Il semblerait que
celà soit le résultat d'une policy de Gmail indiquant que seul les
servers smtp.gmail peuvent délivrer des mails gmail (suis je compréhensible?).

4- Voilà pourquoi actuellement, je cherche à obtenir ( et Msmtp semble être 
idéal) quelque chose comme:
destinataire A j'utilise From x...@gmail.com et smpt gmail avec identifiant XXX
destinataire B j'utilise From y...@gmail.com et smpt gmail avec identifiant YYY
destinataire C j'utilise From z...@voo.be et smtp.voo.be

 
 
   Pour l'erreur socket, le man de fetchmail dit:
  
   An error was encountered when attempting to open a socket to retrieve
   mail. If you don't know what a socket is, don't 

Re: fetchmail (procmail mutt) : timeout socket error

[serge]

Le Thursday 30 July 2009 15:45:57 Michaël Pierson, vous avez écrit :
 Le jeudi 30 juillet 2009 à 08:11:22, se...@srv0.ath.cx a écrit :
[...]
  sans cette ligne, les messages seront réexpédiés via SMTP vers le serveur
  localhost (par défaut).

 oui:  % fetchmail -V -f ~/.fetchmailrc
  Les messages seront réexpédiés via SMTP vers : localhost (par défaut)

 après modification:
  Les messages seront acheminés avec /usr/bin/procmail -Y -d %T.

  Tu as un serveur SMTP actif sur le port 25 qui accepte les messages sans
  authentification ?

 Comment le savoir?
C'est normal que le MTA accepte une session SMTP sans authentification sur 
localhost ou 127.0.0.1. Par contre pour ne pas ouvrir une porte au spam, il 
doit être soit fermé pour l'extérieure, ou utiliser un mécanisme 
d'authentification.

Pour le tester, avec 'telnet' en local:

* légende:
- : réponse du serveur;
- : envoie d'une commande.

% telnet 127.0.0.1 25
Trying localhost ...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
 - 220 mail.X ESMTP Exim 4.69 Thu, 30 Jul 2009 16:48:19 +0200
 - MAIL FROM:m...@localhost.localdomain
 - 250 OK
 - RCPT TO: utilisat...@localhost.localdomain
 - 250 Accepted
 - DATA
 - 354 Enter message, ending with . on a line by itself
 - Mon message de teste terminé par un point
 - .
 - 250 OK id=1MWWwA-0002hZ-HY
 - QUIT
 - 221 mail.X closing connection
Connection closed by foreign host.

Un message de m...@localhost.localdomain a été envoyé à 
utilisat...@localhost.localdomain.


   Pour les envois, j'utilise Mutt et msmtp pour me connecter à un serveur
   smtp gmail 'host smtp.gmail.com'.
  
   Postfix pour les mails en local.
 
  C'est excessif ! Tu as déjà msmtp qui rempli cette tâche !!

 Oui et je souhaites aborder plusieurs points:

 1-Tout d'abord un éclairage:
 Le MTA Postfix gère le mail en local et l'envoi des mails.
 Msmtp transmet le mail à un server smtp (ici gmail) qui lui s'occupe de
 la livraison. Msmtp dit au MUA Mutt de l'appeler à la place du MTA
 Postfix. Je comprend donc bien que Msmtp fait le job à la place de postfix
 en ce qui concerne l'envoi des mails. Quid du mail en local? Qui s'en
 occupe dans ce cas?

Je ne comprends pas bien. Tu veux dire comment envoyer un message avec 'mail' 
(car avec Mutt c'est bon) ? Du style :

% echo 'Mon message texte' | mail -s Object utilisat...@domaine.com

Le programme 'mail'  utilise '/usr/lib/sendmail' pour l'envoie des messages. 
Tu peux ajouter un autre chemin pour utiliser 'Msmtp' :

* Pour tous:
% echo 'set sendmail=/usr/bin/msmtp'  /etc/nail.rc

* Par utilisateur:
% echo 'set sendmail=/usr/bin/msmtp'  ~/.mailrc

* Ou un lien :
/usr/lib/sendmail - /usr/bin/msmtp

De même avec Mutt pour qu'il utilise 'Msmtp'.

Donc plus besoin de Postfix

 2-Revenons une étape en arrière: Msmtp n'est pas installé et je
 cherche à contacter le server smtp gmail à partir de Mutt.
 Dans '~/.muttrc' j'utilise la ligne
 set smtp_url='smtps://x...@gmail.com:z...@smtp.gmail.com:465'
 qui provoque le message : authentificateurs non disponibles
 Je ne résoudrait pas ce point mais je le contourne en installant msmtp.
 J'aimerai revenir sur cette erreur pour comprendre.

Moi aussi J'aimerai comprendre. Tu disais qu'avec ton ancêtre (etch) mutt 
fonctionnait bien. Avec la même configuration ( Msmtp et Postfix ) ?


 3-Revenons encore une étape plus en arrière: J'utilise un seul
 compte mail: celui de mon FAI. Postfix gère les mails via smtp.voo.be
 J'adapte le champ From fonction du destinataire avec dans '~/muttrc':
 send-hook '~C ^...@lists\.debian\.org$''my_hdr From: Michaël Pierson
 x...@gmail.com'
 Ces envois sont considérés comme du spam par mon Fai. Il semblerait que
 celà soit le résultat d'une policy de Gmail indiquant que seul les
 servers smtp.gmail peuvent délivrer des mails gmail (suis je
 compréhensible?).

Si tu postais le message avec les entêtes du message considéré spam, on 
pourait l'analysé.
Aussi en utilisant le service 'echo' de 'cict.fr':

% echo teste | mail -s teste robotm...@cict.fr

C'est un robot de test de message, il renvoie les entêtes pour bien les 
analyser.


 4- Voilà pourquoi actuellement, je cherche à obtenir ( et Msmtp semble être
 idéal) quelque chose comme: destinataire A j'utilise From x...@gmail.com et
 smpt gmail avec identifiant XXX destinataire B j'utilise From y...@gmail.com
 et smpt gmail avec identifiant YYY destinataire C j'utilise From z...@voo.be
 et smtp.voo.be


* La doc de Mutt en français:
http://cedricduval.free.fr/mutt/fr/sitehtml/manual.html

Les Muttés de la liste te dirons mieux comment configurer Mutt avec des 
profiles.

* Exemple configuration avec profile en français:
http://www.bidon.ca/Mutt.html

  Il faudrait aussi regarder les logs de Postfix quand fetchmail réinjecte
  les messages sur le serveur SMTP localhost:25

 Dans /var/log/syslog?

Il me semble que c'est /var/log/maillog sur debian (?).
% grep -E  (reject|warning|error|fatal|panic): /var/log/maillog

ou 

% tail -F 

Re: fetchmail (procmail mutt) : timeout socket error

[serge]

Le Sunday 26 July 2009 12:43:52 Michaël Pierson, vous avez écrit :
 Le vendredi 24 juillet 2009 à 01:25:47, se...@srv0.ath.cx a écrit :
  Le Friday 24 July 2009 00:34:30 Michaël Pierson, vous avez écrit :
   Le mercredi 22 juillet 2009 à 10:24:45, Edi Stojicevic a écrit :
* Michaël Pierson michael.y.f.pier...@gmail.com [2009-07-22
19:03:35
 
  +0200] wrote :
 Je relève mes mails tous les quart d'heure (crontab):
 */15 * * * * fetchmail --silent
   
Pourquoi ne pas mettre dans ton ~/.fetchmailrc
set daemon 900
  
   oui pourquoi pas
  
 Ce 22 juillet (à quelques autres reprises) j'ai reçu de Cron Deamon
 le mail suivant:
 fetchmail: timeout after 300 seconds waiting for server
 mail.voo.be. fetchmail: socket error while fetching from
 *m...@*server* fetchmail: Query status=2 (SOCKET)

 Jj'ai rien dans /var/log/mail.info
   
et dans /var/log/mail.(err|log) ?
  
   non rien du tout
 
  * Avec ces lignes ( au debut de ~/.fetchmailrc ):
 
  set no syslog
  set logfile ~/.fetchmail.log

 Lignes ajoutées le 24 juillet en début de fichier comme recommandé.
 2 nouveaux messages mails de Cron Deamon le 25.
 Je n'ai pas de fichier ~/.fetchmail.log créé.

 @+
 Michaël


Salut;

Il y a deux manières d'utiliser fetchmail:
- mode utilisateur ( un fichier ~/.fetchmailrc par utilisateur );
- mode système ( un unique fichier /etc/fetchmailrc pour tous les
  utilisateurs et administré par un utilisateur spécifique ou root ).

Les paramètres utilisés pour chaque mode sont certaines fois différents, et le 
mode de lancement différents aussi, mais ils n'utilisent pas un service cron.

Celui qui t'intéresse est certainement le mode utilisateur, avec un fichier de 
configuration placé dans le 'home' de l'utilisateur: ~/.fetchmailrc

Pour lancer fetchmail automatiquement en mode 'daemon' lorsque l'utilisateur 
se connecte ( login ), on utilise soit '~/.bash_login' ou '~/.bash_profile' 
en y ajoutant:

if [ -f ~/.fetchmailrc -a -x /usr/bin/fetchmail ]; then
# Vérification des permissions
if [ $(stat -c '%U %a' ~/.fetchmailrc) != $USER 600 ]; then
chown -h $USER  ~/.fetchmailrc
chmod -f 0600  ~/.fetchmailrc
fi
# Si il y a une instance de fetchmail
if [ -f ~/.fetchmail.pid ]; then
PIDSTATUS=/proc/$(head -n 1 ~/.fetchmail.pid)/status
if [ -f $PIDSTATUS -a $(grep fetchmail $PIDSTATUS) ]; then
/usr/bin/fetchmail --quit
sleep 1
fi
fi
# Lancement de fetchmail en mode daemon
# avec interval entre ramassage de 300 s
# et journal des actions.
/usr/bin/fetchmail  \
--daemon 300 \
--logfile ~/.fetchmail.log \
--pidfile ~/.fetchmail.pid
fi

Par la suite pour terminer proprement fetchmail en sortant, on ajout 
à '~/.bash_logout':

if [ -f ~/.fetchmail.pid ]; then
PIDSTATUS=/proc/$(head -n 1 ~/.fetchmail.pid)/status
if [ -f $PIDSTATUS -a $(grep fetchmail $PIDSTATUS) ]; then
/usr/bin/fetchmail --quit
fi
fi

@+
-- 
(o_
(/)_
S e r g e

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: fetchmail (procmail mutt) : timeout socket error

[Michaël Pierson]

Le mercredi 29 juillet 2009 à 08:30:18, se...@srv0.ath.cx a écrit :
 Le Sunday 26 July 2009 12:43:52 Michaël Pierson, vous avez écrit :
  Le vendredi 24 juillet 2009 à 01:25:47, se...@srv0.ath.cx a écrit :
   Le Friday 24 July 2009 00:34:30 Michaël Pierson, vous avez écrit :
Le mercredi 22 juillet 2009 à 10:24:45, Edi Stojicevic a écrit :
 * Michaël Pierson michael.y.f.pier...@gmail.com [2009-07-22
 19:03:35
  
   +0200] wrote :
  Je relève mes mails tous les quart d'heure (crontab):
  */15 * * * * fetchmail --silent

 Pourquoi ne pas mettre dans ton ~/.fetchmailrc
 set daemon 900
   
oui pourquoi pas
   
  Ce 22 juillet (à quelques autres reprises) j'ai reçu de Cron Deamon
  le mail suivant:
  fetchmail: timeout after 300 seconds waiting for server
  mail.voo.be. fetchmail: socket error while fetching from
  *m...@*server* fetchmail: Query status=2 (SOCKET)
 
  Jj'ai rien dans /var/log/mail.info

 et dans /var/log/mail.(err|log) ?
   
non rien du tout
  
   * Avec ces lignes ( au debut de ~/.fetchmailrc ):
  
   set no syslog
   set logfile ~/.fetchmail.log
 
  Lignes ajoutées le 24 juillet en début de fichier comme recommandé.
  2 nouveaux messages mails de Cron Deamon le 25.
  Je n'ai pas de fichier ~/.fetchmail.log créé.
 
  @+
  Michaël
 
 
 Salut;
 
 Il y a deux manières d'utiliser fetchmail:
   - mode utilisateur ( un fichier ~/.fetchmailrc par utilisateur );
   - mode système ( un unique fichier /etc/fetchmailrc pour tous les
 utilisateurs et administré par un utilisateur spécifique ou root ).
 
 Les paramètres utilisés pour chaque mode sont certaines fois différents, et 
 le 
 mode de lancement différents aussi, mais ils n'utilisent pas un service cron.
 
 Celui qui t'intéresse est certainement le mode utilisateur, avec un fichier 
 de 
 configuration placé dans le 'home' de l'utilisateur: ~/.fetchmailrc
 
 Pour lancer fetchmail automatiquement en mode 'daemon' lorsque l'utilisateur 
 se connecte ( login ), on utilise soit '~/.bash_login' ou '~/.bash_profile' 
 en y ajoutant:
 
 if [ -f ~/.fetchmailrc -a -x /usr/bin/fetchmail ]; then
 # Vérification des permissions
 if [ $(stat -c '%U %a' ~/.fetchmailrc) != $USER 600 ]; then
 chown -h $USER  ~/.fetchmailrc
 chmod -f 0600  ~/.fetchmailrc
 fi
 # Si il y a une instance de fetchmail
 if [ -f ~/.fetchmail.pid ]; then
 PIDSTATUS=/proc/$(head -n 1 ~/.fetchmail.pid)/status
 if [ -f $PIDSTATUS -a $(grep fetchmail $PIDSTATUS) ]; then
 /usr/bin/fetchmail --quit
 sleep 1
 fi
 fi
 # Lancement de fetchmail en mode daemon
 # avec interval entre ramassage de 300 s
 # et journal des actions.
 /usr/bin/fetchmail  \
   --daemon 300 \
   --logfile ~/.fetchmail.log \
   --pidfile ~/.fetchmail.pid
 fi

Comme j'utilise zsh, j'ai ajouté ces lignes dans '~.zshrc'
 
 Par la suite pour terminer proprement fetchmail en sortant, on ajout 
 à '~/.bash_logout':
 
 if [ -f ~/.fetchmail.pid ]; then
 PIDSTATUS=/proc/$(head -n 1 ~/.fetchmail.pid)/status
 if [ -f $PIDSTATUS -a $(grep fetchmail $PIDSTATUS) ]; then
 /usr/bin/fetchmail --quit
 fi
 fi

Et pour sortir proprement j'ai créé un '~.zshrc_logout'


Voici un extrait de '~.fetchmail.log' avec dépassement de délai et
erreur socket et 10' plus tard la réception du mail pour ce compte. 
...
fetchmail: démarrage de fetchmail 6.3.9-rc2 en tâche de fond
fetchmail: mise en sommeil à mer 29 jui 2009 12:17:16 CEST pour 300 secondes
fetchmail: réveillé à mer 29 jui 2009 12:22:16 CEST
fetchmail: 1 message pour x...@gmail.com dans pop.gmail.com (464589 octets).
fetchmail: lecture du message x...@gmail.com@gmail-pop.l.google.com:1 parmi 1 
(464589 octets) éliminé
fetchmail: mise en sommeil à mer 29 jui 2009 12:22:18 CEST pour 300 secondes
fetchmail: réveillé à mer 29 jui 2009 12:27:18 CEST
fetchmail: délai dépassé après 300 secondes d'attente du serveur mail.voo.be.
fetchmail: erreur socket durant la réception de y...@voo.be@mail.voo.be
fetchmail: État de la requête=2 (SOCKET)
fetchmail: mise en sommeil à mer 29 jui 2009 12:32:20 CEST pour 300 secondes
fetchmail: réveillé à mer 29 jui 2009 12:37:20 CEST
fetchmail: 1 message pour y...@voo.be dans mail.voo.be (470460 octets).
fetchmail: lecture du message y...@voo.be@mrouterout.brutele.be:1 parmi 1 
(470460 octets) éliminé
fetchmail: mise en sommeil à mer 29 jui 2009 12:37:22 CEST pour 300 secondes
...



 @+
 -- 
 (o_
 (/)_
 S e r g e
 
 --
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
 ``spam'' dans vos champs From et Reply-To:
 
 Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
 vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 

-- 
Lisez la FAQ de la liste avant de poser une question :
http

Re: fetchmail (procmail mutt) : timeout socket error

[serge]

Le Wednesday 29 July 2009 15:15:49 Michaël Pierson, vous avez écrit :
 Le mercredi 29 juillet 2009 à 08:30:18, se...@srv0.ath.cx a écrit :
  Le Sunday 26 July 2009 12:43:52 Michaël Pierson, vous avez écrit :
   Le vendredi 24 juillet 2009 à 01:25:47, se...@srv0.ath.cx a écrit :
Le Friday 24 July 2009 00:34:30 Michaël Pierson, vous avez écrit :
 Le mercredi 22 juillet 2009 à 10:24:45, Edi Stojicevic a écrit :
  * Michaël Pierson michael.y.f.pier...@gmail.com [2009-07-22
  19:03:35
   
+0200] wrote :
   Je relève mes mails tous les quart d'heure (crontab):
   */15 * * * * fetchmail --silent
 
  Pourquoi ne pas mettre dans ton ~/.fetchmailrc
  set daemon 900

 oui pourquoi pas

   Ce 22 juillet (à quelques autres reprises) j'ai reçu de Cron
   Deamon le mail suivant:
   fetchmail: timeout after 300 seconds waiting for server
   mail.voo.be. fetchmail: socket error while fetching from
   *m...@*server* fetchmail: Query status=2 (SOCKET)
  
   Jj'ai rien dans /var/log/mail.info
 
  et dans /var/log/mail.(err|log) ?

 non rien du tout
   
* Avec ces lignes ( au debut de ~/.fetchmailrc ):
   
set no syslog
set logfile ~/.fetchmail.log
  
   Lignes ajoutées le 24 juillet en début de fichier comme recommandé.
   2 nouveaux messages mails de Cron Deamon le 25.
   Je n'ai pas de fichier ~/.fetchmail.log créé.
  
   @+
   Michaël
 
  Salut;
 
  Il y a deux manières d'utiliser fetchmail:
  - mode utilisateur ( un fichier ~/.fetchmailrc par utilisateur );
  - mode système ( un unique fichier /etc/fetchmailrc pour tous les
utilisateurs et administré par un utilisateur spécifique ou root ).
 
  Les paramètres utilisés pour chaque mode sont certaines fois différents,
  et le mode de lancement différents aussi, mais ils n'utilisent pas un
  service cron.
 
  Celui qui t'intéresse est certainement le mode utilisateur, avec un
  fichier de configuration placé dans le 'home' de l'utilisateur:
  ~/.fetchmailrc
 
  Pour lancer fetchmail automatiquement en mode 'daemon' lorsque
  l'utilisateur se connecte ( login ), on utilise soit '~/.bash_login' ou
  '~/.bash_profile' en y ajoutant:
 
  if [ -f ~/.fetchmailrc -a -x /usr/bin/fetchmail ]; then
  # Vérification des permissions
  if [ $(stat -c '%U %a' ~/.fetchmailrc) != $USER 600 ]; then
  chown -h $USER  ~/.fetchmailrc
  chmod -f 0600  ~/.fetchmailrc
  fi
  # Si il y a une instance de fetchmail
  if [ -f ~/.fetchmail.pid ]; then
  PIDSTATUS=/proc/$(head -n 1 ~/.fetchmail.pid)/status
  if [ -f $PIDSTATUS -a $(grep fetchmail $PIDSTATUS) ]; then
  /usr/bin/fetchmail --quit
  sleep 1
  fi
  fi
  # Lancement de fetchmail en mode daemon
  # avec interval entre ramassage de 300 s
  # et journal des actions.
  /usr/bin/fetchmail  \
  --daemon 300 \
  --logfile ~/.fetchmail.log \
  --pidfile ~/.fetchmail.pid
  fi

 Comme j'utilise zsh, j'ai ajouté ces lignes dans '~.zshrc'

  Par la suite pour terminer proprement fetchmail en sortant, on ajout
  à '~/.bash_logout':
 
  if [ -f ~/.fetchmail.pid ]; then
  PIDSTATUS=/proc/$(head -n 1 ~/.fetchmail.pid)/status
  if [ -f $PIDSTATUS -a $(grep fetchmail $PIDSTATUS) ]; then
  /usr/bin/fetchmail --quit
  fi
  fi

 Et pour sortir proprement j'ai créé un '~.zshrc_logout'


 Voici un extrait de '~.fetchmail.log' avec dépassement de délai et
 erreur socket et 10' plus tard la réception du mail pour ce compte.
 ...
 fetchmail: démarrage de fetchmail 6.3.9-rc2 en tâche de fond
 fetchmail: mise en sommeil à mer 29 jui 2009 12:17:16 CEST pour 300
 secondes fetchmail: réveillé à mer 29 jui 2009 12:22:16 CEST
 fetchmail: 1 message pour x...@gmail.com dans pop.gmail.com (464589 octets).
 fetchmail: lecture du message x...@gmail.com@gmail-pop.l.google.com:1 parmi
 1 (464589 octets) éliminé fetchmail: mise en sommeil à mer 29 jui 2009
 12:22:18 CEST pour 300 secondes fetchmail: réveillé à mer 29 jui 2009
 12:27:18 CEST
 fetchmail: délai dépassé après 300 secondes d'attente du serveur
 mail.voo.be. fetchmail: erreur socket durant la réception de
 y...@voo.be@mail.voo.be fetchmail: État de la requête=2 (SOCKET)
 fetchmail: mise en sommeil à mer 29 jui 2009 12:32:20 CEST pour 300
 secondes fetchmail: réveillé à mer 29 jui 2009 12:37:20 CEST
 fetchmail: 1 message pour y...@voo.be dans mail.voo.be (470460 octets).
 fetchmail: lecture du message y...@voo.be@mrouterout.brutele.be:1 parmi 1
 (470460 octets) éliminé fetchmail: mise en sommeil à mer 29 jui 2009
 12:37:22 CEST pour 300 secondes ...

Tu pourrais montrer la configuration du compte avec  'mail.voo.be' ? C'est un 
compte imap , pop3 , ... ?

Et par la suite, tu utilises 'sendmail', 'procmail' ou un serveur SMTP ? 

Pour l'erreur socket, le man de fetchmail dit:

An error was encountered when attempting to open a socket to retrieve mail. If 
you don't

Re: fetchmail (procmail mutt) : timeout socket error

[Michaël Pierson]

Le mercredi 29 juillet 2009 à 04:54:40, se...@srv0.ath.cx a écrit :
 Le Wednesday 29 July 2009 15:15:49 Michaël Pierson, vous avez écrit :
  Le mercredi 29 juillet 2009 à 08:30:18, se...@srv0.ath.cx a écrit :
   Le Sunday 26 July 2009 12:43:52 Michaël Pierson, vous avez écrit :
Le vendredi 24 juillet 2009 à 01:25:47, se...@srv0.ath.cx a écrit :
 Le Friday 24 July 2009 00:34:30 Michaël Pierson, vous avez écrit :
  Le mercredi 22 juillet 2009 à 10:24:45, Edi Stojicevic a écrit :
   * Michaël Pierson michael.y.f.pier...@gmail.com [2009-07-22
   19:03:35

 +0200] wrote :
Je relève mes mails tous les quart d'heure (crontab):
*/15 * * * * fetchmail --silent
  
   Pourquoi ne pas mettre dans ton ~/.fetchmailrc
   set daemon 900
 
  oui pourquoi pas
 
Ce 22 juillet (à quelques autres reprises) j'ai reçu de Cron
Deamon le mail suivant:
fetchmail: timeout after 300 seconds waiting for server
mail.voo.be. fetchmail: socket error while fetching from
*m...@*server* fetchmail: Query status=2 (SOCKET)
   
Jj'ai rien dans /var/log/mail.info
  
   et dans /var/log/mail.(err|log) ?
 
  non rien du tout

 * Avec ces lignes ( au debut de ~/.fetchmailrc ):

 set no syslog
 set logfile ~/.fetchmail.log
   
Lignes ajoutées le 24 juillet en début de fichier comme recommandé.
2 nouveaux messages mails de Cron Deamon le 25.
Je n'ai pas de fichier ~/.fetchmail.log créé.
   
@+
Michaël
  
   Salut;
  
   Il y a deux manières d'utiliser fetchmail:
 - mode utilisateur ( un fichier ~/.fetchmailrc par utilisateur );
 - mode système ( un unique fichier /etc/fetchmailrc pour tous les
   utilisateurs et administré par un utilisateur spécifique ou root ).
  
   Les paramètres utilisés pour chaque mode sont certaines fois différents,
   et le mode de lancement différents aussi, mais ils n'utilisent pas un
   service cron.
  
   Celui qui t'intéresse est certainement le mode utilisateur, avec un
   fichier de configuration placé dans le 'home' de l'utilisateur:
   ~/.fetchmailrc
  
   Pour lancer fetchmail automatiquement en mode 'daemon' lorsque
   l'utilisateur se connecte ( login ), on utilise soit '~/.bash_login' ou
   '~/.bash_profile' en y ajoutant:
  
   if [ -f ~/.fetchmailrc -a -x /usr/bin/fetchmail ]; then
   # Vérification des permissions
   if [ $(stat -c '%U %a' ~/.fetchmailrc) != $USER 600 ]; then
   chown -h $USER  ~/.fetchmailrc
   chmod -f 0600  ~/.fetchmailrc
   fi
   # Si il y a une instance de fetchmail
   if [ -f ~/.fetchmail.pid ]; then
   PIDSTATUS=/proc/$(head -n 1 ~/.fetchmail.pid)/status
   if [ -f $PIDSTATUS -a $(grep fetchmail $PIDSTATUS) ]; then
   /usr/bin/fetchmail --quit
   sleep 1
   fi
   fi
   # Lancement de fetchmail en mode daemon
   # avec interval entre ramassage de 300 s
   # et journal des actions.
   /usr/bin/fetchmail  \
 --daemon 300 \
 --logfile ~/.fetchmail.log \
 --pidfile ~/.fetchmail.pid
   fi
 
  Comme j'utilise zsh, j'ai ajouté ces lignes dans '~.zshrc'
 
   Par la suite pour terminer proprement fetchmail en sortant, on ajout
   à '~/.bash_logout':
  
   if [ -f ~/.fetchmail.pid ]; then
   PIDSTATUS=/proc/$(head -n 1 ~/.fetchmail.pid)/status
   if [ -f $PIDSTATUS -a $(grep fetchmail $PIDSTATUS) ]; then
   /usr/bin/fetchmail --quit
   fi
   fi
 
  Et pour sortir proprement j'ai créé un '~.zshrc_logout'
 
 
  Voici un extrait de '~.fetchmail.log' avec dépassement de délai et
  erreur socket et 10' plus tard la réception du mail pour ce compte.
  ...
  fetchmail: démarrage de fetchmail 6.3.9-rc2 en tâche de fond
  fetchmail: mise en sommeil à mer 29 jui 2009 12:17:16 CEST pour 300
  secondes fetchmail: réveillé à mer 29 jui 2009 12:22:16 CEST
  fetchmail: 1 message pour x...@gmail.com dans pop.gmail.com (464589 octets).
  fetchmail: lecture du message x...@gmail.com@gmail-pop.l.google.com:1 parmi
  1 (464589 octets) éliminé fetchmail: mise en sommeil à mer 29 jui 2009
  12:22:18 CEST pour 300 secondes fetchmail: réveillé à mer 29 jui 2009
  12:27:18 CEST
  fetchmail: délai dépassé après 300 secondes d'attente du serveur
  mail.voo.be. fetchmail: erreur socket durant la réception de
  y...@voo.be@mail.voo.be fetchmail: État de la requête=2 (SOCKET)
  fetchmail: mise en sommeil à mer 29 jui 2009 12:32:20 CEST pour 300
  secondes fetchmail: réveillé à mer 29 jui 2009 12:37:20 CEST
  fetchmail: 1 message pour y...@voo.be dans mail.voo.be (470460 octets).
  fetchmail: lecture du message y...@voo.be@mrouterout.brutele.be:1 parmi 1
  (470460 octets) éliminé fetchmail: mise en sommeil à mer 29 jui 2009
  12:37:22 CEST pour 300 secondes ...
 
 Tu pourrais montrer la configuration du compte avec  'mail.voo.be' ? C'est un 
 compte imap , pop3 , ... ?

Voici l'intégrale de '~/.fetchmailrc

Re: fetchmail (procmail mutt) : timeout socket error

[Michaël Pierson]

Le vendredi 24 juillet 2009 à 01:25:47, se...@srv0.ath.cx a écrit :
 Le Friday 24 July 2009 00:34:30 Michaël Pierson, vous avez écrit :
  Le mercredi 22 juillet 2009 à 10:24:45, Edi Stojicevic a écrit :
   * Michaël Pierson michael.y.f.pier...@gmail.com [2009-07-22 19:03:35 
 +0200] wrote :
Je relève mes mails tous les quart d'heure (crontab):
*/15 * * * * fetchmail --silent
  
   Pourquoi ne pas mettre dans ton ~/.fetchmailrc
   set daemon 900
 
  oui pourquoi pas
 
Ce 22 juillet (à quelques autres reprises) j'ai reçu de Cron Deamon le
mail suivant:
fetchmail: timeout after 300 seconds waiting for server mail.voo.be.
fetchmail: socket error while fetching from *m...@*server*
fetchmail: Query status=2 (SOCKET)
   
Jj'ai rien dans /var/log/mail.info
  
   et dans /var/log/mail.(err|log) ?
 
  non rien du tout
 
 * Avec ces lignes ( au debut de ~/.fetchmailrc ):
 
 set no syslog
 set logfile ~/.fetchmail.log

Lignes ajoutées le 24 juillet en début de fichier comme recommandé.
2 nouveaux messages mails de Cron Deamon le 25.
Je n'ai pas de fichier ~/.fetchmail.log créé.

@+
Michaël

 
 @+
 -- 
 (o_
 (/)_
 S e r g e
 
 --
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
 ``spam'' dans vos champs From et Reply-To:
 
 Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
 vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: fetchmail (procmail mutt) : timeout socket error

[serge]

Le Friday 24 July 2009 00:34:30 Michaël Pierson, vous avez écrit :
 Le mercredi 22 juillet 2009 à 10:24:45, Edi Stojicevic a écrit :
  * Michaël Pierson michael.y.f.pier...@gmail.com [2009-07-22 19:03:35 
+0200] wrote :
   Je relève mes mails tous les quart d'heure (crontab):
   */15 * * * * fetchmail --silent
 
  Pourquoi ne pas mettre dans ton ~/.fetchmailrc
  set daemon 900

 oui pourquoi pas

   Ce 22 juillet (à quelques autres reprises) j'ai reçu de Cron Deamon le
   mail suivant:
   fetchmail: timeout after 300 seconds waiting for server mail.voo.be.
   fetchmail: socket error while fetching from *m...@*server*
   fetchmail: Query status=2 (SOCKET)
  
   Jj'ai rien dans /var/log/mail.info
 
  et dans /var/log/mail.(err|log) ?

 non rien du tout

* Avec ces lignes ( au debut de ~/.fetchmailrc ):

set no syslog
set logfile ~/.fetchmail.log

@+
-- 
(o_
(/)_
S e r g e

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: fetchmail (procmail mutt) : timeout socket error

[Michaël Pierson]

Le mercredi 22 juillet 2009 à 10:24:45, Edi Stojicevic a écrit :
 * Michaël Pierson michael.y.f.pier...@gmail.com [2009-07-22 19:03:35 +0200] 
 wrote :
 
  Je relève mes mails tous les quart d'heure (crontab):
  */15 * * * * fetchmail --silent

 Pourquoi ne pas mettre dans ton ~/.fetchmailrc 
 set daemon 900

oui pourquoi pas  
 
 
  Ce 22 juillet (à quelques autres reprises) j'ai reçu de Cron Deamon le mail
  suivant:
  fetchmail: timeout after 300 seconds waiting for server mail.voo.be.
  fetchmail: socket error while fetching from *m...@*server*
  fetchmail: Query status=2 (SOCKET)
  
  Jj'ai rien dans /var/log/mail.info

 et dans /var/log/mail.(err|log) ?

non rien du tout


 
 -- 
  .''`.  Edi Stojicevic
 : :'  : Debian GNU/Linux user, admin  developer - http://www.debian.org
 `. `~'  French speaking Debian website founder   - http://www.debianworld.org
   `-GPG Key Id : 0x1237B032
 
 -- 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

fetchmail (procmail mutt) : timeout socket error

[Michaël Pierson]

Je relève mes mails tous les quart d'heure (crontab):
*/15 * * * * fetchmail --silent

Ce 22 juillet (à quelques autres reprises) j'ai reçu de Cron Deamon le mail
suivant:
fetchmail: timeout after 300 seconds waiting for server mail.voo.be.
fetchmail: socket error while fetching from *m...@*server*
fetchmail: Query status=2 (SOCKET)

Jj'ai rien dans /var/log/mail.info
Le dernier message date du 19 juillet

Une idée ou une direction de recherche?

Re: fetchmail (procmail mutt) : timeout socket error

[Edi Stojicevic]

* Michaël Pierson michael.y.f.pier...@gmail.com [2009-07-22 19:03:35 +0200] 
wrote :

 Je relève mes mails tous les quart d'heure (crontab):
 */15 * * * * fetchmail --silent

Pourquoi ne pas mettre dans ton ~/.fetchmailrc 

set daemon 900


 Ce 22 juillet (à quelques autres reprises) j'ai reçu de Cron Deamon le mail
 suivant:
 fetchmail: timeout after 300 seconds waiting for server mail.voo.be.
 fetchmail: socket error while fetching from *m...@*server*
 fetchmail: Query status=2 (SOCKET)
 
 Jj'ai rien dans /var/log/mail.info
 Le dernier message date du 19 juillet

 Une idée ou une direction de recherche?

et dans /var/log/mail.(err|log) ?

-- 
 .''`.  Edi Stojicevic
: :'  : Debian GNU/Linux user, admin  developer - http://www.debian.org
`. `~'  French speaking Debian website founder   - http://www.debianworld.org
  `-GPG Key Id : 0x1237B032

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

sarge, 2.6.20.3, libata, timeout et autres messages

[Nicolas KOWALSKI]

Bonjour,

Ma machine sarge utilise un noyau 2.6.20.3, avec libata pour le disque IDE 
(chipset piix). Ca marche très bien, mais au bout de quelques minutes, les 
erreurs suivantes apparaissent, une seule fois :


ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd ca/00:08:c7:87:4b/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 out
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1: soft resetting port
ata1.00: configured for UDMA/33
ata1: EH complete
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA


Avez vous constaté aussi de votre côté de type d'erreurs ? De 
quoi s'agit-il ? Sont-elles sans conséquences ?


Merci d'avance,
--
Nicolas


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et

Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

imposer un timeout sur un mount -t nfs ...

[Daniel Caillibaud]

Bonjour,

J'ai un script de surveillance qui vérifie un montage nfs et fait un umount  
mount en cas de besoin (ça règle 95% des pbs).

Mon problème est que si le serveur nfs est HS, le mount ne rend pas la main, et donc la ligne suivante du script n'est pas exécutée, et donc l'alerte 
jamais envoyée...

C'est gênant pour un script de monitoring :-/

Y'a moyen d'imposer un timeout à mount ?

Sinon, on peut le lancer en tache de fond et le tuer s'il a pas fini apres qq 
secondes, mais ça me parait un peu bancal non ?

remplacer mon
umount /nfs $TMP 21  mount /nfs $TMP 21 || mail -s 'alerte nfs' moi 
$TMP

par
mount -o remount /nfs $TMP 21 
sleep 10
[ $(ps aux|grep [m]ount|wc -l) -gt 0 ]  killall mount
mail -s 'alerte nfs' moi $TMP

--
Daniel

R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin de message est-il si effroyable?
R: Répondre au dessus de la citation
Q: Quelle est la chose la plus désagréable dans un message ?


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et

Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

tty timeout

[Wallace]

Bonsoir,
Je cherche a faire un timeout sur les tty (les consoles locales).
En fait a mon boulot les autres admin sont pas aussi paranos que moi et
ne se delogue pas des consoles, je voudrais donc que ces dernieres sans 
activite au bout de 10min par ex fassent logout.

Une contrainte par contre c'est qu'il ne faut pas que ce logout vienne 
du shell car des connexions ssh doivent pouvoir tenir plus longtemps en 
timeout.

J'ai bien pense a faire un kill des shell des tty dans la nuit mais je 
ne trouve pas ca propre.

Merci pour vos conseils
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To:
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: tty timeout

[Wallace]

kolter a écrit :
l'astuce est ici : http://linuxfr.org/tips/182.html
à mettre dans le .bashrc des utilisateurs ou plutot dans /etc/bashrc si t'es 
admin

C'est ce que je disais dans le message a savoir qu'il ne faut pas que ca 
soit le shell qui le gere a cause des consoles ssh qui doivent rester 
ouverte plusieurs heures parfois.
De plus le timeout dans le shell veut dire le faire pour tous les shell
sachant que zsh est le shell pour root et quelques utilisateurs
et que bash l'est pour d'autre ce n'est pas gerable.

++
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To:
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: tty timeout

[Frédéric Bothamy]

* Wallace [EMAIL PROTECTED] [2005-01-20 18:56] :
 Bonsoir,
 Je cherche a faire un timeout sur les tty (les consoles locales).
 En fait a mon boulot les autres admin sont pas aussi paranos que moi et
 ne se delogue pas des consoles, je voudrais donc que ces dernieres sans 
 activite au bout de 10min par ex fassent logout.
 
 Une contrainte par contre c'est qu'il ne faut pas que ce logout vienne 
 du shell car des connexions ssh doivent pouvoir tenir plus longtemps en 
 timeout.
 
 J'ai bien pense a faire un kill des shell des tty dans la nuit mais je 
 ne trouve pas ca propre.

timeoutd semble être le paquet que tu cherches. D'après sa description :

Description: Flexible user timeout daemon with X11 support
 timeoutd enforces the time restrictions specified for each or all users.
 .
 timeoutd scans /var/run/utmp every minute and checks /etc/timeouts for
 an entry which matches a restricted user, based on:
 .
  - The current day and time
  - The tty that the user is currently logged in on
  - The user's login ID
  - Any primary or secondary groups the user is in
 timeoutd can restrict local users, local X11-users and remote users via
 telnet/SSH for a maximum of their session, max. day, idle or no login  at
 all.
 .
 timeoutd is also able to restrict users running X.


Fred

-- 
Comment poser les questions de manière intelligente ?
http://www.gnurou.org/documents/smart-questions-fr.html
Comment signaler efficacement un bug ?
http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html


-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

tty timeout

[Wallace]

Bonsoir,
Je cherche a faire un timeout sur les tty (les consoles locales).
En fait a mon boulot les autres admin sont pas aussi paranos que moi et
ne se delogue pas des consoles, je voudrais donc que ces dernieres sans 
activite au bout de 10min par ex fassent logout.


Une contrainte par contre c'est qu'il ne faut pas que ce logout vienne 
du shell car des connexions ssh doivent pouvoir tenir plus longtemps en 
timeout.


J'ai bien pense a faire un kill des shell des tty dans la nuit mais je 
ne trouve pas ca propre.


Merci pour vos conseils

Re: tty timeout

[kolter]

Le Jeudi 20 Janvier 2005 18:56, Wallace a écrit :
 Bonsoir,
 Je cherche a faire un timeout sur les tty (les consoles locales).
 En fait a mon boulot les autres admin sont pas aussi paranos que moi et
 ne se delogue pas des consoles, je voudrais donc que ces dernieres sans
 activite au bout de 10min par ex fassent logout.

l'astuce est ici : http://linuxfr.org/tips/182.html

à mettre dans le .bashrc des utilisateurs ou plutot dans /etc/bashrc si t'es 
admin


 Une contrainte par contre c'est qu'il ne faut pas que ce logout vienne
 du shell car des connexions ssh doivent pouvoir tenir plus longtemps en
 timeout.

 J'ai bien pense a faire un kill des shell des tty dans la nuit mais je
 ne trouve pas ca propre.

 Merci pour vos conseils

-- 
Emmanuel Bouthenot (aka Kolter)
  MAIL : free.fr / kolter (at)
   GPG : 0x414EC36E
   WWW : http://kolter.free.fr
JABBER : amessage.de / kolter (at)

Re: tty timeout

[Wallace]

kolter a écrit :


l'astuce est ici : http://linuxfr.org/tips/182.html

à mettre dans le .bashrc des utilisateurs ou plutot dans /etc/bashrc si t'es 
admin


C'est ce que je disais dans le message a savoir qu'il ne faut pas que ca 
soit le shell qui le gere a cause des consoles ssh qui doivent rester 
ouverte plusieurs heures parfois.

De plus le timeout dans le shell veut dire le faire pour tous les shell
sachant que zsh est le shell pour root et quelques utilisateurs
et que bash l'est pour d'autre ce n'est pas gerable.

++

Re: tty timeout

[kolter]

Le Jeudi 20 Janvier 2005 21:46, Wallace a écrit :
 kolter a écrit :
  l'astuce est ici : http://linuxfr.org/tips/182.html
 
  à mettre dans le .bashrc des utilisateurs ou plutot dans /etc/bashrc si
  t'es admin

 C'est ce que je disais dans le message a savoir qu'il ne faut pas que ca
 soit le shell qui le gere a cause des consoles ssh qui doivent rester
 ouverte plusieurs heures parfois.
 De plus le timeout dans le shell veut dire le faire pour tous les shell
 sachant que zsh est le shell pour root et quelques utilisateurs
 et que bash l'est pour d'autre ce n'est pas gerable.

 ++

pas gérable ?

hum : pour les shells les plus courants (dash, bash, (t)csh, zsh, ksh, ...) je 
pense que c'est faisable : sachant ce que tu disais que tu as pensé à faire 
un kill des shell pdt la nuit tu dois bien savoir lesquels sont utilisé et 
donc pouvoir modifié le fichier *rc générique (dans /etc en général) associé
pour qu'il gère ce timeout ..

en ce qui concerne ssh, quand t'es connecté en ssh, des variables 
d'environemment sont définies : comme $SSH_CLIENT et $SSH_TTY 
CQFD : une conditionelle dans les fichiers *rc de chaque shell et on atteint 
normalement les shell non-ssh ...

M.

-- 
Emmanuel Bouthenot (aka Kolter)
  MAIL : free.fr / kolter (at)
   GPG : 0x414EC36E
   WWW : http://kolter.free.fr
JABBER : amessage.de / kolter (at)

Re: tty timeout

[Frédéric Bothamy]

* Wallace [EMAIL PROTECTED] [2005-01-20 18:56] :
 Bonsoir,
 Je cherche a faire un timeout sur les tty (les consoles locales).
 En fait a mon boulot les autres admin sont pas aussi paranos que moi et
 ne se delogue pas des consoles, je voudrais donc que ces dernieres sans 
 activite au bout de 10min par ex fassent logout.
 
 Une contrainte par contre c'est qu'il ne faut pas que ce logout vienne 
 du shell car des connexions ssh doivent pouvoir tenir plus longtemps en 
 timeout.
 
 J'ai bien pense a faire un kill des shell des tty dans la nuit mais je 
 ne trouve pas ca propre.

timeoutd semble être le paquet que tu cherches. D'après sa description :

Description: Flexible user timeout daemon with X11 support
 timeoutd enforces the time restrictions specified for each or all users.
 .
 timeoutd scans /var/run/utmp every minute and checks /etc/timeouts for
 an entry which matches a restricted user, based on:
 .
  - The current day and time
  - The tty that the user is currently logged in on
  - The user's login ID
  - Any primary or secondary groups the user is in
 timeoutd can restrict local users, local X11-users and remote users via
 telnet/SSH for a maximum of their session, max. day, idle or no login  at
 all.
 .
 timeoutd is also able to restrict users running X.


Fred

-- 
Comment poser les questions de manière intelligente ?
http://www.gnurou.org/documents/smart-questions-fr.html
Comment signaler efficacement un bug ?
http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html

Re: 2.6.8, WiFi et chipset Prism54 -- timeout [RESOLU]

[Stephane List]

dlist wrote:

Il est quand même agaçant de voir que des société se permettent  
d'appeler du même nom des produits différents. RIEN n'indique nulle 
part que c'est une V2.
   



il m'est arrivé la même chose avec une carte Netgear WG511 que j'ai
acheté la semaine dernière. Elle était sensé avoir un chipset Prism2
or 'lspci' me montrait un chipset Texas Instrument, qui ne marche
absolument pas avec linux (donc avec ndiswrapper), et bien sûr cela
n'était écrit nulle part (à part sur la carte elle-même (un V2..
mais rien à propos de TI), mais je n'ai pas pu ouvrir l'emballage au
magasin).


J'ai ramené la carte et me suis tourné vers une carte Planet wl-3560
(802.11g+) , avec un chipset Atheros. Le driver de madwifi fonctionne
nikel en 11M (pas eu le temps de tester les autres vitesses) et je
peux m'amuser avec Kismet (en passant, seulement 27% des signaux sont
cryptés avec une clé WEP, expérience du jour , ..., c'est fou).

Voilà, c'est pas de la pub, c'est juste pour éviter - peut-être -  à
d'autres de s'emmerder avec cette désinformation chronique de
certaines sociétés sur leurs produits.

A+

 


Jean-Luc

   



S.


 



Les cartes wifi a base de TI marche tres bien sous Linux :
http://acx100.sourceforge.net/

Je ne dis pas ca parceque je bosse chez TI, mais parceque j'ai 2 cartes 
wifi chez moi, et je n'ai pas de soucis ;-)

http://slist.lilotux.net/acx100/

A +

Steph

Re: 2.6.8, WiFi et chipset Prism54 -- timeout [RESOLU]

[Sébastien GALLET]

Stephane List a écrit :
Salut


Les cartes wifi a base de TI marche tres bien sous Linux :
http://acx100.sourceforge.net/

Je confirme j'ai une dlink dwl-520+ et elle fonctionne sous linux 
(2.4.27) ( et je ne bosse pas chez TI ;) ).
Une petite question : as-tu essayé de faire fonctionner cette carte en 
mode master (pour en faire un AP) ?




A +

Steph

Seb

Re: 2.6.8, WiFi et chipset Prism54 -- timeout [RESOLU]

[dlist]

Le vendredi 15 oct 2004 à 19 h 40, Jean-Luc a dit:

 Le 15.10.2004 20:24:49, dlist a écrit :
 
 
  Il est quand même agaçant de voir que des société se permettent
  d'appeler du même nom des produits différents. RIEN n'indique
 nulle part que c'est une V2.
 
 il m'est arrivé la même chose avec une carte Netgear WG511 que j'ai
 acheté la semaine dernière. Elle était sensé avoir un chipset
 Prism2 or 'lspci' me montrait un chipset Texas Instrument, qui ne
 marche absolument pas avec linux (donc avec ndiswrapper), et bien
 sûr cela n'était écrit nulle part (à part sur la carte elle-même
 (un V2.. mais rien à propos de TI), mais je n'ai pas pu ouvrir
 l'emballage au magasin).
 
 
 J'ai ramené la carte et me suis tourné vers une carte Planet
 wl-3560(802.11g+) , avec un chipset Atheros. Le driver de madwifi
 fonctionne
 
 Qu'est-ce que le driver de madwifi ?

le driver pour les chipset Atheros, cf.
http://sourceforge.net/projects/madwifi/

 
 nikel en 11M (pas eu le temps de tester les autres vitesses) et je
 peux m'amuser avec Kismet (en passant, seulement 27% des signaux
 sont cryptés avec une clé WEP, expérience du jour , ..., c'est
 fou).
 
 J'ai une wanadoo livebox. Elle supporte le chiffrage wap/wep.
 Elle est livrée avec un dongle usb en 802.11g. Avec lui, pas de  
 problème, on peut fonctionner avec la clé wep.
 
 Avec la carte smc2802w sous windows et les drivers d'origine, je
 suis  obligé de mettre hors service la clé de chiffrage, sinon la
 carte ne se  connecte pas.

[...] 

 
 Sous linux, je n'ai pas essayé encore. Mais je ne pense pas que ça
 doit  fonctionner mieux que sous win vu que les drivers utilisés par
  
 ndiswrapper sont ceux de windows

à éviter donc .. :)

 
 C'est assez gênant car le périphérique ne peut pas être enregistré
 au  niveau du routeur, il est donc nécessaire de laisser celui-ci
 ouvert  en permanence. Je ne tiens pas particulièrement à servir
 de fournisseur  d'accès pour les voisins Le risque reste quand
 même limité... par  la porté radio de l'engin qui n'est pas terrible
 terrible.

combien? 300 mètres?

 
 
 Voilà, c'est pas de la pub, c'est juste pour éviter - peut-être - 
 à d'autres de s'emmerder avec cette désinformation chronique de
 certaines sociétés sur leurs produits.
 
 A+
 S.
 
 
 Jean-Luc
 

S.

Re: 2.6.8, WiFi et chipset Prism54 -- timeout [RESOLU]

[Jean-Luc Coulon (f5ibh)]

Le 16.10.2004 10:24:43, dlist a écrit :

Le vendredi 15 oct 2004 à 19 h 40, Jean-Luc a dit:


Le 15.10.2004 20:24:49, dlist a écrit :


[ ... ]


Qu'est-ce que le driver de madwifi ?


le driver pour les chipset Atheros, cf.
http://sourceforge.net/projects/madwifi/




[ ... ]


fou).

J'ai une wanadoo livebox. Elle supporte le chiffrage wap/wep.
Elle est livrée avec un dongle usb en 802.11g. Avec lui, pas de
problème, on peut fonctionner avec la clé wep.

Avec la carte smc2802w sous windows et les drivers d'origine, je
suis  obligé de mettre hors service la clé de chiffrage, sinon la
carte ne se  connecte pas.


[...]



Sous linux, je n'ai pas essayé encore. Mais je ne pense pas que ça
doit  fonctionner mieux que sous win vu que les drivers utilisés par

ndiswrapper sont ceux de windows


à éviter donc .. :)


Essai ce matin de mettre une clé... et miracle (petit, mais quand  
même...), la carte s'est enregistrée sur la livebox et ça fonctionne.






C'est assez gênant car le périphérique ne peut pas être enregistré
au  niveau du routeur, il est donc nécessaire de laisser celui-ci
ouvert  en permanence. Je ne tiens pas particulièrement à servir
de fournisseur  d'accès pour les voisins Le risque reste quand
même limité... par  la porté radio de l'engin qui n'est pas terrible
terrible.


combien? 300 mètres?


A l'intérieur de la maison... c'est déjà bien...


Jean-Luc


pgp9cOrHYwdqq.pgp
Description: PGP signature

Re: 2.6.8, WiFi et chipset Prism54 -- timeout [RESOLU]

[Yves Rutschle]

On Fri, Oct 15, 2004 at 07:40:00PM +, Jean-Luc Coulon
(f5ibh) wrote:
 (en passant, seulement 27% des signaux sont cryptés avec
 une clé WEP, expérience du jour , ..., c'est fou).

Sans doute parce que WEP ne sert à rien: ça se casse très
facilement[1]. Ça ne fait donc que donner une illusion de
sécurité, un peu comme cacher son argent sous son oreiller
en laissant sa porte ouverte. Personellement, je pense que
WEP fait plus de mal que de bien, justement car il fait
penser qu'on est en sécurité.

Si tu veux que ton réseau soit sûr, il faut le penser d'une
façon telle qu'un attaquant qui a un accès physique
(sans-fil, ou même un port sur un switch[2]) au
réseau ne puisse pas le pénetrer, et ça implique d'avoir
toutes les communications entre machine, encruptées
point-à-point, avec, par exemple, SSH. En d'autre termes, il
faut considérer que le réseau intérieur est aussi sûr que
l'Internet.

Y. - briseur de petites bulles

[1] http://whitepapers.zdnet.co.uk/0,39025945,60022729p,00.htm
[2] Voir à ce propor Ocean's Eleven

Re: 2.6.8, WiFi et chipset Prism54 -- timeout [RESOLU]

[dlist]

Le samedi 16 oct 2004 à 09 h 21, Yves a dit:

 On Fri, Oct 15, 2004 at 07:40:00PM +, Jean-Luc Coulon
 (f5ibh) wrote:
  (en passant, seulement 27% des signaux sont cryptés avec
  une clé WEP, expérience du jour , ..., c'est fou).

faute de typo ici en fait: je parlais de WPA.

 
 Sans doute parce que WEP ne sert à rien: ça se casse très
 facilement[1]. Ça ne fait donc que donner une illusion de
 sécurité, un peu comme cacher son argent sous son oreiller
 en laissant sa porte ouverte. Personellement, je pense que
 WEP fait plus de mal que de bien, justement car il fait
 penser qu'on est en sécurité.

WEP ok, mais WPA?

 
 Si tu veux que ton réseau soit sûr, il faut le penser d'une
 façon telle qu'un attaquant qui a un accès physique
 (sans-fil, ou même un port sur un switch[2]) au
 réseau ne puisse pas le pénetrer, et ça implique d'avoir
 toutes les communications entre machine, encruptées
 point-à-point, avec, par exemple, SSH. En d'autre termes, il
 faut considérer que le réseau intérieur est aussi sûr que
 l'Internet.

donc pas sûr.

 
 Y. - briseur de petites bulles

Attention à Perrier.

 
 [1] http://whitepapers.zdnet.co.uk/0,39025945,60022729p,00.htm

n'existe plus.

 [2] Voir à ce propor Ocean's Eleven
 
 
 -- 
 Pensez à lire la FAQ de la liste avant de poser une question :
 http://wiki.debian.net/?DebianFrench
 
 Pensez à rajouter le mot ``spam'' dans vos champs From et
 Reply-To:
 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact
 [EMAIL PROTECTED]
 

Re: 2.6.8, WiFi et chipset Prism54 -- timeout

[Jean-Luc Coulon (f5ibh)]

Le 15.10.2004 01:30:14, François TOURDE a écrit :

Le 12705ième jour après Epoch,
Jean-Luc Coulon écrivait:


Quelle est votre version de kernel avec lequel la carte focntionne ?


Actuellement, avec un 2.6.5 mais je crois (sans être sûr à 100%)
qu'elle marche en 2.6.8


Pourrais-je savoir quel est la somme md5 de votre firmware ?

j'ai essayé :
1f0a68fbe45963f76e525c9789f5609c  1.0.3.0.arm
8bd4310971772a486b9784c77f8a6df9  1.0.4.3.arm


fermat:~# md5sum /usr/lib/hotplug/firmware/isl3890
8bd4310971772a486b9784c77f8a6df9  /usr/lib/hotplug/firmware/isl3890


Ca rassure un peu : le dilemne est je garde la carte ou je la

retourne ...

La loi donnant 7 jours, il faut que je me dépèche ...


J'ai fait aussi vite que j'ai pû ;)

Autres infos éventuellement, je joins un lspci -v pour voir les
conflits ou autres infos.




fermat:~# lspci -v


[ ... ]


:02:03.0 Network controller: Intersil Corporation Intersil ISL3890
[Prism GT/Prism Duette] (rev 01)
Subsystem: Unknown device 17cf:0014
Flags: bus master, medium devsel, latency 80, IRQ 11
Memory at f8ffc000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [dc] Power Management version 1



Là se situe la différence :
:00:0c.0 Network controller: Intersil Corporation Intersil ISL3890  
[Prism GT/Prism Duette] (rev 01)
   Subsystem: Accton Technology Corporation SMC2802W V2 Wireless  
PCI Adapter

   Flags: bus master, medium devsel, latency 80, IRQ 11
   Memory at da00 (32-bit, non-prefetchable) [size=8K]
   Capabilities: [dc] Power Management version 1

Il me donnait d'abord unknown device 00eE, parès avoir mis à jour les  
ids (update-pciids), j'ai retrouvé la désignation de ma carte :
SMC2802W V2 ... Et le V2 fait toute la différence : il n'est pas  
supporté par le projet PRISM54 (pas encore).


J'ai trouvé un projet qui s'appelle ndiswrapper, il y a un source  
debian pour le module et les utilitaires. Il prend en entrée les  
drivers Windows et construit un module... Cette carte (V2) est censée  
être supportée. Mais après avoir chargé normalement le module, ma carte  
n'est pas vue par le systèeme.


Jean-Luc


pgpE725MeP2in.pgp
Description: PGP signature

Re: 2.6.8, WiFi et chipset Prism54 -- timeout [RESOLU]

[Jean-Luc Coulon (f5ibh)]

Le 15.10.2004 11:39:13, Jean-Luc Coulon (f5ibh) a écrit :

Le 15.10.2004 01:30:14, François TOURDE a écrit :


[ ... ]


Il me donnait d'abord unknown device 00eE, parès avoir mis à jour les  
ids (update-pciids), j'ai retrouvé la désignation de ma carte :
SMC2802W V2 ... Et le V2 fait toute la différence : il n'est pas  
supporté par le projet PRISM54 (pas encore).


J'ai trouvé un projet qui s'appelle ndiswrapper, il y a un source  
debian pour le module et les utilitaires. Il prend en entrée les  
drivers Windows et construit un module... Cette carte (V2) est censée  
être supportée. Mais après avoir chargé normalement le module, ma  
carte n'est pas vue par le systèeme.


Ca marche avec ndiswrapper.
le seul problème venait du driver windows que j'avais trouvé et qui  
était inadapté.



Bon après-midi à tous

Jean-Luc


pgpH6i3D1XR8l.pgp
Description: PGP signature

Re: 2.6.8, WiFi et chipset Prism54 -- timeout [RESOLU]

[François TOURDE]

Le 12706ième jour après Epoch,
Jean-Luc Coulon écrivait:

 Le 15.10.2004 11:39:13, Jean-Luc Coulon (f5ibh) a écrit :
 Le 15.10.2004 01:30:14, François TOURDE a écrit :

 [ ... ]
 
 Il me donnait d'abord unknown device 00eE, parès avoir mis à jour les  
 ids (update-pciids), j'ai retrouvé la désignation de ma carte :
 SMC2802W V2 ... Et le V2 fait toute la différence : il n'est pas  
 supporté par le projet PRISM54 (pas encore).
 
 J'ai trouvé un projet qui s'appelle ndiswrapper, il y a un source  
 debian pour le module et les utilitaires. Il prend en entrée les  
 drivers Windows et construit un module... Cette carte (V2) est censée  
 être supportée. Mais après avoir chargé normalement le module, ma  
 carte n'est pas vue par le systèeme.

 Ca marche avec ndiswrapper.
 le seul problème venait du driver windows que j'avais trouvé et qui  
 était inadapté.

Cool. Ravi pour toi que ça marche. Et merci d'avoir posté la solution
pour les autres. Habitude qui semble se perdre ;)

Par contre, regarde dans les archives récentes (1 ou 2 mois), il y a
eu des fils au sujet de ndiswrapper et de quelques un de ses soucis.


pgp97XIIW7tL7.pgp
Description: PGP signature

Re: 2.6.8, WiFi et chipset Prism54 -- timeout [RESOLU]

[Jean-Luc Coulon (f5ibh)]

Le 15.10.2004 15:39:30, François TOURDE a écrit :

Le 12706ième jour après Epoch,
Jean-Luc Coulon écrivait:


Le 15.10.2004 11:39:13, Jean-Luc Coulon (f5ibh) a écrit :

Le 15.10.2004 01:30:14, François TOURDE a écrit :


[ ... ]


Il me donnait d'abord unknown device 00eE, parès avoir mis à jour

les

ids (update-pciids), j'ai retrouvé la désignation de ma carte :
SMC2802W V2 ... Et le V2 fait toute la différence : il n'est pas
supporté par le projet PRISM54 (pas encore).

J'ai trouvé un projet qui s'appelle ndiswrapper, il y a un source
debian pour le module et les utilitaires. Il prend en entrée les
drivers Windows et construit un module... Cette carte (V2) est

censée

être supportée. Mais après avoir chargé normalement le module, ma
carte n'est pas vue par le systèeme.


Ca marche avec ndiswrapper.
le seul problème venait du driver windows que j'avais trouvé et qui
était inadapté.


Cool. Ravi pour toi que ça marche. Et merci d'avoir posté la solution
pour les autres. Habitude qui semble se perdre ;)

Par contre, regarde dans les archives récentes (1 ou 2 mois), il y a
eu des fils au sujet de ndiswrapper et de quelques un de ses soucis.



J'ai fouillé les archives, je vois des personnes se plaindre de  
problèmes de connexion ou de portée, rien de plus. Mais il est vraique  
c'est un peu galère de chercher dans les archives.


Il y a un problème de packaging Debian de ndiswrapper... Mais bon, je  
suis arrivé à m'en accomoder. Par exemple : il créé les paquets debian  
des modules et des utilitaires dans /usr/src/modules, il faut être root  
pour pouvoir décompresser l'archive et ensuite créer les paquets, la  
cible du paquet est la version de linux qui tourne et pas celle qu'on  
est en train de compiler. Normalement, tout ce qui se trouve dans /usr/ 
src/modules devrait pouvoir être construit avec la cible modules_image  
de make_kpkg. Mais ce n'est pas trop grave.


Sinon, la connexion a été immédiate et les taux de transfert honorables  
d'un étage à l'autre.


Il est quand même agaçant de voir que des société se permettent  
d'appeler du même nom des produits différents. RIEN n'indique nulle  
part que c'est une V2.


Jean-Luc


pgp5bRyAy3Hcr.pgp
Description: PGP signature

Re: 2.6.8, WiFi et chipset Prism54 -- timeout [RESOLU]

[dlist]

 
 Il est quand même agaçant de voir que des société se permettent  
 d'appeler du même nom des produits différents. RIEN n'indique nulle 
 part que c'est une V2.

il m'est arrivé la même chose avec une carte Netgear WG511 que j'ai
acheté la semaine dernière. Elle était sensé avoir un chipset Prism2
or 'lspci' me montrait un chipset Texas Instrument, qui ne marche
absolument pas avec linux (donc avec ndiswrapper), et bien sûr cela
n'était écrit nulle part (à part sur la carte elle-même (un V2..
mais rien à propos de TI), mais je n'ai pas pu ouvrir l'emballage au
magasin).


J'ai ramené la carte et me suis tourné vers une carte Planet wl-3560
(802.11g+) , avec un chipset Atheros. Le driver de madwifi fonctionne
nikel en 11M (pas eu le temps de tester les autres vitesses) et je
peux m'amuser avec Kismet (en passant, seulement 27% des signaux sont
cryptés avec une clé WEP, expérience du jour , ..., c'est fou).

Voilà, c'est pas de la pub, c'est juste pour éviter - peut-être -  à
d'autres de s'emmerder avec cette désinformation chronique de
certaines sociétés sur leurs produits.

A+

 
 Jean-Luc
 

S.

Re: 2.6.8, WiFi et chipset Prism54 -- timeout [RESOLU]

[Jean-Luc Coulon (f5ibh)]

Le 15.10.2004 20:24:49, dlist a écrit :




Il est quand même agaçant de voir que des société se permettent
d'appeler du même nom des produits différents. RIEN n'indique nulle
part que c'est une V2.


il m'est arrivé la même chose avec une carte Netgear WG511 que j'ai
acheté la semaine dernière. Elle était sensé avoir un chipset Prism2
or 'lspci' me montrait un chipset Texas Instrument, qui ne marche
absolument pas avec linux (donc avec ndiswrapper), et bien sûr cela
n'était écrit nulle part (à part sur la carte elle-même (un V2..
mais rien à propos de TI), mais je n'ai pas pu ouvrir l'emballage au
magasin).


J'ai ramené la carte et me suis tourné vers une carte Planet wl-3560
(802.11g+) , avec un chipset Atheros. Le driver de madwifi fonctionne


Qu'est-ce que le driver de madwifi ?


nikel en 11M (pas eu le temps de tester les autres vitesses) et je
peux m'amuser avec Kismet (en passant, seulement 27% des signaux sont
cryptés avec une clé WEP, expérience du jour , ..., c'est fou).


J'ai une wanadoo livebox. Elle supporte le chiffrage wap/wep.
Elle est livrée avec un dongle usb en 802.11g. Avec lui, pas de  
problème, on peut fonctionner avec la clé wep.


Avec la carte smc2802w sous windows et les drivers d'origine, je suis  
obligé de mettre hors service la clé de chiffrage, sinon la carte ne se  
connecte pas.


Sous linux, je n'ai pas essayé encore. Mais je ne pense pas que ça doit  
fonctionner mieux que sous win vu que les drivers utilisés par  
ndiswrapper sont ceux de windows


C'est assez gênant car le périphérique ne peut pas être enregistré au  
niveau du routeur, il est donc nécessaire de laisser celui-ci ouvert  
en permanence. Je ne tiens pas particulièrement à servir de fournisseur  
d'accès pour les voisins Le risque reste quand même limité... par  
la porté radio de l'engin qui n'est pas terrible terrible.




Voilà, c'est pas de la pub, c'est juste pour éviter - peut-être -  à
d'autres de s'emmerder avec cette désinformation chronique de
certaines sociétés sur leurs produits.

A+
S.



Jean-Luc


pgp43UckCqlcq.pgp
Description: PGP signature

2.6.8, WiFi et chipset Prism54 -- timeout

[Jean-Luc Coulon (f5ibh)]

Bonsoir,

J'ai acquis une carte SMC 2802W qui est équipée d'un chipset prism et  
qui est supposée fonctionner sous linux.


J'ai déjà fait l'installation sous windows (non sans peine). Elle  
arrive à se conencter à ma livebox mais nécessite pour ça une  
interventino manuelle à chaque fois... mais ce n'est pas le propos. (il  
est d'ailleurs curieux de constater que la livebox utilsie par défaut  
le canal 0... qui n'est pas attribué en France).


Sous linux 2.6.8, le firmware récupéré sur prisl54.org se charge bien  
mais au moment d'intialiser la carte, k'ai une floppée de messages  
d'erreur:

eth0: device soft reset timed out
eth0: timeout waiting for mgmt response
[ plusieurs fois ]
eth0: mgmt tx queue is still fill
[ plusieurs fois ]

J'ai ensuite essayé ave cla rc4 de 2.6.9, on ne sait jamais... Même  
résultat (si l'on peut dire).


J'ai ensuite installé un 2.4.28-pre4 (il y a un backport du support  
wireless prism54 sur celui-ci). Là les messages sont différents : il se  
plaint de problèmes d'IRQ qui serait trop longue à répondre.


Bref, je ne m'en sors pas.

J'ai googlisé un peu. Je retrouve bien mes messages d'erreurs... amis  
pas de réponse constructive sur le sujet.


Une idée ? Une piste ?

Jean-Luc


pgpmrP1zFM2Ej.pgp
Description: PGP signature

Re: 2.6.8, WiFi et chipset Prism54 -- timeout

[François TOURDE]

Le 12705ième jour après Epoch,
Jean-Luc Coulon écrivait:

 Bonsoir,

 J'ai acquis une carte SMC 2802W qui est équipée d'un chipset prism et  
 qui est supposée fonctionner sous linux.


[...]

 eth0: device soft reset timed out
 eth0: timeout waiting for mgmt response
 [ plusieurs fois ]
 eth0: mgmt tx queue is still fill
 [ plusieurs fois ]

J'ai aussi une carte avec le même chipset, et j'ai eu les mêmes
messages d'erreur. J'avoue que je ne sais plus exactement à quel
moment ils ont disparu, si c'est suite à la mise à jour de hotplug ou
lors de mon passage de 2.4.24 à 2.6.5 ...

Pour info, voilà ma version de hotplug:

fermat:~# dpkg -l \*hotplug\*|grep ^ii
ii  hotplug   0.0.20040329-15   Linux Hotplug Scripts

Pour le firmware, par contre, c'est probablement pas le même, mais en
cas j'utilise le isl3890 que j'ai récupéré ... je sais plus où ;)

J'espère que ça te fera avancer.


pgpAJbuLtTnZB.pgp
Description: PGP signature

Re: 2.6.8, WiFi et chipset Prism54 -- timeout

[f5ibh]

On Thu, Oct 14, 2004 at 10:49:35PM +0200, François TOURDE wrote:
 Le 12705ième jour après Epoch,
 Jean-Luc Coulon écrivait:
 
  Bonsoir,
 
  J'ai acquis une carte SMC 2802W qui est équipée d'un chipset prism et  
  qui est supposée fonctionner sous linux.
 
 
 [...]
 
  eth0: device soft reset timed out
  eth0: timeout waiting for mgmt response
  [ plusieurs fois ]
  eth0: mgmt tx queue is still fill
  [ plusieurs fois ]
 
 J'ai aussi une carte avec le même chipset, et j'ai eu les mêmes
 messages d'erreur. J'avoue que je ne sais plus exactement à quel
 moment ils ont disparu, si c'est suite à la mise à jour de hotplug ou
 lors de mon passage de 2.4.24 à 2.6.5 ...

Quelle est votre version de kernel avec lequel la carte focntionne ?

 
 Pour info, voilà ma version de hotplug:
 
 fermat:~# dpkg -l \*hotplug\*|grep ^ii
 ii  hotplug   0.0.20040329-15   Linux Hotplug Scripts

J'ai la même version


 
 Pour le firmware, par contre, c'est probablement pas le même, mais en
 cas j'utilise le isl3890 que j'ai récupéré ... je sais plus où ;)

Oui, ça c'est standard. J el'ai récupéré sur le site prism54.org
Il y a diverses version appellées 1.0.4.3.arm, 1.0.3.0.arm ...
Il faut la renommer en isl3890 et la mettre das /usr/lib/hotplug/firmware

Pourrais-je savoir quel est la somme md5 de votre firmware ?

j'ai essayé :
1f0a68fbe45963f76e525c9789f5609c  1.0.3.0.arm
8bd4310971772a486b9784c77f8a6df9  1.0.4.3.arm
 
 J'espère que ça te fera avancer.

Ca rassure un peu : le dilemne est je garde la carte ou je la retourne ...
La loi donnant 7 jours, il faut que je me dépèche ...

Jean-Luc


signature.asc
Description: Digital signature

Re: 2.6.8, WiFi et chipset Prism54 -- timeout

[François TOURDE]

Le 12705ième jour après Epoch,
Jean-Luc Coulon écrivait:

 Quelle est votre version de kernel avec lequel la carte focntionne ?

Actuellement, avec un 2.6.5 mais je crois (sans être sûr à 100%)
qu'elle marche en 2.6.8

 Pourrais-je savoir quel est la somme md5 de votre firmware ?

 j'ai essayé :
 1f0a68fbe45963f76e525c9789f5609c  1.0.3.0.arm
 8bd4310971772a486b9784c77f8a6df9  1.0.4.3.arm

fermat:~# md5sum /usr/lib/hotplug/firmware/isl3890 
8bd4310971772a486b9784c77f8a6df9  /usr/lib/hotplug/firmware/isl3890

 Ca rassure un peu : le dilemne est je garde la carte ou je la retourne ...
 La loi donnant 7 jours, il faut que je me dépèche ...

J'ai fait aussi vite que j'ai pû ;)

Autres infos éventuellement, je joins un lspci -v pour voir les
conflits ou autres infos.
fermat:~# lspci -v
:00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge 
(rev 04)
Flags: bus master, fast devsel, latency 0
Memory at e800 (32-bit, prefetchable) [size=64M]
Capabilities: [e4] #09 [d104]
Capabilities: [a0] AGP version 2.0

:00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge 
(rev 04) (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, fast devsel, latency 32
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: c000-cfff
Memory behind bridge: fc00-fdff
Prefetchable memory behind bridge: d800-e7ff

:00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02) 
(prog-if 00 [UHCI])
Subsystem: Intel Corp. Latitude C640
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at bf80 [size=32]

:00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02) 
(prog-if 00 [UHCI])
Subsystem: Intel Corp.: Unknown device 4541
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at 1000 [size=32]

:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 42) (prog-if 00 
[Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=10, sec-latency=32
I/O behind bridge: e000-
Memory behind bridge: f400-fbff

:00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02)
Flags: bus master, medium devsel, latency 0

:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) (prog-if 8a 
[Master SecP PriP])
Subsystem: Intel Corp. Latitude C640
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at unassigned
I/O ports at unassigned
I/O ports at unassigned
I/O ports at unassigned
I/O ports at bfa0 [size=16]
[virtual] Memory at 2000 (32-bit, non-prefetchable) [size=1K]

:00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio 
Controller (rev 02)
Subsystem: Cirrus Logic: Unknown device 5959
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at d800 [size=256]
I/O ports at dc80 [size=64]

:00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem Controller (rev 02) 
(prog-if 00 [Generic])
Subsystem: PCTel Inc Dell Inspiron 2100 internal modem
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at d400 [size=256]
I/O ports at dc00 [size=128]

:01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 440 
Go] (rev a3) (prog-if 00 [VGA])
Subsystem: Dell: Unknown device 00d5
Flags: bus master, VGA palette snoop, 66MHz, medium devsel, latency 32, 
IRQ 11
Memory at fc00 (32-bit, non-prefetchable) [size=16M]
Memory at e000 (32-bit, prefetchable) [size=128M]
Memory at dff8 (32-bit, prefetchable) [size=512K]
Expansion ROM at 8000 [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 2.0

:02:00.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] 
(rev 78)
Subsystem: Dell: Unknown device 00d5
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at ec80 [size=128]
Memory at f8fffc00 (32-bit, non-prefetchable) [size=128]
Expansion ROM at f900 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2

:02:01.0 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus 
Controller
Subsystem: Dell: Unknown device 00d5
Flags: bus master, medium devsel, latency 168, IRQ 11
Memory at 20001000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
Memory window 0: 2040-207ff000 (prefetchable)
Memory window 1: 2080-20bff000
I/O window 0: 4000-40ff
I/O window 1: 4400-44ff
16-bit legacy interface ports at 0001

:02:01.1 CardBus bridge: Texas 

pb chassis ASTOR identifié par SCA HSBP M5 provoque des timeout lors du boot!

[Tarik Bendjama]

mBonjour,

 Je suis l'expediteur du message intitulé Installation echoue au début dûe 
au SCSI ! qui n'a pas reçu bcp d'écho, et après plusieurs essais sur 
pratiquemnt toutes le possiiblités des paramètres boot, ainsi que sur la 
configuration matériel, il s'est avéré que le chassis ASTOR sur lequel sont 
installé 2 disques dur Quantum Atlas 10K 9,1 Go de type SCA, et relié çà une 
carte mère N440BX, qui est à l'origine du problème provoquant la boucle :


...
SCSI Host 0 abort reset (pid 9) timeout resetting...
SCSI bus is being reset for host 0 channel 0 ..
sym53c8xx_reset.

Dès que le controleur SCSI (sym53c875) est relié à un disque dur SCSI 
directement et sans passer par le chassis l'installation continue 
normalement, mais moi j'ai besoin que ça marche avec ce chassis!!


Là je suis completement bloqué et je ne sais pas quoi inventer.
merci de m'approter votre aide!

_
MSN Search, le moteur de recherche qui pense comme vous ! 
http://search.msn.fr/worldwide.asp

le chassis ASTOR identifié par SCA HSBP M5 provoque des timeout lors du boot!

[Tarik Bendjama]

Bonjour,

 Je suis l'expediteur du message intitulé Installation echoue au début dûe 
au SCSI ! qui n'a pas reçu bcp d'écho, et après plusieurs essais sur 
pratiquemnt toutes le possiiblités des paramètres boot, ainsi que sur la 
configuration matériel, il s'est avéré que le chassis ASTOR sur lequel sont 
installé 2 disques dur Quantum Atlas 10K 9,1 Go de type SCA, et relié çà une 
carte mère N440BX, qui est à l'origine du problème provoquant la boucle :


...
SCSI Host 0 abort reset (pid 9) timeout resetting...
SCSI bus is being reset for host 0 channel 0 ..
sym53c8xx_reset.

Dès que le controleur SCSI (sym53c875) est relié à un disque dur SCSI 
directement et sans passer par le chassis l'installation continue 
normalement, mais moi j'ai besoin que ça marche avec ce chassis!!


Là je suis completement bloqué et je ne sais pas quoi inventer.
merci de m'approter votre aide!

_
MSN Messenger  http://g.msn.fr/FR1001/866 : dialoguez en direct et 
gratuitement avec vos amis !

wvdial et timeout

[Alain DIDIERJEAN]

J'utilise wvdial pour me connecter à mon FAI et souhaiterai mettre un timeout 
sur la connexion après 300 secondes de non-activité. /etc/wvdial.conf = 

[Dialer Defaults]
ISDN = 0
Modem Type = Analog Modem
Modem = /dev/ttyS0
Baud = 115200
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 S32=34
Dial Command=ATDT
Phone = 0868929898
Username = 0164231015
Password = 09rvanve
New PPPD = yes
Auto DNS = 1 
Auto Reconnect=0
Idle Seconds = 300 
^^
Cette ligne qui fonctionnait parfaitement du temps que j'utilisais SuSE est 
sans effet sous woody !!
j'ai rajouté la dernière ligne dans /etc/ppp/peers/wvdial :
noauth
name wvdial
usepeerdns
idle 300
^^^ Toujours pas de timeout. Je suis distrait et il m'arrive de rester 
connecté 2/3 heures pour rien... Au secours !!


-- 
\\|// - ?
   (o o)
/=oOOO=(_)=OOOo===\

 Alain DIDIERJEAN   Ces mystères nous dépassent
 Feignons d'en être l'organisateur
 

Re: plip et timeout

[Romuald DELAVERGNE]

On Sat, 17 May 2003 16:23:23 +0200
Michel [EMAIL PROTECTED] wrote:

 Il y a toujours des timeouts qui polluent un peu l'affichage , y
 aurait-il un moyen de ne pas les afficher a l'ecran ?
 

En modifiant le source du noyau.

plip et timeout

[Michel]

Bonjour ,

J'utilse un vieux portable ( compaq presario 1260 , K6 333 , 96Mo ram )
que je connecte a mon reseau par plip , notamment pour les upgrades .

Il y a toujours des timeouts qui polluent un peu l'affichage , y
aurait-il un moyen de ne pas les afficher a l'ecran ?

Amicalement

Michel
--

Tuxophiles, bien sur que nous sommes tuxophiles, et winophobes en plus.
Mais il ne faut pas confondre tuxophilie et tuxo-integrisme, l'amalgame
est fait beaucoup trop rapidement par les winophiles-tuxophobes .

Re: Modem Sagem 800 et LCP: timeout sending Config-Requests

[Matthieu Moy]

Jean-Roch SOTTY [EMAIL PROTECTED] writes:

   Ben t'as du courage ;-) le driver eagle (http://eagle-usb.fr.st) est 
 bien plus
 stable (et entièrement libre !) mais bon ça devrait marcher aussi.

En effet : Ca y est, ca marche ! 

Merci,

-- 
Matthieu

Re: Modem Sagem 800 et LCP: timeout sending Config-Requests

[Matthieu Moy]

Jean-Roch SOTTY [EMAIL PROTECTED] writes:

 Matthieu Moy a écrit :
 Bonjour,
 J'eessaye déséspérément de faire marcher  mon modem Sagem Fast 800
 sur ma Debian  stable. J'utilise les  modems fournis sur  le CD du
 kit de connexion
  de Free.
   Ben t'as du courage ;-) le driver eagle (http://eagle-usb.fr.st) est 
 bien plus
 stable (et entièrement libre !) mais bon ça devrait marcher aussi.

En fait, je me disais que  les machins à télécharger, je ferais plutôt
/après/ avoir une connexion haut débit ;-)

C'est  étrange qu'ils  mettent  des drivers  de  merde sur  le CD  (je
confirme, ils freezent régulièrement  ma machine, le programme adictrl
est écrit  avec les  pieds, il faut  utiliser gdb pour  comprendre que
Segmentation  fault veut dire  tanto Vous  n'êtes pas  root, tanto
Votre noyau n'utilise pas devfs ...) alors qu'ils auraient pu mettre
un driver libre ...

   C'est bizarre ... pppoa se lance à peine. tu as esssayé d'utilisé pppoe 
 (le
 [EMAIL PROTECTED] 800 bien qu'usb supporte les 2) De plus le pppoa du cd 
 contient
 une erreur : il sature la ram ...

J'ai  pas essayé.  J'avais cru  comprendre  que pppoe  était pour  les
modems ethernet. 

   Sinon j'avais eut ce genre de problème sans vraiment
 comprendre de quoi il en retournait :-(
 Un problème de conf ppp due à mon ancien modem 56k :-/

J'ai  toujours mon  modem  56K  en effet.  J'ai  essayé en  supprimant
complètement le répertoire  /etc/ppp et en reprennant celui  du CD. Je
vais essayer en débranchant complètement mon modem 56k.

Bon, je vais voire ce que donnent les drivers eagle. 

Merci,

-- 
Matthieu

Modem Sagem 800 et LCP: timeout sending Config-Requests

[Matthieu Moy]

Bonjour,

J'eessaye déséspérément de faire marcher  mon modem Sagem Fast 800 sur
ma Debian  stable. J'utilise les  modems fournis sur  le CD du  kit de
connexion de Free. 

Après  petites  modifs dans  le  Makefile  du  driver (utilisation  de
gcc-3.0, et minusculisation  d'un '-C' passé en option  à install), le
driver compile. Une recompilation de noyau avec l'option devfs activée
pour l'usb, mon modem semble être reconu :

# adictrl
+++OpenDriver
File handle=3
Opened it
Trying to read OPTN0
Option OPTN0 assigned value 0x80020066

[ ... ]

--ConvertSRecordsToBinary: pDst=4023f008, pFw=b93c
--ConvertSRecordsToBinary
End DSP processing. DspSize=7dda8
# cat /proc/adimodem

Analog Devices USB ADSL Modem Status Display
-
Tx Rate 0x00a0 Rx Rate 0x0260 Crc 0x
FEC 0x Margin 0x0029 Atten 0x0034
VID-CPE 0x VID-CO 0x001c HEC 0x
VPI 0x0008 VCI 0x0023 Delin GOOD
Cells Rx 0x Cells Tx 0x00a3
Pkts Rx 0x Pkts Tx 0x
Modem is operational

# ifconfig -a
ADIModem Link encap:Ethernet HWaddr 00:60:4C:10:B0:C9 
  inet addr:192.168.60.30 Bcast:192.168.60.255
  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:3 errors:133 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100 
  RX bytes:0 (0.0 b) TX bytes:330 (330.0 b)
[ ... ]

Est-ce que je peux en déduire que mon modem est correctement reconnu ? 

Maintenant,   voilà   les   problèmes   :  J'ai   édité   le   fichier
/etc/ppp/peers/dsl-provider et  /etc/ppp/{ch|p}ap-secrets, et tente un
pon dsl-provider. Un plog -f me donne ceci :

May 2 23:38:25 chezmoi pppd[984]: pppd 2.4.1 started by root, uid 0
May 2 23:38:25 chezmoi pppd[984]: using channel 16
May 2 23:38:25 chezmoi pppd[984]: Using interface ppp0
May 2 23:38:25 chezmoi pppd[984]: Connect: ppp0 -- /dev/pts/4
May 2 23:38:26 chezmoi pppd[984]: sent [LCP ConfReq id=0x1 mru 1492 magic 
0x906be845]
May 2 23:38:56 chezmoi pppd[984]: LCP: timeout sending Config-Requests 
May 2 23:38:56 chezmoi pppd[984]: Connection terminated. 
May 2 23:38:56 chezmoi pppd[984]: Waiting for 1 child processes... 
May 2 23:38:56 chezmoi pppd[984]: script pppoa, pid 985
May  2 23:38:56 chezmoi  pppd[984]: Script  pppoa finished  (pid 985),
status = 0x1
May 2 23:38:56 chezmoi pppd[984]: Exit. 

Pendant la tentative de connexion, ifconfig -a me montre une interface
ppp0, mais  elle disparait tout de  suite, et c'est  le fameux message
LCP:  timeout sending  Config-Requests.  Niet, pas  de connexion.  A
aucun moment, ping ou traceroute ne marchent. 

Est-ce que quelqu'un a une idée sur la question ? 

Est-ce que ça peut venir d'un mauvais driver ? 

Est ce que c'est un truc con dans un fichier de config ? 

Merci,

-- 
Matthieu

Re: Modem Sagem 800 et LCP: timeout sending Config-Requests

[zulian]

Le Samedi 3 Mai 2003 00:00, Matthieu Moy a écrit :
 Bonjour,

 J'eessaye déséspérément de faire marcher  mon modem Sagem Fast 800 sur
 ma Debian  stable. J'utilise les  modems fournis sur  le CD du  kit de
 connexion de Free.

Essayes plutot le driver eagle-1.0.3

à http://eagle-usb.fr.st/ + plein de doc et ils sont trés sympas.


-- 
Frédéric ZULIAN
F1sxo

Re: Modem Sagem 800 et LCP: timeout sending Config-Requests

[Jean-Roch SOTTY]

Matthieu Moy a écrit :

Bonjour,

J'eessaye déséspérément de faire marcher  mon modem Sagem Fast 800 sur ma 
Debian  stable. J'utilise les  modems fournis sur  le CD du  kit de connexion

 de Free.

Ben t'as du courage ;-) le driver eagle (http://eagle-usb.fr.st) est 
bien plus
stable (et entièrement libre !) mais bon ça devrait marcher aussi.


cat /proc/adimodem

 Modem is operational
 Est-ce que je peux en déduire que mon modem est correctement reconnu ?
	Oui, et qu'il est près à se connecter (les 2 leds doiventêtre allumées). Donc 
c'est bien un problème de ppp.


Maintenant,   voilà   les   problèmes   :  J'ai   édité   le   fichier 
/etc/ppp/peers/dsl-provider et  /etc/ppp/{ch|p}ap-secrets, et tente un pon 
dsl-provider. Un plog -f me donne ceci :

C'est bizarre ... pppoa se lance à peine. tu as esssayé d'utilisé pppoe 
(le
[EMAIL PROTECTED] 800 bien qu'usb supporte les 2) De plus le pppoa du cd contient une erreur 
: il sature la ram ...


	Sinon j'avais eut ce genre de problème sans vraiment comprendre de quoi il en 
retournait :-(

Un problème de conf ppp due à mon ancien modem 56k :-/

Pendant la tentative de connexion, ifconfig -a me montre une interface ppp0, 
mais  elle disparait tout de  suite, et c'est  le fameux message LCP: 
timeout sending  Config-Requests.  Niet, pas  de connexion.  A aucun moment,

 ping ou traceroute ne marchent.



Est-ce que ça peut venir d'un mauvais driver ?

je ne pense pas : il semble marcher.

Est ce que c'est un truc con dans un fichier de config ?

oui de ppp donc : de toutes façon il n'y a que 3 fichiers à verfier 
dans /etc/ppp/
options, pap-secrets et peers/ton-provider

J'insiste le eagle est vraiment plus intéressant : du détare, make 
clean, make,
make install, il te demande ton login/pass et ça roule :-) pour le reste voir
sur cette même liste
http://lists.debian.org/debian-user-french/2003/debian-user-french-200304/msg01180.html

Jean-Roch

probleme de timeout sur sendmail

[kamel latrach]

excusez moi pour ce hors sujet.
J'ai un ami avec une petite laison qui se prend des time-out de temps en
temps lorsqu'il veut checker ses mails sur un serveur sendmail ( log
=-ERR POP timeout from).
Savez vous comment augmenter ce paramètre au niveau du serveur 
?
merci

kamel latrach 
Network Administrator
e-Qual - Avenue du Futuroscope -
Arobase 2, Téléport 1 
86360 Chasseneuil du Poitou - FRANCE

__o 

_`\,_ 
..(_)/ (_) 

Re: Petit problme de timeout pour monter un partage NFS

[Davy Gigan]

On Sat, 26 Oct 2002 19:43:10 +0200
Aurélien Le Provost [EMAIL PROTECTED] wrote:

Oct 25 15:09:52 chassis kernel: portmap: server localhost not
responding, timed out
   Ta machine essaye de contacter ton serveur portmap, lequel a priori
   n'est pas lancé vu le message d'erreur.
 Euh... Et pourquoi ça ? Il devrait être lancé au démarrage, non ?

Plusieurs moyens de savoir si le daemon tourne :

  ~# rpcinfo -p localhost
  ~# netstat -apn | grep 111

-- 
Davy Gigan
System  Network Administration  [Please no HTML, I'm not a browser]
University Of Caen (France)   [Pas d'HTML, je ne suis pas un navigateur]

Petit problme de timeout pour monter un partage NFS

[Aurlien Le Provost]

Salut

Soit un serveur woody avec un partage NFS, avec nfs-kernel-server et 
tout ce qui va bien dans le noyau. Tout est, a priori, bien configuré, 
puisque ça marche sans problèmes avec 4 clients woody.

Soit ma machine sous sarge. Quand je veux monter ce partage, soit ça 
marche très bien, soit ça marche aussi, mais il se passe deux ou trois 
minutes avant que la commande ne rende la main. C'est aléatoire...

Dans /var/log/messages :

Oct 25 15:09:52 chassis kernel: portmap: server localhost not 
responding, timed out
Oct 25 15:11:32 chassis kernel: portmap: server localhost not 
responding, timed out
Oct 25 15:11:32 chassis kernel: lockd_up: makesock failed, error=-5
Oct 25 15:13:12 chassis kernel: portmap: server localhost not 
responding, timed out

Pareil dans /var/log/syslog.

Question : pourquoi ma machine cherche-t-elle à contacter un serveur 
sur localhost (qui se ping très bien au passage, le réseau est a priori 
bien configuré aussi) alors que je lui demande de monter un partage qui 
se trouve sur le serveur ?

@+

Re: Petit problme de timeout pour monter un partage NFS

[Davy Gigan]

 Oct 25 15:09:52 chassis kernel: portmap: server localhost not 
 responding, timed out
 Oct 25 15:11:32 chassis kernel: lockd_up: makesock failed, error=-5

Ta machine essaye de contacter ton serveur portmap, lequel a priori
n'est pas lancé vu le message d'erreur. Elle fait cela pour connaitre
le port sur lequel tourne ton lockd, et comme y'a pas de réponse, la
connexion sur ton lockd n'est pas possible.

 Question : pourquoi ma machine cherche-t-elle à contacter un serveur 
 sur localhost (qui se ping très bien au passage, le réseau est a priori 
 bien configuré aussi) alors que je lui demande de monter un partage qui 
 se trouve sur le serveur ?


-- 
Davy Gigan
System  Network Administration  [Please no HTML, I'm not a browser]
University Of Caen (France)   [Pas d'HTML, je ne suis pas un navigateur]

Re: Petit problme de timeout pour monter un partage NFS

[Davy Gigan]

  Oct 25 15:09:52 chassis kernel: portmap: server localhost not 
  responding, timed out

 Ta machine essaye de contacter ton serveur portmap, lequel a priori
 n'est pas lancé vu le message d'erreur.

Euh ... Désolé, j'oublie le plus important : il faut que tu lances le
portmap, mais tu avais deviné ?

# /etc/init.d/portmap start


-- 
Davy Gigan
System  Network Administration  [Please no HTML, I'm not a browser]
University Of Caen (France)   [Pas d'HTML, je ne suis pas un navigateur]

Re: Petit problme de timeout pour monter un partage NFS

[Aurlien Le Provost]

Salut

Le Samedi 26 Octobre 2002 14:10, Davy Gigan a écrit :

   Oct 25 15:09:52 chassis kernel: portmap: server localhost not
   responding, timed out
 
  Ta machine essaye de contacter ton serveur portmap, lequel a priori
  n'est pas lancé vu le message d'erreur.

Euh... Et pourquoi ça ? Il devrait être lancé au démarrage, non ?

@+

[HS] copie cd foireux, timeout qui ne vient pas, impossibilite de killer ...

[Okki]

Salut

Voilà, quand je tente de copier un fichier à partir d'un CD foireux,
j'ai droit au message suivant

Aug  9 22:43:10 darthvader kernel: SCSI host 1 abort (pid 185041) timed
out - resetting
Aug  9 22:43:10 darthvader kernel: SCSI bus is being reset for host 1
channel 0.
Aug  9 22:43:10 darthvader kernel: ncr53c8xx_reset: pid=185041
reset_flags=2 serial_number=185041 serial_number_at_timeout=185041


Là dessus, le cp se bloque et impossibilité de faire un kill -9 ... il
finit par timeouter au bout d'un certain temps ... une heure, une
semaine ... entre temps, il continue de tenter de lire, ca m'énerve,
c'est lourd, et j'aurai pas envie qu'il bousille mon lecteur pour de
telles conneries ... y aurait pas moyen de configurer le kernel ou autre
pour lui dire voilà, t'arrives pas à copier, donc tu fais pas chier, tu
kill le process foireux et tu restes zen ...

Qu'il m'affiche le message une ou deux fois ca va, j'ai compris ... mais
au delà c'est non seulement lourd, mais complètement inutile. Notons au
passage que le lecteur n'a rien à voir, ca me l'a déjà fait sur plein de
lecteurs, et celui là c'est un UltraPleX 40x de chez Plextor acheté ce
matin ... Par contre, le controlleur c'est une merde à 50 balles ... ca
pourrait venir de lui ?

D'ailleurs, pour en revenir aux CD, ceux sont des Verbatim, pas la
moindre rayure, eraflure, poussière ou autre ... ils sont comme neuf.
Pourtant, vers la fin du CD (un CD sur cinquante), il me sort ca ... Ca
ne vient pas non plus du graveur, à mon avis. Un PlexWriter 12x SCSI de
chez Mr Plextor, acheté il y a peu (et je lui fait confiance :)

Si quelqu'un a quelques idées, je suis preneur
A+

Re: [HS] copie cd foireux, timeout qui ne vient pas, impossibilite de killer ...

[Raphaël SurcouF]

Le ven 09/08/2002 à 22:54, Okki a écrit :
 
 Qu'il m'affiche le message une ou deux fois ca va, j'ai compris ... mais
 au delà c'est non seulement lourd, mais complètement inutile. Notons au
 passage que le lecteur n'a rien à voir, ca me l'a déjà fait sur plein de
 lecteurs, et celui là c'est un UltraPleX 40x de chez Plextor acheté ce
 matin ... Par contre, le controlleur c'est une merde à 50 balles ... ca
 pourrait venir de lui ?
 
 D'ailleurs, pour en revenir aux CD, ceux sont des Verbatim, pas la
 moindre rayure, eraflure, poussière ou autre ... ils sont comme neuf.
 Pourtant, vers la fin du CD (un CD sur cinquante), il me sort ca ... Ca
 ne vient pas non plus du graveur, à mon avis. Un PlexWriter 12x SCSI de
 chez Mr Plextor, acheté il y a peu (et je lui fait confiance :)

Je dirais de vérifier ta chaîne SCSI au complet, c'est-à-dire vérifier
les différentes terminaisons, aussi bien physiques que celles pouvant
être présentes dans les différents périphériques et le contrôleur.

Amicalement,

-- 
Raphaël SurcouF
[EMAIL PROTECTED]

Probleme résolu, merci à tous ! [aic7xxx + scsi : aborting command due to timeout]

[Nicolas Massé]

Bonjour,

J'ai enfin résolu mon problème de carte SCSI, qui en fait était purement 
matériel !
C'était un problème de terminaisons !
Ma carte SCSI ncr53c8xx comportait une terminaison physique (un bouchon) ET 
un disque dur avec une terminaison activée par un jumper. Et enfin ma carte 
SCSI aic7xxx ne comportait pas de terminaisons du tout !
J'ai résolu le problème :
- en enlevant la carte aic7xxx
- en mettant le scanner, le lecteur CD et le lecteur DAT sur la 
carte ncr53c8xx
- en désactivant la terminaison du disque dur fautif !

Ce problême m'a fait prendre conscience de l'importance des messages 
d'erreur de linux, les camoufler par une interface graphique (comme le fait 
windows) ne résoud en rien le probleme !

Je remercie donc toutes les personnes qui, depuis un mois, m'ont 
accompagné dans cette formidable aventure qu'est linux...

Encore merci !  

 J'ai un gros problême avec ma carte SCSI, lorsque j'essaye d'accéder à un 
 périphérique situé sur ma carte SCSI, j'obtiens très souvent :
   serveur:~# mount /cdrom
   scsi : aborting command due to timeout : pid 5991, scsi0, channel 0, id 
 3, lun 0
   Test Unit Ready 00 00 00 00 00
   SCSI host 0 abort (pid 5991) timed out - resetting
   SCSI bus is being reset for host 0 channel 0.

 Ma configuration : Machine (P120) entièrement SCSI :
   - une carte ncr53c8xx (scsi1) avec 2 disques dur
   - une carte aic7xxx (scsi0) avec un scanner, lecteur CD et un lecteur 
 DAT

 Quelques précisions :
   - J'utilise 2 cartes SCSI car du jour au lendemain, la carte ncr53c8xx 
 à refusé de reconnaitre autre chose  que les deux disques durs !
   - La carte aic7xxx est la carte adaptec sans bios vendue dans toutes 
 les boutiques info à 400 FF

 J'ai quelques doutes :
   - Serait-ce un problême d'IRQ partagés (Cartes PCI) ?
   - Ou peut-être un problême de terminaisons ?

 Merci d'avance !

Re: =?us-ascii?Q?Probleme r=E9solu, merci =E0 tous ! [aic7xxx + scsi : aborting?= =?us-ascii?Q? command due to timeout]?=

[Erwan David]

Le Wed 31/07/2002, =?us-ascii?Q?Nicolas Mass=E9?= disait
 Bonjour,
   
 J'ai enfin r?solu mon probl?me de carte SCSI, qui en fait ?tait
 purement mat?riel !

Maintenant tu peux régler les problèmes de ton mailer : tu annonces de
l'us-ascii et tu envoie des caractères accentués. Ça passe pas.

-- 
Erwan

aic7xxx + scsi : aborting command due to timeout

[Nicolas Massé]

Bonjour,

J'ai un gros problême avec ma carte SCSI, lorsque j'essaye d'accéder à un 
périphérique situé sur ma carte SCSI, j'obtiens très souvent :
serveur:~# mount /cdrom
scsi : aborting command due to timeout : pid 5991, scsi0, channel 0, id 
3, lun 0
 Test Unit Ready 00 00 00 00 00
SCSI host 0 abort (pid 5991) timed out - resetting
SCSI bus is being reset for host 0 channel 0.

Ma configuration : Machine (P120) entièrement SCSI :
- une carte ncr53c8xx (scsi1) avec 2 disques dur
- une carte aic7xxx (scsi0) avec un scanner, lecteur CD et un lecteur 
DAT

Quelques précisions :
- J'utilise 2 cartes SCSI car du jour au lendemain, la carte ncr53c8xx 
à refusé de reconnaitre autre chose que les deux disques durs !
- La carte aic7xxx est la carte adaptec sans bios vendue dans toutes 
les boutiques info à 400 FF

J'ai quelques doutes :
- Serait-ce un problême d'IRQ partagés (Cartes PCI) ?
- Ou peut-être un problême de terminaisons ?

Merci d'avance !




PS : Cette configuration marchait parfaitement sous W[censuré] NT ...




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: aic7xxx + scsi : aborting command due to timeout

[Raphaël SurcouF]

Le lun 29/07/2002 à 12:10, =?us-ascii?Q?Nicolas Mass=E9?= a écrit :
 Bonjour,
 
 J'ai un gros problême avec ma carte SCSI, lorsque j'essaye d'accéder à un 
 périphérique situé sur ma carte SCSI, j'obtiens très souvent :
   serveur:~# mount /cdrom
   scsi : aborting command due to timeout : pid 5991, scsi0, channel 0, id 
 3, lun 0
Test Unit Ready 00 00 00 00 00
   SCSI host 0 abort (pid 5991) timed out - resetting
   SCSI bus is being reset for host 0 channel 0.
 
 Ma configuration : Machine (P120) entièrement SCSI :
   - une carte ncr53c8xx (scsi1) avec 2 disques dur
   - une carte aic7xxx (scsi0) avec un scanner, lecteur CD et un lecteur 
 DAT
 
 Quelques précisions :
   - J'utilise 2 cartes SCSI car du jour au lendemain, la carte ncr53c8xx 
 à refusé de reconnaitre autre chose que les deux disques durs !
   - La carte aic7xxx est la carte adaptec sans bios vendue dans toutes 
 les boutiques info à 400 FF
 
 J'ai quelques doutes :
   - Serait-ce un problême d'IRQ partagés (Cartes PCI) ?
   - Ou peut-être un problême de terminaisons ?

Vérifies toutes tes terminaisons, sachant que les cartes peuvent en
avoir une en interne. Quant au problème éventuel d'IRQ, si les deux
cartes ont un port PCI d'écart, je ne vois pas de problèmes.
 
 PS : Cette configuration marchait parfaitement sous W[censuré] NT ...

Tu peux dire Windows en toutes lettres, mais que ça fonctionne sous ce
système ne prouve rien car il a trop tendance à tout rendre si
transparent que même ces bêtes erreurs ne se voient plus.

A bientôt !

-- 
Raphaël SurcouF 
[EMAIL PROTECTED]
#debianfr @ Undernet.org


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: disque timeout [Re: Copie de disque...]

[Eric Dillenseger]

On Mon, Jun 24, 2002 at 02:21:43AM +0200, jeremy KUHN wrote:
 j'ai un serveur qui me fait des timeout egalement et je sais pas d'ou ca 
 pourrais provenir, d'apres les logs ce serait du a un recover qui aurait 
 mal tourné, mais ma carte scsi me dis également qu'il y a un probleme au 
 demarrage.
 
 Est-ce que ce genre de problemes viennent effectivement du disque??
 
Pas sûr, si tu cherches un peu sur le net, tu verra qu'il peut y avoir
plusieures causes.
Pour ma part, c'était un disque Maxtor 6.5Go IDE ATA66.
Le disque avait quelquechose comme 3ans passés.
En install standard, aucun problème. En revanche, dès que je compilais
le kernel en incluant le support UDMA qui va bien avec ma carte mère,
le moindre accès disque trop important provoquais le message suivant:
kernel: hda: timeout waiting for DMA 
kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14 
kernel: hda: irq timeout: status=0x58 { DriveReady SeekComplete 
DataRequest } 
kernel: hda: Drive not ready for command
Et la led d'activité restait allumée ~10sec.
Après recherches sur le net j'ai vu que ça pouvais venir:
1-d'une mauvaise gestion de l'UDMA par le controleur disque
2-défaillance du disque
3-magie voodoo
Ne croyant pas trop à la dernière et ayant constaté que c'était le seul
disque de ce modèle à avoir le problème, me suis payé un IBM 40Go
ATA100. (à 101EUR c'est donné)
Plus aucun problème.
Par contre, d'ici à ce que tu décide de changer le disque (ou rester en
l'étât), n'oublie pas de sauvegarder les données importantes, on sait
jamais.
-- 
/*--
assert(cafeine  50 * EXPRESSO); // Lethal dose? 
brain += cafeine;
--*/


pgpNRDwEwunVn.pgp
Description: PGP signature

disque timeout [Re: Copie de disque...]

[jeremy KUHN]

j'ai un serveur qui me fait des timeout egalement et je sais pas d'ou ca 
pourrais provenir, d'apres les logs ce serait du a un recover qui aurait 
mal tourné, mais ma carte scsi me dis également qu'il y a un probleme au 
demarrage.


Est-ce que ce genre de problemes viennent effectivement du disque??

Eric Dillenseger wrote:


On Sun, Jun 23, 2002 at 09:34:10PM +0200, Michel Parlebas wrote:
 


-

Ma passerelle Linux se trouve ? l'?troit avec le disque dur actuel.

Quelle est la meilleure m?thode pour transf?rer son contenu sur un
disque plus important sans rien perdre des pr?cieuses donn?es ?...
   


J'ai effectué la manip il y a 2 jours à cause d'un disque qui faisait
beaucoup de timeouts. Pour ce faire, suis à la lettre le 'Hard Disk
upgrade mini Howto'
(http://linux.uhp-nancy.fr/HOWTOFRENCH/mini/Hard-disk-upgrade/Hard-disk-upgrade.html)
Avec cette méthode, ca à fonctionné sans aucun problème.
 


--
MP


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]


   



 






--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

timeout

[frederic . zulian]

Bonjour,


Sur un reseau ax25, j'accede à un serveur lent, ping  à 1s,  les
differents navigateurs, et mailers que j'ai essayer ne me permettent pas
de charger mes pages ou de recuperer mon courrier et me donnent
regulierement des timeout. 

Il doit bien avoir une possibilité de configurer cela mais ou ?



Frederic