NevemTeve's blog

recv gondja: errno=113 EHOSTUNREACH

Vajon előfordulhat-e, hogy azt mondja a 'read' (avagy 'recv'), hogy EHOSTUNREACH = No route to host?

A jelek szerint igen, meg is lepte a programocskámat... Most az egyszer nem tudom az egzotikus platformot hibáztatni, CentOs 6.4, x86_64

Asszem az lesz a legjobb megoldás, ha azt a default programágat, ahol az 'ez a hiba nem fordulhat elő' van, szépen kiszedem, és helyette az 'ezt a kapcsolatot megette a fene' nevű ágat használom az 'egyéb hiba' esetén...

Pillanatnyi állapot:
[code]
rc2 = soc_errno;
len = 0;
switch (rc2) {
case SCEWOULDBLOCK:
if (mcb.rdebuglevel>1) {
S3I_DebugLineT ("S3IR_read_soc(%d): WOULDBLOCK\n"
, (int)rdp->pio->sock);
}
rc = S_RD_NODATA; /* nincs mit olvasni */
break;

MySql AIX-on part 5/9

Szóval a collect2 problémáján elegánsan túllendülünk a '-berok' opcióval, és áttérünk a következő problémá(k)ra.

Ugyebár a libtool ellenkezik a cmake-hit tanításaival, ő kézi erővel állítja el a statikus és a shared libet. Persze amíg van sed és perl, ez kezelhető, de azért zavar tud hozni egy-két apróság:

1. duplikált könyvtárak a linkelésnél (talán csak a hangsúly kedvéért):

        -o libmysqlclient.so\
        CMakeFiles/libmysql.dir/libmysql_exports_file.cc.o\
        -lpthread libclientlib.a ../dbug/libdbug.a ../strings/libstrings.a\
        ../vio/libvio.a ../mysys/libmysys.a -lz\
        /usr/local/lib/libssl.so\
        /usr/local/lib/libcrypto.so\
        /usr/local/lib/libcrypto.so\
        ../dbug/libdbug.a ../mysys/libmysys.a ../strings/libstrings.a\

Mindegy, a shared lib jól jön létre. Remélem, legalábbis.

AIX: linkelési hiba -- túlbuzgó collect2

Úgy tűnik nekem, hogy AIX-on a collect2 olyan konstruktorokra/destruktorokra is lecsap, amelyek ott vannak ugyan a *.a fájlban, de a konkrét executabléba nem kellenének. A példaprogram:


/* collect2_main.cc */

#include <cstdio>

int main ()
{
    fprintf (stderr, "A főprogram vagyok, semmi különös\n");
    fflush (stderr);
}

Futásának eredménye, ha csak úgy 'normálisan' linkeljük:

$ ./collect2_prob
A főprogram vagyok, semmi különös

Ha hozzálinkelünk egy másik objektet, amit nem hívunk és nem használunk ugyan, de amiben van egy globális objektum, akkor annak azért lefut a konstruktora (AIX-on és linuxon is):

$ ./collect2_prob_o
HibaProvokalo: Nekem qrvára nem kellene futnom
A főprogram vagyok, semmi különös

MySql AIX-on: ki az a collect2?

Az előző adás folytatása: a g++ nem a 'ld' (sem a 'gld') nevű programot hívja, hanem az /opt/freeware/libexec/gcc/*/*/collect2-t. (Mondjuk a név nem ismeretlen, hiszen linuxon tényleg ő szokta kiírni a linkelési hibákat.)

Talán az lenne a legjobb, ha ennek a collect2-nek lenne valamilyen kimenete, amiben meggyónná, hogy mit és miért csinál. No, majd keresgélek.

MySql AIX-on: halad, csak lassan...

Mostanra eljutottunk odáig, hogy a __fe_def_env miatt nincs duplikált szimbol, de azért még nem áll össze a 'myisam_ftdump'


ld: 0711-224 WARNING: Duplicate symbol: ._mi_report_crashed
ld: 0711-344 See the loadmap file loadmap for more information.
ld: 0711-317 ERROR: Undefined symbol: THR_THD
ld: 0711-317 ERROR: Undefined symbol: vtable for handler
ld: 0711-317 ERROR: Undefined symbol: key_map_empty
ld: 0711-317 ERROR: Undefined symbol: opt_myisam_use_mmap
...

MySql fordítás -- WTF

Mármint a fordítás ezzel áll meg:


/usr/local/src/mysql-5.5.38/include/my_global.h: In function 'my_ulonglong2double':
/usr/local/src/mysql-5.5.38/include/my_global.h:289:74: error: expected ')' before 'A'

A kérdéses haeaderben:


/* Go around some bugs in different OS and compilers */
#ifdef _AIX /* By soren@t.dk */
#define _H_STRINGS
#define _SYS_STREAM_H
/* #define _AIX32_CURSES */ /* XXX: this breaks AIX 4.3.3 (others?). */
#define ulonglong2double(A) my_ulonglong2double(A)
#define my_off_t2double(A)  my_ulonglong2double(A)
C_MODE_START
inline double my_ulonglong2double(unsigned long long A) { return (double A); }
C_MODE_END
#endif /* _AIX */

Ez most szándékos? Vagy lekváros?

Sony DVP-SR370

Sony DVP-SR370 gyártmányú lejátszón próbálok DVD-ről mencoder-elt AVI fájlt lejátszani, a következő rendkívül kifinomult hibaüzenet jön:

Data error (VIDEO)

A leírás szerint:

Lejátszható fájlformátumok
Videó: MPEG-1 (Cyber-shot adat)/MPEG-4 (simple profile)/Xvid
Fénykép: JPEG (DCF formátum)
Zene: MP3 (kivéve mp3PRO)/WMA(kivéve WMA Pro)/AAC/LPCM/WAVE
Használható kiterjesztések: „.avi”,„.mpg”, „.mpeg”, „.mp4”,,„.jpg”, „.mp3”,„.wma”, „.m4a”, „.wav”

Nekem már csak azt kell kitalálnom, hogy mi az a 'simple profile', meg hogy hogyan kell azt a mencoder-ből kirázni. (Maga a fájl nem lehet teljesen rossz, lejátszható számítógépen (Windows, Linux különféle programok) és srt8105-ös STB-n is)

Pelikán elvtárs, a mplayer nem habostorta!

Például crop-olni szeretnék (-vf crop=w:h:x:y), mplayer-ben megy, mencoder-ben segfault... Most fordul debug-gal, majd referálok az eredményről.

20140730.1749 Hát ennyit mondott:


#0  0x08126d97 in draw_bottom_blackbar_slice (y=<optimized out>, 
    x=<optimized out>, h=<optimized out>, w=<optimized out>, 
    stride=<optimized out>, src=<optimized out>, vf=<optimized out>)
    at libmpcodecs/vf_expand.c:366
#1  draw_slice (vf=0x928abb0, src=0xffffc694, stride=0xffffc700, w=720, h=16, 
    x=0, y=0) at libmpcodecs/vf_expand.c:402
...

20140730.1918 Tehát optimalizáció nélkül kellene fordítani... az sem triviális, mert a beágyazott ffmpeg egyik programja nem fordul optimalizáció nélkül: kifogy a gcc a regiszterekből.

új PHP, új gond

PHP-5.4.30 nem fordul, pontosabban a libphp5.la linkelése nem sikerül:


ld: 0711-317 ERROR: Undefined symbol: .tgetnum
ld: 0711-317 ERROR: Undefined symbol: .tputs
ld: 0711-317 ERROR: Undefined symbol: .tgoto
ld: 0711-317 ERROR: Undefined symbol: .tgetstr
ld: 0711-317 ERROR: Undefined symbol: .tgetent
ld: 0711-317 ERROR: Undefined symbol: .tgetflag

Ez egy AIX-6.1, legutóbb a PHP-5.4.27 fordult rajta; a kérdéses szimbóleumok a /usr/lib/libcurses.a-ból kellene jöjjenek.

Szerk: No, úgy látszik, a múltkori readline probléma volt emögött is: amióta a readline-ból nem csinálunk libreadline.so-t (tehát csak statikus libreadline.a készül), a libtool (házilag utángyártott vacak!) nem írja bele a libreadline.la-ba, hogy függ a libcurses-től.

pthread vagy pthreads

Nagyon úgy tűnik, hogy ismét egy apróságon pörgök, de mintha AIX-on a 's'-végű lenne a szabvány/szokvány; linux-on meg a másik.
A gcc opció mindkét esetben -pthread, de a shared lib, amit beleszerkeszt, különbözik:

AIX: /usr/lib/libpthreads.a(shr_xpg5_64.o)
linux:(NEEDED) Shared library: [libpthread.so.0]

20140610.2115: tehát a megfejtés: ahol lehet, ott a -lpthread(s) helyett -pthread legyen, ahol nem lehet (mondjuk direktben hívjuk a ld-t valamilyen spec esetben), ott el kell ágazni platform szerint.

mc, TERM=linux, gpm, jajjanyám

20190406
És ha rákattintunk a linkre, azt látjuk, hogy (remélhetőleg) közel a megoldás!
http://midnight-commander.org/ticket/3208

20170611
Úgy nézem, akkor lép fel, ha TERM=putty-256color... Na most jön a --without-gpm-mouse
Szerk: téves riasztás, volt a gépemen egy ősrégi /usr/bin/mc[edit], az indult el tévedésből ($EDITOR volt ráálítva)

20170609
Na ez miez (végtelen sok ismétlődéssel az 'user-log'-ban, Debian8/mc-4.8.17):


Jun  7 11:46:52 z-pc mcedit: Warning: closing connection
Jun  7 11:46:52 z-pc mcedit: *** info
Jun  7 11:46:52 z-pc mcedit: Warning: closing connection

find -- ez most kiszúrás, vagy csak szórakozik velem?

find . -name Makefile -exec echo {}.extension \;

Ez a find-parancs AIX5.3-on a következőt generálja:

{}.extension
{}.extension
{}.extension

Na ez most kiszúrás, vagy csak szórakozik velem?

20140508.0508: Köszönöm a hozzászólásokat, azóta működik a kerülő-módszerrel ( vagyis átirányítással egy 'while read FILENAME; do'-ba)

git=szenya

Vagy hasonló. Például Harry Potter ellenszenves tanárát 'greasy git'-ként emlegetik. Ennél nagyobb gondom, hogy a git-1.9.2 ellenáll a fordításnak az egyik AIX-os gépemen. A következő apróságok örvendeztettek meg:

1. a make distclean törli a configure-t. Szerintem inkább a Makefile-t kellene törölnie, de hát ahány ház, annyi szokás; megoldjuk:

sed_repl 's/^  \$(RM) configure/   # $(RM) configure/' Makefile

2. Nem használja a libtool-t. Megoldás:

make ... QUIET_LINK='aix-libtool --mode=link ' ...

3. Van neki egy xdiff/lib.a nevű komponense, ami provokál egy hibát az aix-libtool-ban (Ugyanis az levágja a név elejéről a 'lib' prefixet, és rémülten szembesül az üres névvel.) Aix-libtool javítva.

libtool újabb kalandjai...

Nem fordul a gettext... már számtalanszor lefordult, de most nem, megpusztult a configure a libiconv keresésénél...
És végül kiderült, hogy ki a hibás. Hát én, természetesen. Nem tudtam, hogy a configure script a libtool *.la fájlját (esetünkben a /usr/local/lib/libiconv.la-t) shell-scriptként akarja feldolgozni!
Vagyis abban nem lehet ám akármi, csak változó=érték hozzárendelések, és #kettőskereszttel bevezetett megjegyzések... Persze ennek egy jó kis kapkodás közben kellett előkerülnie, semmiképp sem valami békés pillanatban...

sshd: key_parse_private2: missing begin marker

Ez mi ez?


debug1: sshd version OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker

Egyelőre annyit látok, hogy van egy authfile.c és abban egy key_parse_private2 függvény.

20140326.1643 Mintha az lenne, hogy a [/usr/local]/etc/ssh-beli ssh_host_*_key fájlokban a fejléc/lábléc lenne hibás:

ez van:

-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

ezt várja:

-----BEGIN OPENSSH PRIVATE KEY-----
-----END OPENSSH PRIVATE KEY-----

Na, akkor átírom, és meglátjuk, mi törpénik...

LC_CTYPE: ISO-8859-2 vagy ISO8859-2

Újabb nagy diadala a szabványoknak és az együttműködésnek: egyik unix így szereti, a másik meg amúgy... Ha én meg ssh-ból megyek egyikből a másikba (vö: SendEnv és AcceptEnv), akkor vagy jó lesz a másikfajta, vagy nem. Hirtelen ennyit tudok javasolni megoldásként:

http://web.axelero.hu/lzsiga/ekezet.html#Q0094

20140127.1003: És ehhez egy kis kiegészítés

http://web.axelero.hu/lzsiga/ekezet.html#Q0096

Oracle TCP_KEEPALIVE nélkül?

2017.02.27. 10:46
Említsük meg, hogy AIX-on a könnyen googlizható nevű "no" segédprogrammal lehet a TCP_KEEPALIVE időzítését hangolni.


$ /usr/sbin/no -a | grep keep
                ndpt_keep = 120
              tcp_keepcnt = 8
             tcp_keepidle = 14400 # = 2 óra
             tcp_keepinit = 150
            tcp_keepintvl = 150
# /usr/sbin/no -o tcp_keepidle=120 #  = 60 sec (félmásodperces egységben)

2014.03.14. 15:53
Továbbá szerveroldalon: sqlnet.ora-ban sqlnet.expire_time=<perc>

2014.03.14. 15:20
Aki keres az talál: a leírás szerint a tnsnames.ora-ban az description=(enable=broken) való erre! Mindjárt kipróbálom.

Szemaforok -- van választék

A múltkori eset után picit utánaolvastam a szemaforoknak, és egy kis táblázatot alkottam: itt látható..

Már írtam is hozzá egy kis kiegészítést: a SsystemV IPC-nek szerencsés tulajdonsága, hogy ha használjuk a SEM_UNDO opciót, akkor egy váratlan leállás sem tudja zárolva hagyni a szemafort, ami viszont megtörténhet a POSIX-os szemaforral.

Bepörög az Apache az imagick-tól

Ez most csak egy emlékeztető magamnak, hogy ismét akadt egy kis nyomoznivaló...

Komponensek:

AIX 6.1 (oslevel 6100-09)
Apache httpd-2.4.7
PHP-5.4.24
ImageMagick-6.8.8-4
imagick-3.1.2

Hibajelenség:

A 'phpinfo()' elég a hiba bemutatásához, de csak Apache-on át, standalone-ban jó.
Úgyszintén jó, ha httpd -X paranccsal futtatom.
Akkor is, ha nincs a php.ini-ben az extension=imagick.so.
Amikor nem jó, akkor valamiféle végtelen ciklusban pörög, a truss-ból egyelőre ennyit láttam, hogy némelyik process valamiféle szemaforra vár (_sem_wait), és folyamatosan pörög Err#13 (EACCES) hibával... A többi process logjai alapján olyasmi érzésem van, hogy az egyik process (nyilván a 'főnök') lezárta (sem_destroy) a szemaforokat, amit a gyermekek sem_wait-je EACCES-ként jelez?

új Apache, új gondok...

Komponensek:

AIX-5.2
httpd-2.4.7
apr-1.5.0
apr-util-1.5.3

Problémás rész:

/usr/local/src/httpd-2.4.7/srclib/apr/libtool --silent --mode=link \
    gcc  -pthread  -mtune=native -maix32 -std=c99 \  
        -Wl,-brtl  -L/usr/local/lib -lcpotlas -Wl,-brtl,-brtllib -lrtl \
        -Wl,-blibpath:/usr/local/lib:/usr/lib:/lib -Wl,-brtl \   
        -o mod_cache_socache.la \
        -Wl,-bI:/usr/local/src/httpd-2.4.7/server/httpd.exp \
        /usr/local/src/httpd-2.4.7/srclib/apr-util/libaprutil-1.la \
        -rpath /usr/local/libexec/apache2 -module -avoid-version \
        mod_cache_socache.lo

OpenSsl reloaded

openssl-ék szerint az 1.0.1 az már nem olyan, mint a 0.9.8, hogy minden alverzió inkompatibilisnek számít. Nem, itt már az 1.0.1 kompatibilis az 1.0.0-lal.

Normálisan ilyenkor a verziószámot major+minor részre bontják, a major változása inkompatibilis fejlesztést jelent, a minor változása kompatibiliset (vagyis újrafordítás/szerkesztés nélkül használható az új) pl:

major=1.0.1g minor=(üres)
major=1.0.1 minor=g
major=1.0 minor=1
major=1.0 minor=1g
stb

Hát OpenSsl-éknél ez nem így van, ők azzal fejezik ki a kompatibilitást, hogy a majort 1.0.0-ra állítják, minor nincs. Először hallgattam a jobbik eszemre, és meghaxoltam a Makefile-t 1.0.1-re, de ma a kompatibilitás mián azt mondtam, hogy jó,legyen major=1.0.0, minor=1.0.1f (hogy azért mégis maradjon valami jele annak, hogy milyen verzió ez).

gdb-vel kavarok

egyik gép (linux; gdb-7.5.1) így írja ki a shared libeket:

From        To          Syms Read   Shared Object Library
0xf7fe1830  0xf7ff7c8f  Yes (*)     /lib/ld-linux.so.2
0xf7fc1a40  0xf7fc2988  Yes (*)     /lib/i686/cmov/libdl.so.2
0xf7e90a80  0xf7f8647c  Yes (*)     /lib/i686/cmov/libc.so.6

Nem rossz, de lehetne jobb: ha kiírná az adatterületeket is.

másik gép (AIX; gdb-7.3):

Text Range              Data Range              Syms    Shared Object Library
0xd052d240-0xd052da3e   0xf0828608-0xf0828730   Yes     /usr/lib/libcrypt.a(shr.o)
0xd0aecc80-0xd0aecdb6   0xf101acc0-0xf101ad30   Yes     /usr/lib/librtl.a(shr.o)
0xd0118680-0xd04ed13b   0xf0759130-0xf0827ba0   Yes     /usr/lib/libc.a(shr.o)
0xd05df21c-0xd05df2d8   0xf02a50f8-0xf02a50f8   Yes     /usr/lib/libdl.a(shr.o)
0xd1ca3150-0xd1ca70d2   0xf117b12d-0xf117b404   Yes     /usr/local/lib/libcpotlas.so

backspace ^H vagy ^?

De komolyan, olvtársak, hogy van az, hogy az elmúlt 40-50 év még nem volt elég ahhoz, hogy megnyugtatóan rendeződjön ez a mélységesen mély probléma?

Most ne mondjuk azt, hogy a bash/readline/mc/egyéb program tök jól kezeli mindkettőt, hanem vegyük elő a legfelhasználóbarátságtalanabb programunkat (pl dash, ksh), és nézzük meg, hogy abban működik-e a BackSpace, vagy esetleg megjelenik helyette egy ^H vagy ^? szekvencia.

Többé kevésbe megoldás az, ha valamilyen profile-ba beteszünk valami ilyesmit: stty erase $(tput kbs), de miért nem történik ez automágikusan, amikor a telnetd (vagy hasonló) létrehozza a virtuális terminált? Nem találták a tcsetattr-nál a c_cc[VERASE]-t vagy a tgetstr("kb") lett volna túl nehéz?

Win16-os hibakeresés

Valamit elronthattam, debuggolni kellene. Ahogy látszik a dolog, Assembly szinten kellene nézelődni (A function-prolog lehet rossz. Talán.)... Sajnos a jó öreg BorlandC4.5-höz tartozó TDW nem indul el. Google barátom az OpenWatcom-ot ajánlotta, annak van 16-bites fordítója és debuggere is. Kipróbáltam, tényleg van.
Sajnos megpusztul azon a ponton, amikor 'huge' pointerrel kellene matekoznia.
Ez a forrásprogram, a memory model large, a szerkesztésnél a lib286\clibl -t használom [szerk: itt korábban tévesen 'clibc' állt -- akkor legalább meglenne a hiba], ennek ellenére a __PIA úgy fut(na) le, hogy a DS-t nem állítja be, vagyis mintha nem tudná, hogy 'large' modellben vagyunk...