A ps az összes futó folyamatot megjeleníti, míg a w csak azt, hogy ki van benn és éppen milyen parancsot futtat.
Ha pl nem csinál semmit, akkor arra ott az idle time, gondolom ez a script egyik alappillére.
Ha viszont a ps aux | grep -i hetsznyukapanyanyimonyok alapú, akkor meg minden folyamat, amit az adtt felhasználó indított el, pl azzal, hogy belépett, pl bash, login, stb.
A különbség számomra ahogy leesett az az, hogy a ps aux minden folyamat, ami éppen fut, a w pedig hogy ki és éppen mit csinál és mindig az utolájra beírt parancsot írja ki, hogyha pedig a csóka visszakapja a command prompt-ot, akkor a w kimenete az adott felhasználó alapértelmezett shell-jének a neve.
PFF, megint nem tudok fogalmazni 😀

A „ps -ef” -et használom, az összes processz megjelenítéséhez. Nyilván ebből ki kell szürni azokat grep-el, akik használnak adatbázist.
Megnézem „w” -vel ugyanígy szürve grep-el, és kiderül hogy a „ps” -el megjelenítettekhez képest csak kb. harmada van a „w” listán. Most ezek úgy lógnak valahol, és nincsenek belépve? A „ps” kiírja hogy ott vannak, van tty meg loginnév meg ilyenek.
Az is lehetséges hogy ezeket már nyugodtan ki lehet lökni az adatbázisból, mert olyan közelzombi állapotban vannak.
Az adatbáziskezelőnek is van egy segédszoftvere, ami a „ps” -nek megfelelő állapotot írja ki a userhasználatot illetően, tehát a „ps” -nek igaza van. Az egyetlen probléma az hogy csak a „w” használatával tudom eldönteni, hogy az adott user vajon lustálkodik-e, vagy hosszabb feldolgozást futtat, ugyanis csak ebben jelenik meg a processz JCPU ideje.
Tehát egy kb. 10 perces sleep idő alatt szeretném kideríteni az adott processz müködését és annak cpu terhelését a „w” -vel, viszont sok processz már eleve nem is jelenik meg.
Lehet hogy kicsit zavaros amit írok, de valami ötlet jó lenne ennek a megoldására, pl. a jcpu idő kijelzése mással típusú is.

EL

Szerkesztve utólag:
Azt hiszem a dolog világosodik:
A „w” által kiírt listán azért nem jelennek meg azok a bizonyos processzek, mert már nem is élnek, tehát elvileg nyugodtan leállíthatók. Elvileg. Valami „tcp delay” mizéria lehet.
Gyakorlatilag ennek a feltételezésnek a kivizsgálása – érzésem szerint – hosszabb időt vesz igénybe.