La commande "PURGE" ne fonctionne plus sur Maverick

Nan mais tout ces outils ne sont, à coup sûr, qu'il interfaçage de l'appel la commande purge qui ne necessitait pas de droit d'admin auparavant et qui en nécessite actuellement.
Je pense que ces machins (qu'ils soient gratuits ou payants) ne sont plus fonctionnels.

Perso, je ne vois pas l'intérêt de la commande purge tant que l'OS ne commence pas à créer du SWAP.
 
Jusqu'à l'arrivée de Mavericks, qui demandera de nouvelles vérifications, l'utilité de la commande était flagrante, en tout cas sur mes trois portables.
Exemple sur le MBP avec 8 GB de RAM :
- sans appel à purge, le MBP avait 4 GB de swap au bout de 3-4 jours puis se maintenait entre 4 et 5 GB.
- avec appel à purge, le MBP se cantonnait au 64 MB de swap initiaux, sauf (très bizarrement) appel à certaines commandes qui le faisait monter à 256 MB (en dépit de plusieurs GB de libres ; allez comprendre !)

En fait, cela vient de ce que le système croyait astucieux d'utiliser du swap plutôt que de libérer complètement la mémoire inutilisée. Complètement crétin mais bon, il a fallu semble-t-il plus de dix ans pour que quelque chose soit fait.

PS : pourquoi crétin ? Parce que vider de la RAM et la réutiliser est une tâche extrêmement rapide quand allouer et paginer des fichiers de swap sur un disque dur est, comparativement, très lent. Donc quand on a 2 GB de RAM inutilisée, avec la purge on la libère totalement et elle est directement utilisable et on gagne du temps.
Encore un cas une supposée optimisation ne fait qu'empirer le fonctionnement : recharger des bibliothèques, déjà cachées par ailleurs, et lorsqu'on en a besoin, est moins coûteux aussi que gérer du swap.
 
J'ai installé Mavericks hier sur l'un de mes iMac (cf. signature), et outre le problème signalé ici, j'ai remarqué qu'il crée dès le démarrage un gros fichier de swap:
Bloc de code:
ls -lh /private/var/vm/
total 2228224
-rw-------  1 root  wheel    64M 29 oct 18:02 swapfile0
-rw-------  1 root  wheel   1,0G 29 oct 18:02 swapfile1
À titre de comparaison, voici ce que j'ai sur l'autre mac avec 10.8.5:
Bloc de code:
ls -lh /private/var/vm  
total 524288
-rw-------  1 root  wheel    64M 24 oct 12:25 swapfile0
-rw-------  1 root  wheel    64M 29 oct 18:41 swapfile1
-rw-------  1 root  wheel   128M 29 oct 18:41 swapfile2
Je précise que j'ai fait une clean install. Il va me falloir user régulièrement de la commande purge.
 
Dernière édition:
purge sera sqns doute encore utile mais la raison de la taille initiale du fichier de swap est à chercher dans un changement de gestion de la mémoire virtuelle.
 
purge sera sqns doute encore utile mais la raison de la taille initiale du fichier de swap est à chercher dans un changement de gestion de la mémoire virtuelle.
Il faut en conclure que c'est sans rapport avec la Ram de mon iMac (seulement 4 Go), et que ce doit être pour tout le monde pareil?
 
Oui. Mon MBP a 8 GB de RAM et le fichier a également été créé avec cette taille.
 
Il y a tout de même vraiment un gros problème dans la gestion de la mémoire virtuelle:
Bloc de code:
ls -lh /private/var/vm/
total 16908288
-rw-------  1 root  wheel    64M 29 oct 18:02 swapfile0
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile1
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile2
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile3
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile4
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile5
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile6
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile7
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile8
Je précise: il y avait 3 Go de swap avant d'ouvrir iPhoto (une librairie qui fonctionnait parfaitement sous 10.8) il y a quelques minutes; et là, 8 Go, iPhoto qui ne répond plus pendant un bon moment, etc.

Cela me fait rager, parce que j'avais lu que Mavericks aurait une gestion optimisée de la mémoire permettant une plus grande réactivité de la machine, ce qui était ma principale motivation pour faire la mise à jour de la machine en question, et c'est exactement le contraire qui se produit. On se croit revenu à 10.3 en pire. À ce train-là, il va falloir lancer purge toutes les deux minutes, avec blocage de l'activité pendant ce temps…!
 
Il y a tout de même vraiment un gros problème dans la gestion de la mémoire virtuelle:
Bloc de code:
ls -lh /private/var/vm/
total 16908288
-rw-------  1 root  wheel    64M 29 oct 18:02 swapfile0
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile1
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile2
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile3
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile4
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile5
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile6
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile7
-rw-------  1 root  wheel   1,0G 30 oct 18:06 swapfile8
Je précise: il y avait 3 Go de swap avant d'ouvrir iPhoto (une librairie qui fonctionnait parfaitement sous 10.8) il y a quelques minutes; et là, 8 Go, iPhoto qui ne répond plus pendant un bon moment, etc.

Cela me fait rager, parce que j'avais lu que Mavericks aurait une gestion optimisée de la mémoire permettant une plus grande réactivité de la machine, ce qui était ma principale motivation pour faire la mise à jour de la machine en question, et c'est exactement le contraire qui se produit. On se croit revenu à 10.3 en pire. À ce train-là, il va falloir lancer purge toutes les deux minutes, avec blocage de l'activité pendant ce temps…!

Ce qu'i faudrait voir c'est si ta RAM est complétement utilisée à ce moment là.
(parce que 4Go, depuis Lion, c'est très -trop?- peu)
 
Tu as raison. Mais 8 GB, ça paraît un peu énorme, quand même.

Quand on sait qu'Apple vend encore des machines avec 4 GB de RAM par défaut...

Je pense que là, on a un vrai bug (à signaler à Apple, je dirais). De mon côté, je n'ai pas de souci pour l'instant, avec ma vieille version de iPhoto ('08).
 
Tu as raison. Mais 8 GB, ça paraît un peu énorme, quand même.

Quand on sait qu'Apple vend encore des machines avec 4 GB de RAM par défaut...

Je pense que là, on a un vrai bug (à signaler à Apple, je dirais). De mon côté, je n'ai pas de souci pour l'instant, avec ma vieille version de iPhoto ('08).

:sleep:
Franchement, le passage de 4 à 8 Go s'est justifié pour moi lors de la migration de 10.6 à 10.7 (SL à L en juillet 2011).
Les 4 Go supplémentaires ont bien soulagé mon MBP...
Aujourd'hui, mon MBP commence à vieillir et ma prochaine machine aura sans doute 16 Go... :eek:
 
☞ À l'intention de celles_&_ceux qui voudraient pouvoir continuer de recourir à une petite application 'AppleScript' afin de purger ponctuellement et manuellement la mémoire RAM Inactive.

♤

Comme il a été relevé dans ce fil, le fichier exécutable 'purge' (localisé sous «Mavericks» à l'adresse : /usr/sbin) requiert des droits root pour être activé. Parmi les conséquences :

- ouvrir une fenêtre du «Terminal» pour y taper désormais sudo purge, au lieu de l'ancien purge, déclenche une demande de password pour que l'utilisateur se promeuve sudoer - ce qui fait que cette manœuvre à rallonges devient peu praticable 'à la volée' en cas de recours ponctuel ;

- l'ancienne petite application_maison 'Purge' réalisée grâce à l'«Éditeur AppleScript» par renseignement du script :

Bloc de code:
do shell script "purge"
quit

n'exécute plus le fichier 'purge' par double-clic sur son icône, mais, faute de mot-de-passe root autorisant l'opération, fait apparaître le message : 'operation not permitted.​

Afin de récupérer la fonctionnalité de cet 'AppleScript' toujours commode à avoir à disposition 'okazou', il suffit de pratiquer les 2 opérations suivantes :

♧

- a) activer l'utilisateur root (ne concerne que celles & ceux qui ne l'auraient pas déjà réveillé des limbes). Le plus direct est de presser la combinaison de touches ⇧⌘G (Aller au dossier... dans le menu Aller du Finder) et de copier-coller dans le champ de saisie : /System/Library/CoreServices afin de faire s'afficher le répertoire 'CoreServices' pour lancer l'application : «Utilitaire d'Annuaire». Déverrouiller le cadenas avec un mot-de-passe admin (requis), se rendre dans la barre supérieure de menus à : 'Édition' et sélectionner : 'Activer l'utilisateur root'. Une demande de saisie d'un mot-de-passe root intervient, à la suite de quoi le Super-Utilisateur Système root se trouve activé. Re-démarrer.

[NB. L'intérêt de la manœuvre est de se procurer un mot-de-passe_root actif. L'inconvénient de la manœuvre est que certains néophytes pourraient bien être tentés de s'en aller faire des ravages en mode graphique dans leur OS en ouvrant une session_root, pour ensuite venir grossir les rangs des plaignants du forum OS X de MacG :D.]

♡

- b) créer un AppleScript activable (ceux qui ont l'ancienne petite application_maison purge pourront se contenter de l'ouvrir avec l'«Éditeur AppleScript» et d'éditer le script avant de sauvegarder). Aller à : Applications/Utilitaires et lancer «Éditeur Applescript». Dans la fenêtre de saisie du script, copier-coller :

Bloc de code:
do shell script "purge" password "[COLOR="Red"]le_mot_de_passe_root_actif[/COLOR]" with administrator privileges
quit

comme montré dans ce visuel :

264177_original.png



Il ne reste plus qu'à aller au menu : Fichier/Enregistrer de l'«Éditeur AppleScript», afin de choisir l'intitulé 'Purge' (par exemple) et surtout le format de sortie 'Application' comme montré ici :


264418_original.png



♢

Si vous avez les Menulets de l'application «iStat Menus» dans la barre supérieure de menus du Finder, remarquez quelle valeur de départ est affichée par le menulet 'MEM' à : Inactive, puis double-cliquez l'icône de l'application Applescript «Purge» en laissant l'opération s'exécuter, avant d'aller vérifier au menulet 'MEM' quelle valeur se trouve désormais affichée. Elle devrait avoir baissé de manière significative <du moins c'est ce qu'elle fait sur mon Mac sous «Mavericks» où l'AppleScript fait s'exécuter le fichier purge sans plus de message de déni.>

&#9816;
 
Dernière édition par un modérateur:
Super, marche très bien ton script ! :) Merci!

Par contre, quand j'ai redémarrer après avoir activer les droits root, il y a "autres utilisateurs" à côté de moi sur l'écran de démarrage, et impossible de l'enlever dans les préférences système/utilisateurs et groupe.

C'est normal?
 
Sympa le script ... Sinon Onyx propose au moins téméraires une interface plus facile d'accès ;)
tab "Information > Mémoire
 
Salut waniphon.

Dès lors que tu as activé l'utilisateur root, tu vois apparaître au LoginWindow (écran d'ouverture de session) l'option 'Autre' (avec l'icône -assez laide, je reconnais- d'une silhouette en buste opaque) à côté des icônes personnalisées des utilisateurs ayant-comptes. C'est la situation normale. Ne t'en sens pas dérangé, au contraire! Car à l'occasion, si tu as besoin de lancer une session root en mode graphique (pour vider une poubelle récalcitrante ou pour modifier le nom du titulaire, par exemple, d'un autre compte), il te suffit de sélectionner 'Autre' et dans le double champ de saisie qui apparaît de renseigner :

nom d'utilisateur : root
mot-de-passe : le_mot_de_passe_root

et tu te retrouves dans une session Super-Administrateur Système. Rien ne la différencie d'une autre graphiquement parlant, sauf les pouvoirs qui y sont appendus. D'une session root, par exemple, tous les répertoires de l'OS sont accessibles en mode graphique, y compris les répertoires d'utilisateurs protégés par mots de passe, qui se trouvent aussi accessibles que des dossiers ordinaires.

&#9828;

Pour continuer en mode 'jeopardization' du sujet de ce fil, on pourrait voir là une faille de sécurité des données personnelles sous OS X, mais à bien considérer les choses, elle concerne surtout l'utilisateur-admin aborigène de l'OS qui, ayant eu la courtoisie de permettre à une autre personne d'avoir un compte-admin parallèle sans avoir soi-même activé l'utilisateur root, se retrouverait avec un admin_en_second qui aurait pris l'initiative d'activer l'utilisateur root inactif. Avec, donc, la possibilité d'aller fureter d'une session root dans les répertories de l'admin_aborigène. Ce qui est bien indélicat. Un utilisateur-admin aborigène admettant d'autres utilisateurs-admin en parallèle devrait toujours activer une 1ère fois l'utilisateur root afin de définir le mot-de-passe root, quitte ensuite à désactiver l'utilisateur root. Ainsi, un admin_en_second ne pourrait pas, en mode graphique, utiliser le jocker 'root' pour outrepasser ('override') la protection du répertoire de compte de l'admin_aborigène.

&#9831;

Mais ce débat reste assez futile, dès lors qu'un admin_en_second est habilité à utiliser le «Terminal» en se promouvant sudoer avec son mot de passe admin, pour passer des commandes sudo. Ainsi, si tu supposes que toto est l'admin_aborigène du Mac, et qu'il a intronisé bibi au rang d'admin_en_second, eh bien! bibi peut très bien dans le «Terminal» passer par exemple une commande :

Bloc de code:
sudo chown -R toto:admin /Users/toto

qui modifie le groupe staff (ayant-comptes) de relevance par défaut du compte de toto en le groupe admin auquel bibi appartient à tous les étages du répertoire de toto ; puis :

Bloc de code:
sudo chmod -R 770 /Users/toto

pour élargir les droits drwx------ appendus aux sous-répertoires de toto (lecture-écriture/exécution pour lui seul) en drwxrwx--- qui permet à un membre du groupe admin d'accéder en clair aux sous-répertoires de toto comme s'il était root. Ce, afin d'accéder à ses données, avant de repasser des commandes inverses de type :

Bloc de code:
sudo chown -R toto:staff /Users/toto

pour rétablir à staff le groupe de relevance des sous-répertoires et répertoire de toto, puis :

Bloc de code:
sudo chmod -R 700 /Users/toto

et :

Bloc de code:
sudo chmod 755 /Users/toto/Public

pour ré-interdire les sous-répertoires à quiconque n'est pas toto sauf le dossier 'Public', enfin :

Bloc de code:
sudo chmod 755 /Users/toto

pour rétablir le répertoire global de toto dans les permissions par défaut dans les versions récentes d'OS X d'exécuter_l'entrée + lire_l'espace dudit répertoire pour tous ceux qui ne sont pas l'utilisateur (où derechef les sous-répertoires de toto porteront pour eux le sens interdit en mode graphique exception faite du dossier 'Public'). Ni vu ni connu. Un peu tortueux, tout cela, n'est-ce-pas? - à l'image des cheminements sans rectitude d'une personne passée du côté sombre de la Force...

&#9825;

...Je n'ai développé cet exercice scolaire, dépourvu de la moindre élégance, que pour en déduire la règle de prudence élémentaire : ne jamais admettre un admin_en_second sur un ordinateur dont on est l'admin_aborigène [même, et surtout même, pas la 'chère & tendre' :D] - si l'on a quelque chose à cacher. Ce n'est pas la seule (verrouiller par un mot-de-passe le programme interne également, afin d'interdire le mode 'Target' ou le boot sur la 'Recovery' à quiconque n'a pas de mot-de-passe admin - la précaution de définir le mot-de-passe Maître afin d'éviter qu'un admin_en_second ne s'en vienne le définir et ne s'approprie la possibilité de ré-initialiser tous les mots-de-passe de comptes en mode graphique devenant irrelevante dans les circonstances), mais elle semble évidente pour quiconque a des soucis sécuritaires. La seule alternative, c'est de considérer un Mac comme une maison_de_verre, et se comporter comme quelqu'un qui n'a rien à cacher - attitude plus difficile à assumer qu'il ne semble...

&#9758; en résumé : j'ai comme qui dirait digressé sur le sujet 'purge' de ce fil, en passant du coq_à_l'âne root_à_l'autre pour en déduire un impératif de purge de tout compte admin fors l'aborigène, sauf si ledit admin_en_second n'est qu'un avatar de l'aborigène créé à des fins d'issue de secours - ce qui à tout bien considérer est un médiocre rattrapage du droit_fil aux cheveux d'un jeu de mots où se lit la licence_root des dimanches... :D

&#9826;

...Sinon Onyx propose au moins téméraires une interface plus facile d'accès
tab "Information > Mémoire

eh oui! takamaka. Maître Onyx est passé par là entre temps. Restent les quelques MacUsers de la vieille école qui aimeraient bien pouvoir continuer d'actionner la purge à la volée en un click sur l'icône de l'application dans leur Dock... Ce qui reste plus direct que de lancer Onyx :D

&#9810;&#65038;​

[Pour les amateurs, je signale qu'en utilisant l'utilitaire «CronniX» (par exemple), il est possible d'éditer la crontab précédente du style :

59 * * * * /usr/bin/purge

définie pour l'utilisateur en :

59 * * * * root /usr/sbin/purge

définie pour le système, et le cron exécutera automatiquement la purge à chaque heure moins une minute dans l'exemple choisi, ce imperturbablement.]

&#9815;
 
Dernière édition par un modérateur:
eh oui! takamaka. Maître Onyx est passé par là entre temps. Restent les quelques MacUsers de la vieille école qui aimeraient bien pouvoir continuer d'actionner la purge à la volée en un click sur l'icône de l'application dans leur Dock... Ce qui reste plus direct que de lancer Onyx :D

Franchement Bravo! C'était scolaire, mais vu mon niveau, c'est bien ainsi. :up:

PS : Quand je passe une commande dans le "terminal", j'ai l'impression d'être un héros. :D
C'est tellement facile de suivre un tuto. :rose:
 
@macomaniac

Ok, au moins on en apprend tous les jours.

Donc impossible de faire le script "purge" sans avoir activé l'utilisateur root ?
 
Salut waniphon.

Donc impossible de faire le script "purge" sans avoir activé l'utilisateur root ?

Il n'est pas aisé de mesurer l'impossible en informatique. Disons (en se bornant à un applescript ciblant le fichier exécutable 'purge' résidant sous «Mavericks» à : /usr/sbin) que :

- le vieux script : do shell script "purge"
quit
se heurte à une interdiction, faute de privilèges suffisants ;

- un nouveau script genre : do shell script "purge" password "le_mot_de_passe_admin" with administrator privileges
quit
revient strictement à passer une commande sudo en tant qu'admin simple : une demande de password s'affiche (le mot-de-passe admin) afin par là de se promouvoir sudoer (équivalent_root) - ce qui n'est franchement pas commode (autant taper sudo purge dans le «Terminal» + mot-de-passe admin) ;

- le nouveau script : do shell script "purge" password "le_mot_de_passe_root" with administrator privileges
quit
passe comme une lettre à la poste car le mot-de-passe renseigné dans le script est le mot-de-passe_root défini à l'activation du Super Admin.​

Donc, pour renseigner un mot-de-passe root, le script suppose que celui-ci ait été défini au préalable, via l'Utilitaire d'Annuaire, en activant l'utilisateur root. Mais rien n'empêche, une fois ce mot-de-passe défini lors de l'activiation en question, de désactiver l'utilisateur root. Le mot-de-passe préalablement défini est retenu comme valide par défaut, aussi longtemps qu'il n'est pas changé. Mais une fois l'utilisateur root désactivé, choisir de le réactiver ouvre l'option de définir à neuf le mot-de-passe root, éventuellement par un différent de l'ancien, ce qui va alors destituer ce dernier et le script ne marchera plus, si le mot-de-passe root n'est pas édité dans sa ligne de texte à sa nouvelle valeur.

Personnellement, script ou pas script, j'active toujours root sur mes Macs et je le laisse activé, car cela me permet à tout moment d'ouvrir une session Super Admin en mode graphique. Aucune raison 'raisonnable' à un tel choix (car le «Terminal» offre bien plus de ressources) - rien qu'un plaisir d'enfance à l'aspect figuratif de super-pouvoirs :D