Commande ps et tri par rapport à "etimes" qui ne semble pas fonctionner...
10 réponses
Francois Lafont
Bonjour,
Je suis sous une Debian Wheezy à jour et j'essaye de trier
la sortie d'une commande ps par rapport au temps écoulé des
processus (le elapsed time). J'utilise le champ "etimes"
(avec un "s" à la fin) pour avoir le temps en secondes.
Ensuite, d'après la page man, je peux classer la sortie par
rapport à ce champ avec "k etimes" ou "k -etimes" (avec le
moins le classement est inversé). Seulement, ça ne semble
pas fonctionner. Que je mette "k etimes" ou "k -etimes",
j'ai le même classement :
En revanche, si je classe avec "etime" (sans le "s" !) qui correspond
aussi au ELAPSED time mais exprimé en minutes, heures etc., suivant
la présence ou pas du moins, j'ai bien un classement inversé :
N'y aurait-il pas un bug de ps au niveau du classement via "etimes"
par hasard ? Constatez-vous la même chose sur votre Linux ?
En fait, ça semble plus grave que ça encore. Sur un autre serveur
sous Wheezy aussi et avec pas mal de processus, le classement via
"etimes" ne se fait pas du tout (désolé c'est un peu long mais ça
se lit vite) :
le 04/08/2015 à 20:29, Francois Lafont a écrit dans le message <55c104a6$0$3183$ :
N'y aurait-il pas un bug de ps au niveau du classement via "etimes" par hasard ?
Je pense que c'est le cas.
Constatez-vous la même chose sur votre Linux ?
Oui, avec procps-ng version 3.3.10 (Arch Linux).
-- Benoit Izac
Francois Lafont
Bonsoir,
On 04/08/2015 21:43, Benoit Izac wrote:
N'y aurait-il pas un bug de ps au niveau du classement via "etimes" par hasard ?
Je pense que c'est le cas.
Constatez-vous la même chose sur votre Linux ?
Oui, avec procps-ng version 3.3.10 (Arch Linux).
Ah, ok. Merci pour l'info Benoît.
Du coup, je pense que je vais faire un bug report chez Debian. Sur ma Wheezy, le paquet contenant /bin/ps s'appelle "procps" et la version du paquet est 3.3.3. Sur une Jessie, c'est 3.3.9, donc une version encore inférieure à la tienne.
François Lafont
PS: c'est terrible les bugs, ça peut vraiment faire perdre pas mal de temps. Là, cette bêtise m'a coûté au moins 3 bonnes heures. ;)
Bonsoir,
On 04/08/2015 21:43, Benoit Izac wrote:
N'y aurait-il pas un bug de ps au niveau du classement via "etimes"
par hasard ?
Je pense que c'est le cas.
Constatez-vous la même chose sur votre Linux ?
Oui, avec procps-ng version 3.3.10 (Arch Linux).
Ah, ok. Merci pour l'info Benoît.
Du coup, je pense que je vais faire un bug report chez Debian.
Sur ma Wheezy, le paquet contenant /bin/ps s'appelle "procps"
et la version du paquet est 3.3.3. Sur une Jessie, c'est 3.3.9,
donc une version encore inférieure à la tienne.
François Lafont
PS: c'est terrible les bugs, ça peut vraiment faire perdre pas
mal de temps. Là, cette bêtise m'a coûté au moins 3 bonnes heures. ;)
N'y aurait-il pas un bug de ps au niveau du classement via "etimes" par hasard ?
Je pense que c'est le cas.
Constatez-vous la même chose sur votre Linux ?
Oui, avec procps-ng version 3.3.10 (Arch Linux).
Ah, ok. Merci pour l'info Benoît.
Du coup, je pense que je vais faire un bug report chez Debian. Sur ma Wheezy, le paquet contenant /bin/ps s'appelle "procps" et la version du paquet est 3.3.3. Sur une Jessie, c'est 3.3.9, donc une version encore inférieure à la tienne.
François Lafont
PS: c'est terrible les bugs, ça peut vraiment faire perdre pas mal de temps. Là, cette bêtise m'a coûté au moins 3 bonnes heures. ;)
Benoit Izac
Dans le message , le 04/08/2015 à 21:43, j'ai écrit :
Bonjour,
le 04/08/2015 à 20:29, Francois Lafont a écrit dans le message <55c104a6$0$3183$ :
N'y aurait-il pas un bug de ps au niveau du classement via "etimes" par hasard ?
Je pense que c'est le cas.
Après un coup d'oeil rapide dans les sources, je pense que c'est peut-être voulu (ps/output.c) :
Donc sr_nop qui veut sans doute dire que c'est non implémenté.
Ah, donc ça ne serait pas un bug alors ? Tout au plus une page man incomplète ?
Je pense que ça pourrait être remplacé par sr_etime.
J'ai tenté le coup via les sources du paquet Debian "procps". J'ai juste patché en effectuant le remplacement que tu indiques et, après une compilation réussie, je constate toujours le « bug ».
-- François Lafont
On 04/08/2015 22:02, Benoit Izac wrote:
Après un coup d'oeil rapide dans les sources, je pense que c'est
peut-être voulu (ps/output.c) :
Donc sr_nop qui veut sans doute dire que c'est non implémenté.
Ah, donc ça ne serait pas un bug alors ? Tout au plus une page man incomplète ?
Je pense que ça pourrait être remplacé par sr_etime.
J'ai tenté le coup via les sources du paquet Debian "procps".
J'ai juste patché en effectuant le remplacement que tu indiques
et, après une compilation réussie, je constate toujours le « bug ».
Donc sr_nop qui veut sans doute dire que c'est non implémenté.
Ah, donc ça ne serait pas un bug alors ? Tout au plus une page man incomplète ?
Je pense que ça pourrait être remplacé par sr_etime.
J'ai tenté le coup via les sources du paquet Debian "procps". J'ai juste patché en effectuant le remplacement que tu indiques et, après une compilation réussie, je constate toujours le « bug ».
-- François Lafont
Benoit Izac
Bonjour,
le 04/08/2015 à 23:02, Francois Lafont a écrit dans le message <55c12856$0$3330$ :
Je pense que ça pourrait être remplacé par sr_etime.
J'ai tenté le coup via les sources du paquet Debian "procps". J'ai juste patché en effectuant le remplacement que tu indiques et, après une compilation réussie, je constate toujours le « bug ».
Pas moi :
% ps o etimes,pid k +etimes | head -n 5 ELAPSED PID 17985 673 17985 674 17985 675 17985 676 % ./pscommand o etimes,pid k +etimes | head -n 5 ELAPSED PID 0 23092 0 23093 140 22880 17627 1192
-- Benoit Izac
Bonjour,
le 04/08/2015 à 23:02, Francois Lafont a écrit dans le message
<55c12856$0$3330$426a74cc@news.free.fr> :
Je pense que ça pourrait être remplacé par sr_etime.
J'ai tenté le coup via les sources du paquet Debian "procps".
J'ai juste patché en effectuant le remplacement que tu indiques
et, après une compilation réussie, je constate toujours le « bug ».
Pas moi :
% ps o etimes,pid k +etimes | head -n 5
ELAPSED PID
17985 673
17985 674
17985 675
17985 676
% ./pscommand o etimes,pid k +etimes | head -n 5
ELAPSED PID
0 23092
0 23093
140 22880
17627 1192
le 04/08/2015 à 23:02, Francois Lafont a écrit dans le message <55c12856$0$3330$ :
Je pense que ça pourrait être remplacé par sr_etime.
J'ai tenté le coup via les sources du paquet Debian "procps". J'ai juste patché en effectuant le remplacement que tu indiques et, après une compilation réussie, je constate toujours le « bug ».
Pas moi :
% ps o etimes,pid k +etimes | head -n 5 ELAPSED PID 17985 673 17985 674 17985 675 17985 676 % ./pscommand o etimes,pid k +etimes | head -n 5 ELAPSED PID 0 23092 0 23093 140 22880 17627 1192
-- Benoit Izac
Francois Lafont
On 04/08/2015 23:27, Benoit Izac wrote:
J'ai tenté le coup via les sources du paquet Debian "procps". J'ai juste patché en effectuant le remplacement que tu indiques et, après une compilation réussie, je constate toujours le « bug ».
Pas moi :
% ps o etimes,pid k +etimes | head -n 5 ELAPSED PID 17985 673 17985 674 17985 675 17985 676 % ./pscommand o etimes,pid k +etimes | head -n 5 ELAPSED PID 0 23092 0 23093 140 22880 17627 1192
Ça doit être lié à la version upstream du programme plus récent dans ton cas que sur ma Wheezy. Sur ma Wheezy "procps" est en version 3.3.3 et, via les sources Debian en appliquant « ton » patch la compilation se fait sans souci mais sans résultat au bout du compte.
J'ai testé alors sur une Debian Jessie où "procps" est en version 3.3.9 et là, effectivement, une fois patché et compilé[1] on retrouve bien un bon classement avec "k etimes" au niveau de la sortie de la commande ps.
Bref, je vais quand même faire un bug report et puis voilà. ;) Merci pour ton aide Benoît.
François Lafont
[1] non sans avoir perdu du temps (encore) sur le fait qu'au départ la compilation sous Jessie ne passait juste pas (avec ou sans patch) à cause de tests qui plantaient. Et il s'avère que ça aussi c'est un petit bug du paquet référencé ici :
Pour avoir une compilation qui aboutisse, j'ai dû « overrider » dh_auto_test dans le fichier debian/rules pour lui dire de ne rien faire. ;)
On 04/08/2015 23:27, Benoit Izac wrote:
J'ai tenté le coup via les sources du paquet Debian "procps".
J'ai juste patché en effectuant le remplacement que tu indiques
et, après une compilation réussie, je constate toujours le « bug ».
Pas moi :
% ps o etimes,pid k +etimes | head -n 5
ELAPSED PID
17985 673
17985 674
17985 675
17985 676
% ./pscommand o etimes,pid k +etimes | head -n 5
ELAPSED PID
0 23092
0 23093
140 22880
17627 1192
Ça doit être lié à la version upstream du programme plus récent dans
ton cas que sur ma Wheezy. Sur ma Wheezy "procps" est en version
3.3.3 et, via les sources Debian en appliquant « ton » patch la
compilation se fait sans souci mais sans résultat au bout du compte.
J'ai testé alors sur une Debian Jessie où "procps" est en version 3.3.9
et là, effectivement, une fois patché et compilé[1] on retrouve bien un
bon classement avec "k etimes" au niveau de la sortie de la commande ps.
Bref, je vais quand même faire un bug report et puis voilà. ;)
Merci pour ton aide Benoît.
François Lafont
[1] non sans avoir perdu du temps (encore) sur le fait qu'au départ la
compilation sous Jessie ne passait juste pas (avec ou sans patch) à cause
de tests qui plantaient. Et il s'avère que ça aussi c'est un petit bug du
paquet référencé ici :
J'ai tenté le coup via les sources du paquet Debian "procps". J'ai juste patché en effectuant le remplacement que tu indiques et, après une compilation réussie, je constate toujours le « bug ».
Pas moi :
% ps o etimes,pid k +etimes | head -n 5 ELAPSED PID 17985 673 17985 674 17985 675 17985 676 % ./pscommand o etimes,pid k +etimes | head -n 5 ELAPSED PID 0 23092 0 23093 140 22880 17627 1192
Ça doit être lié à la version upstream du programme plus récent dans ton cas que sur ma Wheezy. Sur ma Wheezy "procps" est en version 3.3.3 et, via les sources Debian en appliquant « ton » patch la compilation se fait sans souci mais sans résultat au bout du compte.
J'ai testé alors sur une Debian Jessie où "procps" est en version 3.3.9 et là, effectivement, une fois patché et compilé[1] on retrouve bien un bon classement avec "k etimes" au niveau de la sortie de la commande ps.
Bref, je vais quand même faire un bug report et puis voilà. ;) Merci pour ton aide Benoît.
François Lafont
[1] non sans avoir perdu du temps (encore) sur le fait qu'au départ la compilation sous Jessie ne passait juste pas (avec ou sans patch) à cause de tests qui plantaient. Et il s'avère que ça aussi c'est un petit bug du paquet référencé ici :
Le mainteneur m'a expliqué que le paquet mis à jour sera disponible dans Sid (unstable) puis dans Stretch (testing) et ensuite sur Jessie on pourra avoir cette mise à jour du paquet dans les backports uniquement.
Ma question : pourquoi la mise à jour (le petit patch de rien du tout) n'est pas disponible directement dans Jessie (la distribution stable) ? J'imagine que c'est la politique Debian qui veut cela mais pourquoi précisément ? Sur la distribution stable de Debian, seules les mises à jour dites « de sécurité » sont appliquées, c'est ça ?
-- François Lafont
Bonjour à tous,
Pour info, j'ai fait un bug report et le mainteneur a proposé
un patch qui est, ni plus ni moins, celui que Benoît avait
indiqué. ;)
Voici le bug report : https://bugs.debian.org/cgi-bin/bugreport.cgi?bugy4619
Voici le patch : https://gitlab.com/procps-ng/procps/commit/313f9367397e2f1275186f5384371c9a5e24a8b0
Le mainteneur m'a expliqué que le paquet mis à jour sera
disponible dans Sid (unstable) puis dans Stretch (testing) et
ensuite sur Jessie on pourra avoir cette mise à jour du paquet
dans les backports uniquement.
Ma question : pourquoi la mise à jour (le petit patch de rien
du tout) n'est pas disponible directement dans Jessie (la
distribution stable) ? J'imagine que c'est la politique Debian
qui veut cela mais pourquoi précisément ? Sur la distribution
stable de Debian, seules les mises à jour dites « de sécurité »
sont appliquées, c'est ça ?
Le mainteneur m'a expliqué que le paquet mis à jour sera disponible dans Sid (unstable) puis dans Stretch (testing) et ensuite sur Jessie on pourra avoir cette mise à jour du paquet dans les backports uniquement.
Ma question : pourquoi la mise à jour (le petit patch de rien du tout) n'est pas disponible directement dans Jessie (la distribution stable) ? J'imagine que c'est la politique Debian qui veut cela mais pourquoi précisément ? Sur la distribution stable de Debian, seules les mises à jour dites « de sécurité » sont appliquées, c'est ça ?
-- François Lafont
Benoit Izac
Bonjour,
le 07/08/2015 à 14:24, Francois Lafont a écrit dans le message <55c4a374$0$3183$ :
Ma question : pourquoi la mise à jour (le petit patch de rien du tout) n'est pas disponible directement dans Jessie (la distribution stable) ?
Le patch a été appliqué à la version de développement de procps-ng, qui deviendra probablement la 3.3.11 dans quelques temps. Entre la version disponible dans Jessie (3.3.10) et maintenant, il y a eu plein d'autres commits.
D'ailleurs, tu aurais dû remonter ce bug, non pas à Debian (qui n'est en rien responsable) mais, directement à l'upstream (procps @ freelists.org). Si le mainteneur Debian n'était pas développeur de pocps-ng, il aurait très bien pu faire un patch uniquement pour Debian et les autres distributions n'en auraient pas profité.
De plus, je ne suis pas certain qu'il y ait un nouveau paquet Debian avant la sortie de la 3.3.11 contrairement à ce que peut laisser penser la réponse du mainteneur/développeur.
J'imagine que c'est la politique Debian qui veut cela mais pourquoi précisément ?
J'ai l'impression que c'est aussi le poisson qui se mort la queue : sid veut la dernière version et stable veut une version éprouvée. Pour que le patch aille dans stable, il faudrait prendre la version actuelle dans stable, faire le petit patch et la renvoyer dans sid mais sid ne vas pas repasser à une version antérieur que celle qui est déjà en cours donc ça n'ira jamais dans stable... (ce n'est pas le cas ici mais je pense que l'idée est là).
Sur la distribution stable de Debian, seules les mises à jour dites « de sécurité » sont appliquées, c'est ça ?
le 07/08/2015 à 14:24, Francois Lafont a écrit dans le message
<55c4a374$0$3183$426a74cc@news.free.fr> :
Ma question : pourquoi la mise à jour (le petit patch de rien
du tout) n'est pas disponible directement dans Jessie (la
distribution stable) ?
Le patch a été appliqué à la version de développement de procps-ng, qui
deviendra probablement la 3.3.11 dans quelques temps. Entre la version
disponible dans Jessie (3.3.10) et maintenant, il y a eu plein d'autres
commits.
D'ailleurs, tu aurais dû remonter ce bug, non pas à Debian (qui n'est en
rien responsable) mais, directement à l'upstream
(procps @ freelists.org). Si le mainteneur Debian n'était pas
développeur de pocps-ng, il aurait très bien pu faire un patch
uniquement pour Debian et les autres distributions n'en auraient pas
profité.
De plus, je ne suis pas certain qu'il y ait un nouveau paquet Debian
avant la sortie de la 3.3.11 contrairement à ce que peut laisser penser
la réponse du mainteneur/développeur.
J'imagine que c'est la politique Debian qui veut cela mais pourquoi
précisément ?
<https://www.debian.org/security/faq#oldversion>
J'ai l'impression que c'est aussi le poisson qui se mort la queue : sid
veut la dernière version et stable veut une version éprouvée. Pour que
le patch aille dans stable, il faudrait prendre la version actuelle dans
stable, faire le petit patch et la renvoyer dans sid mais sid ne vas pas
repasser à une version antérieur que celle qui est déjà en cours donc ça
n'ira jamais dans stable... (ce n'est pas le cas ici mais je pense que
l'idée est là).
Sur la distribution stable de Debian, seules les mises à jour dites
« de sécurité » sont appliquées, c'est ça ?
le 07/08/2015 à 14:24, Francois Lafont a écrit dans le message <55c4a374$0$3183$ :
Ma question : pourquoi la mise à jour (le petit patch de rien du tout) n'est pas disponible directement dans Jessie (la distribution stable) ?
Le patch a été appliqué à la version de développement de procps-ng, qui deviendra probablement la 3.3.11 dans quelques temps. Entre la version disponible dans Jessie (3.3.10) et maintenant, il y a eu plein d'autres commits.
D'ailleurs, tu aurais dû remonter ce bug, non pas à Debian (qui n'est en rien responsable) mais, directement à l'upstream (procps @ freelists.org). Si le mainteneur Debian n'était pas développeur de pocps-ng, il aurait très bien pu faire un patch uniquement pour Debian et les autres distributions n'en auraient pas profité.
De plus, je ne suis pas certain qu'il y ait un nouveau paquet Debian avant la sortie de la 3.3.11 contrairement à ce que peut laisser penser la réponse du mainteneur/développeur.
J'imagine que c'est la politique Debian qui veut cela mais pourquoi précisément ?
J'ai l'impression que c'est aussi le poisson qui se mort la queue : sid veut la dernière version et stable veut une version éprouvée. Pour que le patch aille dans stable, il faudrait prendre la version actuelle dans stable, faire le petit patch et la renvoyer dans sid mais sid ne vas pas repasser à une version antérieur que celle qui est déjà en cours donc ça n'ira jamais dans stable... (ce n'est pas le cas ici mais je pense que l'idée est là).
Sur la distribution stable de Debian, seules les mises à jour dites « de sécurité » sont appliquées, c'est ça ?
Si le mainteneur Debian n'était pas développeur de pocps-ng, il aurait très bien pu faire un patch uniquement pour Debian et les autres distributions n'en auraient pas profité.
Heureusement, non, quand un bug signalé concerne l'upstream, le mainteneur Debian est censé faire suivre :
If changes to the source code are made that are not specific to the needs of the Debian system, they should be sent to the upstream authors in whatever form they prefer so as to be included in the upstream version of the package.
Benoit Izac , dans le message <87614q3dyu.fsf@izac.org>, a écrit :
Si le mainteneur Debian n'était pas
développeur de pocps-ng, il aurait très bien pu faire un patch
uniquement pour Debian et les autres distributions n'en auraient pas
profité.
Heureusement, non, quand un bug signalé concerne l'upstream, le mainteneur
Debian est censé faire suivre :
If changes to the source code are made that are not specific to the
needs of the Debian system, they should be sent to the upstream
authors in whatever form they prefer so as to be included in the
upstream version of the package.
Si le mainteneur Debian n'était pas développeur de pocps-ng, il aurait très bien pu faire un patch uniquement pour Debian et les autres distributions n'en auraient pas profité.
Heureusement, non, quand un bug signalé concerne l'upstream, le mainteneur Debian est censé faire suivre :
If changes to the source code are made that are not specific to the needs of the Debian system, they should be sent to the upstream authors in whatever form they prefer so as to be included in the upstream version of the package.
Benoit Izac
Bonjour,
le 08/08/2015 à 09:20, Nicolas George a écrit dans le message <55c5adc2$0$2992$ :
Si le mainteneur Debian n'était pas développeur de pocps-ng, il aurait très bien pu faire un patch uniquement pour Debian et les autres distributions n'en auraient pas profité.
Heureusement, non, quand un bug signalé concerne l'upstream, le mainteneur Debian est censé faire suivre :
If changes to the source code are made that are not specific to the needs of the Debian system, they should be sent to the upstream authors in whatever form they prefer so as to be included in the upstream version of the package.
Dans ce cas, pourquoi passer par un intermédiaire ?
| By reporting bugs upstream, you will not only help Archers and Arch | developers, but you will also help other people in the free software | community as the solution will trickle down to all distributions.
-- Benoit Izac
Bonjour,
le 08/08/2015 à 09:20, Nicolas George a écrit dans le message
<55c5adc2$0$2992$426a74cc@news.free.fr> :
Si le mainteneur Debian n'était pas
développeur de pocps-ng, il aurait très bien pu faire un patch
uniquement pour Debian et les autres distributions n'en auraient pas
profité.
Heureusement, non, quand un bug signalé concerne l'upstream, le mainteneur
Debian est censé faire suivre :
If changes to the source code are made that are not specific to the
needs of the Debian system, they should be sent to the upstream
authors in whatever form they prefer so as to be included in the
upstream version of the package.
Dans ce cas, pourquoi passer par un intermédiaire ?
En tout cas, l'histoire nous a démontré que c'est déjà arrivé avec les
conséquences que l'on connaît :
<https://www.debian.org/security/2008/dsa-1571>.
C'est pourquoi je préfère la position d'Arch Linux
<https://wiki.archlinux.org/index.php/Reporting_bug_guidelines#Upstream_or_Arch.3F>
| By reporting bugs upstream, you will not only help Archers and Arch
| developers, but you will also help other people in the free software
| community as the solution will trickle down to all distributions.
le 08/08/2015 à 09:20, Nicolas George a écrit dans le message <55c5adc2$0$2992$ :
Si le mainteneur Debian n'était pas développeur de pocps-ng, il aurait très bien pu faire un patch uniquement pour Debian et les autres distributions n'en auraient pas profité.
Heureusement, non, quand un bug signalé concerne l'upstream, le mainteneur Debian est censé faire suivre :
If changes to the source code are made that are not specific to the needs of the Debian system, they should be sent to the upstream authors in whatever form they prefer so as to be included in the upstream version of the package.
Dans ce cas, pourquoi passer par un intermédiaire ?
| By reporting bugs upstream, you will not only help Archers and Arch | developers, but you will also help other people in the free software | community as the solution will trickle down to all distributions.
