Commande ps et tri par rapport à "etimes" qui ne semble pas fonctionner...

Le
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 :

~$ ps o 'etimes,pid' k -etimes
ELAPSED PID
26410 4426
26407 4511
4687 9288
3678 9950
2737 10152
1143 10598
1133 10599
1123 10600
0 10694

~$ ps o 'etimes,pid' k etimes
ELAPSED PID
26414 4426
26411 4511
4691 9288
3682 9950
2741 10152
1147 10598
1137 10599
1127 10600
0 10695

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é :

~$ ps o 'etimes,pid' k etime
ELAPSED PID
0 10724
1613 10600
1623 10599
1633 10598
3227 10152
4168 9950
5177 9288
26897 4511
26900 4426

~$ ps o 'etimes,pid' k -etime
ELAPSED PID
26902 4426
26899 4511
5179 9288
4170 9950
3229 10152
1635 10598
1625 10599
1615 10600
0 10725

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) :

~# ps ax o "etimes,pid" k -etimes
ELAPSED PID
6902954 1
6902954 2
6902954 3
6902954 6
6902954 7
6902954 8
6902954 9
6902954 10
6902954 12
6902954 13
6902954 14
6902954 15
6902954 16
6902954 17
6902954 18
6902954 19
6902954 20
6902954 21
6902954 23
6902954 24
6902954 25
6902954 27
6902954 28
6902954 29
6902954 30
6902954 31
6902954 32
6902954 33
6902954 34
6902954 35
6902954 36
6902954 37
6902954 38
6902954 39
6902954 40
6902954 41
6902954 42
6902954 43
6902954 44
6902954 49
6902954 50
6902954 51
6902953 52
6902953 53
6902953 54
6902953 55
6902953 56
6902953 57
6902953 58
6902953 207
6902953 215
6902953 270
6902953 297
6902953 300
6902953 303
6902953 304
6902953 312
6902951 357
6902950 492
6902950 752
6902950 778
6902950 783
6902950 785
6902948 1559
6902948 1560
6902948 1561
6902948 1562
6902948 1563
6902946 1934
6902946 2084
6902946 2095
6902945 2101
6902945 2103
6902945 2110
6902945 2114
6902944 2597
6902944 2599
6902944 2714
6902944 2716
6902944 2743
6902943 2767
6902943 2769
6902943 2770
6902943 2779
6902943 2799
6902943 2800
6902943 2825
6902942 2849
6902938 2892
6902936 3023
6902935 3170
6902935 3189
6902933 3192
6902933 3217
6902933 3218
6902933 3219
6902933 3220
6902933 3221
6902933 3222
6902910 3586
6902910 3587
1238582 3768
5049399 8165
223064 8930
223064 8931
223064 8932
223064 8933
223064 8934
223063 8987
144641 12001
53933 12610
3465 12876
3422 12986
3420 12992
76912 13644
166804 15765
1132308 16928
1838 17335
1618 17887
6899679 18796
6899679 18799
6061296 19567
166 22104
184249 22819
2 23083
1 23084
1 23086
0 23088
26424 27241
6896527 31230

~# ps ax o "etimes,pid" k etimes
ELAPSED PID
6903004 1
6903004 2
6903004 3
6903004 6
6903004 7
6903004 8
6903004 9
6903004 10
6903004 12
6903004 13
6903004 14
6903004 15
6903004 16
6903004 17
6903004 18
6903004 19
6903004 20
6903004 21
6903004 23
6903004 24
6903004 25
6903004 27
6903004 28
6903004 29
6903004 30
6903004 31
6903004 32
6903004 33
6903004 34
6903004 35
6903004 36
6903004 37
6903004 38
6903004 39
6903004 40
6903004 41
6903004 42
6903004 43
6903004 44
6903004 49
6903004 50
6903004 51
6903003 52
6903003 53
6903003 54
6903003 55
6903003 56
6903003 57
6903003 58
6903003 207
6903003 215
6903003 270
6903003 297
6903003 300
6903003 303
6903003 304
6903003 312
6903001 357
6903000 492
6903000 752
6903000 778
6903000 783
6903000 785
6902998 1559
6902998 1560
6902998 1561
6902998 1562
6902998 1563
6902996 1934
6902996 2084
6902996 2095
6902995 2101
6902995 2103
6902995 2110
6902995 2114
6902994 2597
6902994 2599
6902994 2714
6902994 2716
6902994 2743
6902993 2767
6902993 2769
6902993 2770
6902993 2779
6902993 2799
6902993 2800
6902993 2825
6902992 2849
6902988 2892
6902986 3023
6902985 3170
6902985 3189
6902983 3192
6902983 3217
6902983 3218
6902983 3219
6902983 3220
6902983 3221
6902983 3222
6902960 3586
6902960 3587
1238632 3768
5049449 8165
223114 8930
223114 8931
223114 8932
223114 8933
223114 8934
223113 8987
144691 12001
53983 12610
3515 12876
3472 12986
3470 12992
76962 13644
166854 15765
1132358 16928
1888 17335
1668 17887
6899729 18796
6899729 18799
6061346 19567
216 22104
184299 22819
0 23229
26474 27241
6896577 31230

En remplaçait "k etimes" (resp "k -etimes") par "k etime" (resp
"k -etime"), j'ai à nouveau un classement correct.

--
François Lafont
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Benoit Izac
Le #26362329
Bonjour,

le 04/08/2015 à 20:29, Francois Lafont a écrit dans le message

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
Le #26362334
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. ;)
Benoit Izac
Le #26362335
Dans le message écrit :

Bonjour,

le 04/08/2015 à 20:29, Francois Lafont a écrit dans le message

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) :

/* code header print() sort() width need vendor flags */
[...]
{"etime", "ELAPSED", pr_etime, sr_etime, 11, 0, U98, ET|RIGHT}, /* was 7 wide */
{"etimes", "ELAPSED", pr_etimes, sr_nop, 7, 0, BSD, ET|RIGHT}, /* FreeBSD */

Donc sr_nop qui veut sans doute dire que c'est non implémenté. Je pense
que ça pourrait être remplacé par sr_etime.

--
Benoit Izac
Francois Lafont
Le #26362338
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) :

/* code header print() sort() width need vendor flags */
[...]
{"etime", "ELAPSED", pr_etime, sr_etime, 11, 0, U98, ET|RIGHT}, /* was 7 wide */
{"etimes", "ELAPSED", pr_etimes, sr_nop, 7, 0, BSD, ET|RIGHT}, /* FreeBSD */

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
Le #26362340
Bonjour,

le 04/08/2015 à 23:02, Francois Lafont a écrit dans le message

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
Le #26362344
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 :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bugv4590.

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. ;)
Francois Lafont
Le #26362679
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 ?

--
François Lafont
Benoit Izac
Le #26362769
Bonjour,

le 07/08/2015 à 14:24, Francois Lafont a écrit dans le message

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 ?



Oui.


--
Benoit Izac
Nicolas George
Le #26362788
Benoit Izac , dans le message
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
Le #26362822
Bonjour,

le 08/08/2015 à 09:20, Nicolas George a écrit dans le message

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 :

C'est pourquoi je préfère la position d'Arch Linux

| 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
Publicité
Poster une réponse
Anonyme