Fórumok
Hello,
(Jelenleg meg invesztigalas fazis van, nem tudok minden adatot mint pl: oslevel)
Hogy tudom AIX-on barminemu szoftver telepitese nelkul megmondani, hogy mi az eg (valoszinuleg egy kernel thread lesz a ludas ... ) tart nyitva egy LV-t ?
Az LV raw egy mar eltavilotott kernel extension hasznalta korabban.
Tippre valahol kdb kornyeken kellene keresgelnem de nem igazan van 2 hetem, hogy megtalaljam amit keresek...
Esetleg valakinek valami tippje ? (es ha van akkor mi? lsof nem jatszik, procfiles PID-et ker)
Hozzászólások
mi a cél? törölni?
"hibásan" lett eltávolítva a "kernel extension"? azért hiszi még opennek?
lsof pedig megmutatná as far as i remember h. mi használja a raw-t.
nincs scp? ha van vágólap még át lehet másolni egy lsof binárist telepítés nélkül
desktopon: openssl enc -base64 < lsof > a.txt
ctrl+c / ctr+v az a.txt tartalmát a serverre, max cksum-al ellenőrizni h. biztos jó lett-e a másolás
serveren: openssl enc -base64 -d < a.txt > lsof
Nem tudjuk mi tortent.
Az egyik partner szolt, hogy bocsi rossz csomagot telepitettunk (mar 3-adszorra) es uninstall utan open maradt az LV. Azt hozza kell tenni, hogy tovabbra is egy bugos csomagot hasznalnak mert: mindenhol ez fut es az a policy. Hiaba lett a bug javitva 1,5 eve ...
Nem tudtak elmondani mit csinaltak es hozzaferesunk sincs a particiohoz....
Egyelore kertem par kdb-s kimenetet, hogy lassam a kernel szerint mi van betoltve es mi nincs
A fuser-t teljesen elfelejtettem ... : )
Ha nincs lehetőséged linux vagy windows felrakására, akkor próbálkozz az fuser paranccsal! ;)
Ketlem hogy Windows elfutva Power Hardwaren...
Plusz miben segitene akar Windows akar Linux ezen a probleman ? :)
A fuser meg jo tipp volt. Relative elfelejtettem a letezeset.
Pedig ott virít a szmájli! Hát elmagyarázom. Azt írtam tréfásan, hogy a más rendszerekből átvett utility helyett elég lenne ha az oprendszert ismernéd. Az oprendszert vagy valamiféle unix-ot, mert az AIX már tartalmazza a System V és BSD (és még sokan mások) parancskészletét is. Láttam már egy csomó ifjú titánt, akik az AIX megismerését a bash felrakásával kezdték. Ráadásul olyan időben, amikor a bash jóformán semmit sem tudott a ksh-hoz képest. Ennek ellenére nem lenézőnek szántam a mondanivalómat - simán belefér a megfeledkeztem case is.
Háát.. Lehet, hogy a Windows nem fut POWER-en. Bár itt nálam a szomszéd szobában van egy olyan gép, amin vígan futott volna a WindowsNT (meg tán Oracle). Bár ilyen tényelg csak a '95-96-os történelmi időkben fordult elő. A gép egy Motorola Atlas 604 (100MHz PowerPC 604, kb. a 43p-nek felel meg). Mellette meg ott csücsül egy eServer p615-ös is. Szóval az a tippet inkább a rutinnak neveztem volna. :)
Amen!
Amugy csak az erdekesseg kedveert, a Windows fut POWER-en :)
--
As above, so below
Azert mert nem fordulok egy parancshoz (fuser) nem azt jelenti, hogy nem ismerem az operacios rendszert.
Az igaz, hogy nem vagyok NevemTeve szintjen (barcsak ott lennek) de jopar ev AIX/Solaris/Linux tapasztalat van mogottem. Elegge sok olyan alkalom volt amikor a fuser csak azt nem valaszolta meg amit tudni akartam.
Bash-t csak es kizarolag akkor hasznalok ha van. Nem okoz gondot stty erase, set -i vi hasznalata :) Az mar tobb gondot, hogy neha az IBM erdekesen portolja a feature-oket a ksh93-ba :) de hat jo script mident megold...
OT
legyen inkább set -o vi :-)
/OT
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Beragadt futó/alvó/zombi process nyitott file-ként hivatkozik a törölt LV-n lévő filesystem egy/több bejegyzésére.
Ha tudod, ha nem akkor megkeresed a törölt LV major és minor számát, a törölt lv-n lévő file inode számát. Ki tudod keres(tet)ni, milyen beragadt process fogja a már törölt /dev/(r)lvname bejegyzést, melyik a kernelben még meglévő processz fogja az (r)lvname kapcsolatot.
man procfiles
a példa:
milyen file-okat tart nyitva az aktuális shell-em
procfiles $$
31129824 : -ksh
Current rlimit: 2000 file descriptors
0: S_IFCHR mode:00 dev:10,4 ino:37813 uid:0 gid:0 rdev:22,54
O_RDWR | O_NOCTTY
1: S_IFCHR mode:00 dev:10,4 ino:37813 uid:0 gid:0 rdev:22,54
O_RDWR | O_NOCTTY
2: S_IFCHR mode:00 dev:10,4 ino:37813 uid:0 gid:0 rdev:22,54
O_RDWR | O_NOCTTY
10: S_IFREG mode:0444 dev:10,5 ino:18554 uid:0 gid:0 rdev:0,0
O_RDONLY size:5875
63: S_IFREG mode:0600 dev:10,4 ino:37593 uid:0 gid:0 rdev:0,0
O_RDWR | O_APPEND size:158052
(itt most konkrétan a ksh esetében a 0, STDIN, 1 STDOUT, 2 STDERR - ezek tényleges a /dev/pts/n termináldevice-re mutatnak, a 10 és a 63 két filerendszerből megnyitott file ...)
pl, ma a dev:10,4 ?
ls -l /dev | awk '/ 10, 4/'
brw-rw---- 1 root system 10, 4 Sep 19 13:45 hd4
crw-rw---- 1 root system 10, 4 Sep 19 13:45 rhd4
mount | grep hd4
/dev/hd4 / jfs2 Nov 10 00:05 rw,log=/dev/hd8
Tehát a dev:10,4 a rootfs /dev/rhd4, /dev/hd4 device-ra mutat, az ino:37593
Melyik file van az inode:37593 -on ?
find / -xdev -inum 37593 -ls
37593 155 -rw------- 1 root system 158356 Mar 16 12:11 /root/.sh_history
Remélem érthető a fenti példa, a /proc/xxxxx bejegyzésekből leszűkíted, melyik processz gyanús, utána kikeresed (procfiles-sel) mit tart nyitva és így kizárásos alapon kiderül, melyik beragadt process hivatkozik olyan device és inode -ra, ami mát a filerendszerből törölve van.
És ezt a processt kill -ezed.
--
z
Ha user space lenne akkor nem lenne gond...
De mar a legelejen kernel threadre tippeltem. Ez be is jott...
Ha vegre sikerul megkapni az informaciot, hogy mit csinalt a customer egybol konnyebb:
Uninstall lefutott es a script jelezte, hogy nem sikerult eltavolitani a kernel modult.
Customer fogta magat es torolte a /dev/ device-ot, eltavolitotta a PdDv bejegyzeseket
Customer megprobalta torolni az LV-t amit a kernel modul hasznalt... Es csak felinformaciot adott tovabb...
Mivel tudjuk, hogy AIX 7.1-en valamiert nem mindig sikerul az elso rmdev az uj release mar tartalmazza a megfelelo fixet... de hat ugy a customer policy, hogy nem hasznaljak a javitast... mert mindenhol ugyanazt hasznaljak.
Tudok olcsón bézbólütőt kölcsönözni. ;)
Azért érdekelne a konstelláció, hogy mi közöd van a rendszerhez? Láthatóan egy dilettáns jól elcseszte, majd megkaptad mint ajándékot a javítás lehetőségét?
Az utot megkoszonom :) Bar ma jobban kellett volna a nagy kek egyik TL-jehez ... :)
Mi a kozom ?
A mi szoftverunk is fut rajta. A T. Nagy Kek pedig nem mindig van a helyzet magaslatan es konnyebb a developereket zaklatni (nem az AIX developereket), hogy oldjunk meg olyan problemat ami nem is a mienk elsosorban (itt azert mi is sarasak vagyunk).
De altalanosan mondhato, hogy a nagy IT cegek problema megoldasa kimerul abban (sokszor a bejovo segitsegkeres is), hogy valami nem mukodik es tobb levelvaltasba kerul, hogy kideruljon olyan informacio, hogy milyen OS, milyen verzio es mi a hibauzent ...