LINUX.ORG.RU

На ядре 2.6.12 перестал запускаться gkrellm


0

0

gkrellm-2.2.4
Если серьезно, то мне по барабану сей трабл. Просто есть мысль что дело не в самом gkrellm и сии фокусы могут затронуть и другие приложения и не только сами их. xterm же не был виной, когда вышло ядро 2.6.8
Как это происходит:
при запуске gkrellm из коммандной строчки, исчезает диалог приглашения, как будто прога запущена, так и висит курсор в самом начале, но прога не запускается. Далее ctrl+c. Да. Если не снимать запуск а ждать, то все же через минут 10 прога запускается.
В логах чистота. По gdb, тоже.

Странно, что нигде не обсуждается эта проблема.
Замечено на трех машинах совершенно разных конфигураций и версий сей проги.

anonymous

Кстати, не важно, откуда запускать приложение. Хоть, из-под рута, хоть из-под обычного пользователя. Прога чего-то ждет перед стартом. Долго ждет.

anonymous
()
Ответ на: комментарий от anonymous

еще. Ядро также пропатчено до 2.6.12.1
результат = 0

anonymous
()

Fedora Core 3, gkrellm 2.2.2 - такого эффекта не наблюдается. Посмотри через strace, где она ждет.

P.S.: у тебя точно все нормально с DNS?

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

заедает вот здесь>
...
...
munmap(0xb7549000, 4096) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(7634), sin_addr=inet_addr("127.0.0.1")}, 16


++++++++++++++++++++++++++++++++++++
#ifconfig
eth0 Link encap:Ethernet HWaddr 01:8C:88:43:D2:E3
inet addr:195.34.177.95 Bcast:195.34.177.255 Mask:255.255.255.0
inet6 addr: fe83::21d:88ff:fe33:c0e2/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12403 errors:0 dropped:0 overruns:0 frame:0
TX packets:3128 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3733943 (3.5 Mb) TX bytes:411041 (401.4 Kb)
Interrupt:16

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4456 errors:0 dropped:0 overruns:0 frame:0
TX packets:4456 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3726978 (3.5 Mb) TX bytes:3726978 (3.5 Mb)

то бишь, с петлей вроде как проблем нет..

resolv.conf тоже в поряде. адреса верные

anonymous
()
Ответ на: комментарий от anonymous

да и до 2.6.12.1, на 2.6.11.12 все было ок.
Переехать-то перееду, но интререстно всеж, что это.

пересобран по принципу
#!/bin/bash
VERSION=2.6.12.1
cd /usr/src/linux/;
make oldconfig; #(отказываемся от ненужных новведений)
make;
make modules_install;
cp arch/i386/boot/bzImage /boot/vmlinuz-$VERSION;
cp config /boot/config-$VERSION;
cp System.map /boot/System.map-$VERSION;
cd /boot/;
mkinitrd -c -k $VERSION;
depmod -a;
lilo;

anonymous
()
Ответ на: комментарий от anonymous

замечена любовь сетевухи с видюхой
cat /proc/interrupts
CPU0
0: 7855611 IO-APIC-edge timer
1: 10170 IO-APIC-edge i8042
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 403514 IO-APIC-edge i8042
14: 83518 IO-APIC-edge ide0
15: 112166 IO-APIC-edge ide1
16: 491614 IO-APIC-level eth0, radeon@pci:0000:01:00.0
18: 2 IO-APIC-level ohci1394
19: 28 IO-APIC-level uhci_hcd:usb1
22: 374025 IO-APIC-level SB Live
23: 0 IO-APIC-level uhci_hcd:usb2
NMI: 0
LOC: 7856437
ERR: 0
MIS: 0

раньше такого в APIC не было. все распределялось.


помогло переставление.

Однако, с gkrellm проблема осталась. один в один.

anonymous
()
Ответ на: комментарий от anonymous

Такое чувство, что этой проге что-то где-то "внизу" самого ядра не нравится..
Остальное ПО вертится.
Блин... Знать бы что... Но я не шипко в этом разбираюсь

Самое смешное, что работаю в fluxbox, а вызов KDEшных прог стал происходить на много быстрее, чем раньше даже в первый раз вызова. Да и остальной софт шустрее работать стал. Не замечал такого раньше.



Люди, помогите пожалуйста

anonymous
()
Ответ на: комментарий от anonymous

Замечена еще одна неприятность.
GTK-based приложения ведут себя странно.
stardict отказывается закрываться.
на 2.6.11.x такого не было

anonymous
()
Ответ на: комментарий от anonymous

Перешел обратно на 2.6.11.12

все встало на свои места.

anonymous
()
Ответ на: комментарий от anonymous

> connect(6, {sa_family=AF_INET, sin_port=htons(7634), sin_addr=inet_addr("127.0.0.1")}, 16 )

А вот это как-то странно. А ну-ка если сделать iptables -A -p tcp --destination-port 7634 -j REJECT ???

no-dashi ★★★★★
()
Ответ на: комментарий от Selecter

iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW

Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

anonymous
()
Ответ на: комментарий от anonymous

rc.firewall

/usr/sbin/iptables -F;
/usr/sbin/iptables -t nat -F;
/usr/sbin/iptables -t mangle -F
/usr/sbin/iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 195.34.177.95
/usr/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/usr/sbin/iptables -A INPUT -m state --state NEW -i ! eth0 -j ACCEPT
/usr/sbin/iptables -P INPUT DROP
/usr/sbin/iptables -A FORWARD -i eth0 -o eth0 -j REJECT

anonymous
()
Ответ на: комментарий от anonymous

>А вот это как-то странно. А ну-ка если сделать iptables -A -p tcp --destination-port 7634 -j REJECT ???

нихрена ровным счетом не меняет

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.