Я напісаў whotop у жніўні, пасля вечара, калі порт 4310 аказаўся занятым і я забіў не той працэс node. 19 жніўня я выклаў пакет у npm. Галоўнае, што абяцае README: whotop кажа, што значэнне недаступнае і чаму, замест упэўненай здагадкі. У кожнай ролі ёсць правіла, якое яе вызначыла.
Гэтае абяцанне я правяраў на фікстурах, якія запісаў сам, і на ранерах CI. Ні разу я не ўзяў сапраўдны вечар сваёй машыны і не задаў ёй радок за радком тое адзінае пытанне, дзеля якога інструмент існуе. Некалькі дзён таму я пісаў пра начны лог свайго ноўтбука. У тым жа логу ёсць адказ: 96 здымкаў whotop ls --all --json, версія 0.4.1, Windows, без правоў адміністратара. Я ўзяў здымак 29 верасня ў 01:59, калі мае агенцкія сесіі толькі што скончылі працу. Глядзеў толькі на працэсы, якія трымаюць TCP-порт на праслухоўванне.
Такіх 33 з 484 працэсаў. Ролю whotop даў 21 з іх: 20 працэсам node, якія ён называе dev-серверамі, і Postgres. Астатнія 12 whotop пазначыў як unknown. 11 з іх наогул не паказалі камандны радок.
З партамі ўсё ў парадку
На Windows whotop адным выклікам PowerShell атрымлівае і табліцу працэсаў, і табліцу сокетаў. Pid уладальніка кожнага сокета зняты ў той жа момант, што і спіс працэсаў. Паводле README, порт, прыпісаны не таму працэсу, гэта тая памылка, якой гэты інструмент рабіць нельга. За гэтую ноч я не знайшоў у логу нічога, што супярэчыла б калонцы партоў.
Гэты прыклад я не планаваў. 5 працэсаў на ноўтбуку былі запушчаныя як astro preview --port 4321, у розны час на працягу 2 дзён. Я іх так і не спыніў. 4321 трымае толькі адзін з іх, pid 23620. Астатнія 4 паводле табліцы сокетаў сядзяць на 4322, 4323, 4324 і 4325. Яшчэ 5 запушчаныя з --port 4326 у першыя 20 хвілін пасля поўначы і сядзяць на партах з 4326 па 4330. У 8 працэсаў порт у камандным радку не той, які яны трымаюць.
Гэта зноў мой жнівеньскі вечар. Калі шукаць 4321 у камандных радках, будзе 5 кандыдатаў і 4 з іх не тыя. whotop port 4321 дае адзін pid.
11 радкоў спасылаюцца на доказ, якога няма
Усе 11 працэсаў astro, гэтыя 10 і яшчэ адзін з --port 4331, падпісаныя як vite. Побач з кожным надрукавана прычына “known dev server in the command line (vite)”. Слова “vite” няма ні ў адным з гэтых 11 камандных радкоў. Там запушчаны astro.js preview.
Я палез у код. Правіла спрацоўвае таму, што ўваходны скрыпт гэта astro. Гэта правільна. Але ярлык і прычыну збірае адна дапаможная функцыя, якая шукае ў камандным радку першы токен dev-сервера. Калі не знаходзіць ніводнага, яна ўсё роўна вяртае першы токен са спіса. Першым у спісе стаіць vite. Роля правільная. Але слова ў ярлыку і ў прычыне бярэцца са значэння па змаўчанні. У README напісана, што класіфікацыя, якую нельга праверыць, гэта тая ж здагадка, толькі ветлівейшая. Тут камандны радок ляжаў у логу, так што праверыць я мог.
Каталогі толькі выведзеныя
На Windows whotop не чытае працоўны каталог чужога працэсу. Для гэтага давялося б чытаць памяць працэсу, таму ён бярэ самы доўгі абсалютны шлях з каманднага радка і пазначае яго (inferred). Для 11 радкоў astro гэта каталог праекта. Падобна на праўду, хоць па логу я і гэтага праверыць не магу.
Яшчэ для 7 радкоў ён не кажа нічога карыснага. 6 працэсаў http-server і 1 serve запушчаныя з кэша npx, таму адзіны шлях у іх камандным радку вядзе ў гэты кэш. whotop абразае яго перад node_modules і выдае каталог кэша. У 6 радкоў http-server атрымліваецца адзін і той жа каталог. Па ім іх не адрозніць. Адзін з гэтых працэсаў трымае 4310, той самы порт з жнівеньскага вечара.
Адзін радок няправільны з-за памылкі ў разборы шляху. У сервера ts-node-dev на порце 4400 у камандным радку 2 шляхі: файл хука ў D:/Temp і за ім шлях праекта. Мой рэгулярны выраз для пошуку шляхоў дазваляе прабелы ўнутры шляху. Першае супадзенне пераскоквае праз прабел і забірае з сабой літару дыска другога шляху. Другі шлях whotop не бачыць зусім. У радку стаіць D:/Temp. Я ўзнавіў гэта на апублікаваным пакеце: без шляху хука тая ж каманда дае каталог праекта.
З 20 радкоў node у 8 каталог фармальна пазначаны як (inferred) і нічым не дапамагае, калі я збіраюся нешта забіць. Яшчэ 3 радкі атрымалі замест ярлыка толькі імя свайго скрыпта, але там прычына сумленна кажа, што больш нічога не супала. У README гэтая праблема з каталогам апісана на прыкладзе claude.exe: яго каталог усталёўкі выглядаў як працоўны. Той выпадак я выправіў у жніўні, а іншых шукаць не стаў.
Імёны службаў застаюцца на адным экране
У гэтым здымку 163 з 484 працэсаў схавалі камандны радок. Рэестр службаў, які whotop чытае без правоў адміністратара, назваў 115 з іх. Папярэджанне ў кожным здымку так і кажа. Але я пашукаў ва ўсім начным логу хоць адно імя службы і не знайшоў. Імёны прывязаныя да працэсу, але друкуе іх толькі інтэрактыўны экран. whotop ls, whotop port і вывад JSON іх выкідваюць.
Я ўзнавіў гэта на падрыхтаваных даных: svchost.exe трымае порт 135 і запускае службу RpcSs. На інтэрактыўным экране гэта svchost.exe [RpcSs]. whotop port 135 паказвае unknown і раіць запусціць абалонку з правамі адміністратара. whotop ls RpcSs нічога не знаходзіць. На маім ноўтбуку 4 з 12 невядомых працэсаў з портам на праслухоўванне былі svchost, а ён існуе для таго, каб запускаць у сабе службы. Якія гэта былі службы, лог сказаць не можа: JSON ужо выкінуў імёны.
Чаго я не правяраў
Сапраўдны працоўны каталог ніводнага з гэтых працэсаў я па логу праверыць не магу. Я не запускаў whotop з правамі адміністратара, таму не ведаю, колькі з 11 маўклівых працэсаў whotop назваў бы з правамі адміністратара. Парты 139, 445 і 5357 належаць pid 4, System. whotop там проста піша unknown. Яшчэ ў здымку 25 сокетаў без працэсу-ўладальніка, іх не паказвае ніводзін радок.
Гэта адзін ноўтбук і адзін здымак, але за ноч лічбы амаль не мяняюцца. У 81 з 96 здымкаў 32 ці 33 працэсы з портам на праслухоўванне, з іх 21 з роляй. 11 ярлыкоў vite ёсць у 91 здымку, а 7 каталогаў npx ва ўсіх 96.
Ніводная з 3 праблем не выпраўлена ў 0.4.1, версіі, якая цяпер ляжыць у npm.