Angeregt durch den Heldenfeed, hier meine Liste der Software-Werkzeuge mit denen ich meinen Job meistere:
Editor: Emacs 23
Schnell&Einfach Editor: vi oder ed (letzteren gerne auch verscripted)
Shell: ksh93 - Davids Shell im vi Mode ist einfach super smart
Browser: Firefox
Mail-Client: gnus.el in Emacs, Outlook im Citrix (leider)
Aufgaben-Verwaltung: org-mode...im Emacs ;)
Allzweck-Waffe: Emacs ,) (mit tramp-mode in Verbindung mit ediff-directories ergeben sich irre Möglichkeiten - recursive diff von Property-Files auf verschiedenen Systemen...)
Versionsverwaltung: subversion, mercurial
Compiler: Sun Studio 11/12, selten gcc
Datenbank: PostgreSQL
OS: Solaris
Performance-Datensammlung: Home-grown psql+sar+ksh+CGI -> LoadDB
Bei mir zuhause sieht es nicht viel anders aus - ausser das es noch einen Mac gibt mit dem das ein oder andere Urlaubsvideo geschnitten wird.
Und auf meinem Server läuft ein
OS: OpenIndiana
WebServer: Apache 2.2
CMS: Magnolia
Mail: Dovecot/sendmail
ba,pnt ;)
Montag, 30. Januar 2012
Mittwoch, 10. August 2011
exec() umbiegen mit dtrace
Um unliebsame Programmaufrufe zu verhindern, ohne an den Programmen selber Modifikationen vornehmen zu müssen eignet sich auch dtrace.
(607) oldn90700:/home/olbohlen$ cat foobar.ksh
#!/bin/ksh
echo true
(608) oldn90700:/home/olbohlen$ ./foobar.ksh
August 10, 2011 03:02:18 PM CEST
Wie geht das?
Man schaltet für DTrace den destructive mode ein und fängt mittels syscall provider die exec* syscalls ab zum entry Zeitpunkt. Dann modifiziert man arg0 für den exec() und das wars dann auch schon:
Sehr spannend was DTrace alles kann :)
(607) oldn90700:/home/olbohlen$ cat foobar.ksh
#!/bin/ksh
echo true
(608) oldn90700:/home/olbohlen$ ./foobar.ksh
August 10, 2011 03:02:18 PM CEST
Wie geht das?
Man schaltet für DTrace den destructive mode ein und fängt mittels syscall provider die exec* syscalls ab zum entry Zeitpunkt. Dann modifiziert man arg0 für den exec() und das wars dann auch schon:
(717) oldn90700:/root# cat preve*
#!/usr/sbin/dtrace -s
#pragma D option destructive
syscall::exec*:entry
/copyinstr(arg0) == "./foobar.ksh" /
{
printf("exec arg0: %s\n", copyinstr(arg0));
copyout("/usr/bin/date", arg0, 14);
}
#!/usr/sbin/dtrace -s
#pragma D option destructive
syscall::exec*:entry
/copyinstr(arg0) == "./foobar.ksh" /
{
printf("exec arg0: %s\n", copyinstr(arg0));
copyout("/usr/bin/date", arg0, 14);
}
Sehr spannend was DTrace alles kann :)
Freitag, 15. Juli 2011
VMware ESX, SLES11, virtuelle IPs
Notiz für mich zum erinnern:
Verwendet man zusätzlichen IP Adressen in der VMware auf den virtuellen NICs, so gibt es offenbar massiv Stress mit IP Kommunikation. Die OpenDS LDAP Server haben regelmässig die Replications verloren...
Kennt das sonst noch jemand?
Verwendet man zusätzlichen IP Adressen in der VMware auf den virtuellen NICs, so gibt es offenbar massiv Stress mit IP Kommunikation. Die OpenDS LDAP Server haben regelmässig die Replications verloren...
Kennt das sonst noch jemand?
Freitag, 1. April 2011
OpenIndiana NWAM
Beim Versuch unter JDS in OpenIndiana dem NWAM eine statische IPv6 Adresse zu konfigurieren, musste ich erleben das der Eintrag offenbar nicht zieht, sprich das Feld leer ist und auch nicht in die Config übernommen wird.
Work-Around:
cd /etc/nwam
vi ncp-.conf
und dann in der Config-Zeile fürs korrekte Interface (bei mir e1000g0) ein
"ipv6-addr=string,2001:dead:beef:feed:face::50/80 eintragen.
Danach einmal die Location wechseln und schon zieht NWAM.
Work-Around:
cd /etc/nwam
vi ncp-
und dann in der Config-Zeile fürs korrekte Interface (bei mir e1000g0) ein
"ipv6-addr=string,2001:dead:beef:feed:face::50/80 eintragen.
Danach einmal die Location wechseln und schon zieht NWAM.
Solaris Internals...
Nächste Woche komm ich bei BOS-IT in Hamburg in den Genuss von Max Bruning der eine Woche lang Dinge aus dem Innenleben unseres Lieblings-OS erzählen wird!
Ich freu mich drauf :)
Ich freu mich drauf :)
Freitag, 25. März 2011
ps -ef hängt?
Wenn ps -ef "hängt" wirds ersteinmal nicht ganz einfach herauszufinden, welcher Prozess dafür verantwortlich ist. Meisstens hängt ein bestimmter Prozess, was es ps unmöglich macht unter /proc/PID/ die Prozessstruktur zu lesen. ps printed dann leider nicht mehr die Zeile mit de entsprechenden PID.
Es gibt aber einen schönen Hack:
cd /proc
(for pid in *; do echo $pid; file $pid/auxv >/dev/null 2>&1; done) &
Die letzte ausgegebene PID ist unser Kandidat. An dieser Stelle verweise ich auf meinen letzten Blog Eintrag, wie man per mdb weitere Schlüsse ziehen kann.
Es gibt aber einen schönen Hack:
cd /proc
(for pid in *; do echo $pid; file $pid/auxv >/dev/null 2>&1; done) &
Die letzte ausgegebene PID ist unser Kandidat. An dieser Stelle verweise ich auf meinen letzten Blog Eintrag, wie man per mdb weitere Schlüsse ziehen kann.
Mittwoch, 23. Februar 2011
hanging process on solaris
Got a hanging process on Solaris 10 today.
It was a netbackup process writing to a tape-device with the PID 19177.
So I fired up mdb -k:
> 0t19177::pid2proc |::walk thread |::findstack -v
stack pointer for thread 30007a49800: 2a1053acb41
[ 000002a1053acb41 sema_p+0x138() ]
000002a1053acbf1 biowait+0x6c(3007eeae0c0, 0, 183fc00, 30005620000, 45c,
3007eeae0c0)
000002a1053acca1 st_cmd+0x2ec(210000045c, 11, 0, 44, 60049bd1dc0, 3007eeae0c0
)
000002a1053acd91 st_space_fmks+0xc4(210000045c, 0, 60049bd1dc0, 1e3, 45c, fc00
)
000002a1053ace41 st_mtioctop+0xb88(60049bd1dc0, 1e3, 0, 100003, 0, 0)
000002a1053acf11 st_ioctl+0xbc8(210000045c, 60049bd1dc0, ffbfa4d0, 100003,
6005a9704d8, 6d01)
000002a1053ad0e1 fop_ioctl+0x20(6003623d580, 6d01, ffbfa4d0, 100003,
6005a9704d8, 1282a58)
000002a1053ad191 ioctl+0x184(b, 3007927e7a8, ffbfa4d0, 563000, 563000, 6d01)
000002a1053ad2e1 syscall_trap32+0xcc(b, 6d01, ffbfa4d0, 563000, 563000, 0)
The first argument to st_ioctl is an dev_t, so we use ::devt to figure out major and minor:
> ::devt 210000045c
MAJOR MINOR
33 1116
So, 33 is the st driver as assumed, and 1116 is device /dev/rmt/164*.
After calling the backup guys, they found out that the tape in this drive broke and caused the hanging IO. After resetting the drive and removing the tape, the process terminated as expected.
It was a netbackup process writing to a tape-device with the PID 19177.
So I fired up mdb -k:
> 0t19177::pid2proc |::walk thread |::findstack -v
stack pointer for thread 30007a49800: 2a1053acb41
[ 000002a1053acb41 sema_p+0x138() ]
000002a1053acbf1 biowait+0x6c(3007eeae0c0, 0, 183fc00, 30005620000, 45c,
3007eeae0c0)
000002a1053acca1 st_cmd+0x2ec(210000045c, 11, 0, 44, 60049bd1dc0, 3007eeae0c0
)
000002a1053acd91 st_space_fmks+0xc4(210000045c, 0, 60049bd1dc0, 1e3, 45c, fc00
)
000002a1053ace41 st_mtioctop+0xb88(60049bd1dc0, 1e3, 0, 100003, 0, 0)
000002a1053acf11 st_ioctl+0xbc8(210000045c, 60049bd1dc0, ffbfa4d0, 100003,
6005a9704d8, 6d01)
000002a1053ad0e1 fop_ioctl+0x20(6003623d580, 6d01, ffbfa4d0, 100003,
6005a9704d8, 1282a58)
000002a1053ad191 ioctl+0x184(b, 3007927e7a8, ffbfa4d0, 563000, 563000, 6d01)
000002a1053ad2e1 syscall_trap32+0xcc(b, 6d01, ffbfa4d0, 563000, 563000, 0)
The first argument to st_ioctl is an dev_t, so we use ::devt to figure out major and minor:
> ::devt 210000045c
MAJOR MINOR
33 1116
So, 33 is the st driver as assumed, and 1116 is device /dev/rmt/164*.
After calling the backup guys, they found out that the tape in this drive broke and caused the hanging IO. After resetting the drive and removing the tape, the process terminated as expected.
Abonnieren
Posts (Atom)