Re: lug-bg: POSTGRES "truncate all"

[Georgi Chorbadzhiyski]

Yavor Doganov wrote:
> On Tue, Jun 14, 2005 at 06:56:59AM +0300, Daniel Ivanov wrote:
> 
>>Става. Но си го написах на перлата.
> 
> При добро желание може и да споделиш, както е направил Георги
> Чорбаджийски.

Решението е същото на на шела, тънкостта е в заявката към системните таблици,
която ти вади списъка с потребителските таблици в дадена база.

-- 
Georgi Chorbadzhiyski
http://georgi.unixsol.org/

Re: lug-bg: X server refresh rate 100 Hz

[Валентин Стойков]

На 13.6.2005 13:58 [EMAIL PROTECTED] написа:
> Здравейте група,
> след многократни проби и безуспешно лутане по форумите, реших да пиша.
>  Проблема е, че X-a не вдига над 80 Hz (refresh rate), а монитора поддържа
> 100. Под уиндолс си ги държи стабилно, дори вдига 120, на 1024х768. Под
> линукс обаче неще. Видеокартата е Nvidia GF 440МХ,vsync и horizsync са
> настроени според документацията на монитора. И ranges i твърдо задаване на
> хоризонталната е пробвано, но неще. Има ли някакъв начин да се вдигне
> refresh-a?

На мен винаги ми е вършила работа програмата ddcxinfo-knoppix.

Виж какво е писано на този адрес:


Цитат от там:
-- начало --
Секцията Monitor може да я напише програмата
ddcxinfo-knoppix, стартирана така:

Примерен код

ddcxinfo-knoppix -monitor


После трябва само да редактираш Identifier-а и си готов.
Тази програма, ако те мързи да я инсталираш може да я намериш в Knoppix и VS 
Live.

Има я компилирана и готова за ползване тук:
http://d.interbild.net/vstoykov/tmp/ddcxinfo-knoppix

След като я изтеглиш се инсталира така:

Примерен код

su
chown root.root ddcxinfo-knoppix
chmod +x ddcxinfo-knoppix
mv ddcxinfo-knoppix /usr/sbin



Ако искаш секцията Monitor да се запише във файл (от който чрез cut/paste да 
преместиш кода в xorg.conf):

Примерен код

ddcxinfo-knoppix -monitor > име_на_файл.txt

-- край -


А това е най-удобния начин, по който създавам xorg.conf в Slackware:

Ще го копирам тук:

 начало --
---
Създаване на xorg.conf на Slackware
~~~

Инсталирайте тези пакети:

http://d.interbild.net/vstoykov/slackware-packages/hwsetup/ddcxinfo-knoppix-0.6_5-i686-vslive1.tgz
http://d.interbild.net/vstoykov/slackware-packages/hwsetup/hwsetup-1.0.14.vs2-i486-2.tgz
http://d.interbild.net/vstoykov/slackware-packages/hwsetup/hwdata_vs-0.148.1.1-noarch-0.tgz
http://d.interbild.net/vstoykov/slackware-packages/hwsetup/vsxorgconf-1.0-noarch-2.tgz

Командите за инсталирането им:

# installpkg ddcxinfo-knoppix-0.6_5-i686-vslive1.tgz
# installpkg hwsetup-1.0.14.vs2-i486-2.tgz
# installpkg hwdata_vs-0.148.1.1-noarch-0.tgz
# installpkg vsxorgconf-1.0-noarch-2.tgz

Спрете Xorg. Спрете GPM (ако е пуснат)
с командата (с права на root):

# /etc/rc.d/rc.gpm stop

Стартирайте hwsetup (с права на root):

# /sbin/hwsetup -p

Стартирайте скрипта vs-xorg.conf:

# vs-xorg.conf

Готово. Вече имате конфигурационен файл xorg.conf.

---

Ако желаете да настроите каква да бъде клавиатурната подредба
можете (преди да изпълните vs-xorg.conf) да създадете конфигурационен файл
"/etc/sysconfig/vslive" с такова съдържание:

--- начало на файла /etc/sysconfig/vslive --
vsConfig_Language=bg
vsConfig_KeyMap=phonetic
- край на файла /etc/sysconfig/vslive --

Горните настройки са за българска фонетична клавиатура.

Следващите са за българска бдс:
--- начало на файла /etc/sysconfig/vslive --
vsConfig_Language=bg
vsConfig_KeyMap=bds
- край на файла /etc/sysconfig/vslive --

Този скрипт се използва в дистрибуциите VS Live и VS Live mini-CD.
--- край --

Re: lug-bg: POSTGRES "truncate all"

[Yavor Doganov]

On Tue, Jun 14, 2005 at 06:56:59AM +0300, Daniel Ivanov wrote:

> Става. Но си го написах на перлата.

При добро желание може и да споделиш, както е направил Георги
Чорбаджийски.

-- 
Поздрави,
Явор Доганов

Re: lug-bg: ps ax|grep sth

[George Danchev]

On Monday 13 June 2005 14:04, Skeleta wrote:
> George Danchev wrote:
> >On Monday 13 June 2005 11:31, Vesselin Markov wrote:
> >>Всъщност, май не зависи от времето за изпълнение нито на ps, нито на
> >> grep. Иначе, при всяко положение grep се изпълнява по-бъзо от ps, но за
> >> да тръгне той, ps трябва да е приключил вече.
> >
> >Това е не вярно. При process1 | process2 ядрото стартира двата процеса
> >едновременно (осигурявайки им file descriptors, etc). Проблема е, че не се
> >знае кой ще разруши тръбата първи, например process2 приключва преди
> > process1 (прекратявайки съществуването на тръбата) тогава ядрото праща
> > сигнал SIGPIPE ( EPIPE ) [1] на process1 който го хваща и ако не е лейм
> > exit()-ва подобаващо, ако . Пример [2]. Работите за доста сложни и
> > понякога зависи дали се пише атомично в тръбата или не, колко е атомично
> > за дадена ОС и т.н. повече на [3].
>
> В обсъждания случай "ps | grep" и двата процеса се стартират
> едновременно, а пръв ще приключи ps, понеже grep ще чака затваряне на
> входния си файл. На практика за друг наблюдаващ процес и двата ще
> завършат едновременно. Поне на мен така ми се струва - самото
> приключване на ps при добре направено ядро трябва да прехвърли
> управлението директно на grep, което пък да си филтрира получения текст
> и също да приключи работа.

Мда, май не сме точни в това какво значи едновременно защото ядрото отделя 
внимание на процесите в timeslices[0] нищо, че може да са и в pipe. Значи 
ядрото много бързо пуска (RN) и приспива процесите (S) (състоянията ги има 
описани в man ps) от двете страни на pipe-a с дискрет най-малко а може и 
няколко един timeslice защото не са само те. Какво ще стане ако ps приключи 
преди да е изтекъл неговия timeslice /много рядко може да стане, но има и 
такъв шанс както се вижда и тогава в неговия изход няма да има grep /. Дали 
ще бъде поставен в състояние RN - Running or runnable / low-priority , а 
после и приспан  S /за да чака другия край /, а grep може ли да е (а може и 
да не е [1] ) все още стартиран камо ли пък поставен в състояние S - 
Interruptible sleep. А дали кернела в зависимост от това с какъв scheduler 
работи няма да реши, че има по-високо приоритетна задача с която да се заеме 
преди това. Все въпроси с ескалираща сложност и на които се притеснявам да 
отговоря, просто ей така ;-)

[0] http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=Timeslice&action=Search
[1] ако е SMP система, grep може да бъде стартиран на друго CPU1 в timeslice 
преди да е изтекъл timeslice на ps на CPU0, но след като този ps instance е 
завършил.


-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 

Re: lug-bg: ps ax|grep sth

[Skeleta]

George Danchev wrote:

  On Monday 13 June 2005 11:31, Vesselin Markov wrote:
  
  
Всъщност, май не зависи от времето за изпълнение нито на ps, нито на grep.
Иначе, при всяко положение grep се изпълнява по-бъзо от ps, но за да тръгне
той, ps трябва да е приключил вече.

  
  
Това е не вярно. При process1 | process2 ядрото стартира двата процеса 
едновременно (осигурявайки им file descriptors, etc). Проблема е, че не се 
знае кой ще разруши тръбата първи, например process2 приключва преди process1 
(прекратявайки съществуването на тръбата) тогава ядрото праща сигнал SIGPIPE 
( EPIPE ) [1] на process1 който го хваща и ако не е лейм exit()-ва 
подобаващо, ако . Пример [2]. Работите за доста сложни и понякога зависи дали 
се пише атомично в тръбата или не, колко е атомично за дадена ОС и т.н. 
повече на [3].
  

В обсъждания случай "ps | grep" и двата процеса се стартират
едновременно, а пръв ще приключи ps, понеже grep ще чака затваряне на
входния си файл. На практика за друг наблюдаващ процес и двата ще
завършат едновременно. Поне на мен така ми се струва - самото
приключване на ps при добре направено ядро трябва да прехвърли
управлението директно на grep, което пък да си филтрира получения текст
и също да приключи работа.

    Скелета

lug-bg: X server refresh rate 100 Hz

[niki]

Здравейте група,
след многократни проби и безуспешно лутане по форумите, реших да пиша.
 Проблема е, че X-a не вдига над 80 Hz (refresh rate), а монитора поддържа
100. Под уиндолс си ги държи стабилно, дори вдига 120, на 1024х768. Под
линукс обаче неще. Видеокартата е Nvidia GF 440МХ,vsync и horizsync са
настроени според документацията на монитора. И ranges i твърдо задаване на
хоризонталната е пробвано, но неще. Има ли някакъв начин да се вдигне
refresh-a?

Re: lug-bg: ps ax|grep sth

[George Danchev]

On Monday 13 June 2005 11:31, Vesselin Markov wrote:
> Всъщност, май не зависи от времето за изпълнение нито на ps, нито на grep.
> Иначе, при всяко положение grep се изпълнява по-бъзо от ps, но за да тръгне
> той, ps трябва да е приключил вече.

Това е не вярно. При process1 | process2 ядрото стартира двата процеса 
едновременно (осигурявайки им file descriptors, etc). Проблема е, че не се 
знае кой ще разруши тръбата първи, например process2 приключва преди process1 
(прекратявайки съществуването на тръбата) тогава ядрото праща сигнал SIGPIPE 
( EPIPE ) [1] на process1 който го хваща и ако не е лейм exit()-ва 
подобаващо, ако . Пример [2]. Работите за доста сложни и понякога зависи дали 
се пише атомично в тръбата или не, колко е атомично за дадена ОС и т.н. 
повече на [3].

[1] когато процес се опита да чете или пише в тръбата без да има някой на 
другия край.

[2] strace ls $HOME | echo
write(1, "18464-coffeeparty.jpg\nAdobeFnt.l"..., 1021) = -1 EPIPE (Broken 
pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++

[3] http://www.tldp.org/LDP/lpg/node10.html

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 

Re: lug-bg: ps ax|grep sth

[Tsvetin Vasilev]

Съгласен съм с това, което пишеш, но ми стана интересно :)

Ако се приложи твоята препоръка за минимална селекция в опциите на ps - 
т.е. да показва само потребителския идентификатор + името на процеса, 
дали това няма да е достатъчно да гарантира вярна селекция връщана от 
grep с използване на скобите "[]" ? Всичките тези разсъждения са само в 
контекста на "sh, bash".


поздрави
Цветин Василев

Peter Pentchev wrote:


On Fri, Jun 10, 2005 at 11:27:35AM +0300, Ivan Ralenekov wrote:
 

RE: lug-bg: ps ax|grep sth

[Vesselin Markov]

Всъщност, май не зависи от времето за изпълнение нито на ps, нито на grep.
Иначе, при всяко положение grep се изпълнява по-бъзо от ps, но за да тръгне
той, ps трябва да е приключил вече.


[EMAIL PROTECTED]:/mnt/localstorage# ps ax | time grep bash
6 pts/0Ss 0:01 -bash
10060 pts/2Ss+0:00 -bash
27610 pts/0S+ 0:00 time grep bash
27611 pts/0R+ 0:00 grep bash
0.00user 0.00system 0:00.02elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+171minor)pagefaults 0swaps
[EMAIL PROTECTED]:/mnt/localstorage# ps ax | time grep bash
6 pts/0Ss 0:01 -bash
10060 pts/2Ss+0:00 -bash
27613 pts/0R+ 0:00 -bash
0.00user 0.00system 0:00.00elapsed 25%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+171minor)pagefaults 0swaps
[EMAIL PROTECTED]:/mnt/localstorage# ps ax | time grep bash
6 pts/0Rs 0:01 -bash
10060 pts/2Ss+0:00 -bash
27657 pts/0S+ 0:00 time grep bash
27658 pts/0S+ 0:00 grep bash
0.00user 0.00system 0:00.00elapsed 33%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+171minor)pagefaults 0swaps
[EMAIL PROTECTED]:/mnt/localstorage# time ps ax | grep bash
6 pts/0Ss 0:01 -bash
10060 pts/2Ss+0:00 -bash
27693 pts/0R+ 0:00 grep bash

real0m0.039s
user0m0.008s
sys 0m0.029s
[EMAIL PROTECTED]:/mnt/localstorage# time ps ax | grep bash
6 pts/0Rs 0:01 -bash
10060 pts/2Ss+0:00 -bash

real0m0.051s
user0m0.015s
sys 0m0.029s



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Pentchev
Sent: Sunday, June 12, 2005 4:58 PM
To: lug-bg@linux-bulgaria.org
Subject: Re: lug-bg: ps ax|grep sth

On Fri, Jun 10, 2005 at 11:27:35AM +0300, Ivan Ralenekov wrote:
> Здравейте,
> 
> Имам един въпрос: защо на едната дистрибуция се получава така, че
> "grep"-a хваща и себе си като процес а на другата не? Проблемът е във
> версията на grep или трябва някаква донастройка?

По принцип това зависи от много неща - от това колко бързо се изпълнява
процесът ps и дали шелът изобщо *успява* да пусне grep, преди ps да е
завършил, през купчина други възможни причини, та чак до начина, по
който работи scheduler-ът в ядрото.  В крайна сметка се оказва, че дори
и с трикове от сорта на egrep '[p]rocess' не е много ясно дали винаги ще
се получи това, което искаш.

Друга причина да не е ясно дали ще се получи това, което искаш, е, че с
ps | grep на практика винаги има опасност от false positives - други
процеси, които много, ама много приличат на това, което търсиш, ама не
са точно това, или просто други процеси, абсолютно несвързани с това,
което търсиш, които просто съдържат низа, който търсиш, в името на
програмата или като параметър.  Има няколко начина да се справиш с това:

1. Пак ps, но доста да стесниш обхвата на търсенето, като например му
кажеш да показва само process ID-то и името на командата, която се
изпълнява - без параметри, без потребителско име, без нищо друго.  Под
FreeBSD и с повечето Linux-ки реализации на ps(1) това става с 'ps axco
pid,command' - като всъщност важната опция е 'o pid,command'.
Следващата стъпка е да обясниш на grep да търси *точно* това, което ти
трябва, а не всичко, което съдържа това, което ти трябва, като някаква
част от името, например нещо като
  ps axco pid,command | egrep ' mozilla-bin$'
или дори
  ps axco pid,command | awk '$2 == "mozilla-bin" {print $1}'

2. Една малка програмка, която се казва 'pidof', и обикновено е част от
пакет с името sysvinit или, ако не, то нещо като pstools, psmisc или
нещо такова.  Тя ще ти даде само process ID-тата на всички процеси,
името на които съвпада *точно* с параметъра, който й подаваш, така че на
практика прави същото като последните две ps|egrep и ps|awk команди,
само че по-бързо и по-лесно - и дори е малко по-portable :)

3. Най-правилният начин: намери някакъв начин да обясниш на процеса,
който търсиш, че ще е много добра идея той *сам* да си записва process
ID-то някъде, или намери някакъв друг начин да го контролираш, да го
пускаш и спираш с някакво инструментче, което следи и помни и знае
process ID-тата на наследниците си.  За първия вариант - повечето
daemons имат възможност да стане с нещо като си записват process ID-тата
във файл, чието име ти си избираш да им укажеш на командния ред.  За
втория - имам предвид нещо като пакета daemontools и програмката
supervise в него, която пуска един процес, който *не* преминава във
фонов режим, и след това можеш да подаваш на supervise команди за това
какво точно да прави с пуснатия и следен от нея процес.  Много програми
се поддават на такова отношение - на практика е достатъчно да можеш да
им обясниш, че не трябва да преминават във фонов режим; sshd -D, squid
-N, fetchmail -b, ntpd -n и т.н.  Тогава имаш наистина ясен и сигурен
начин да пращаш сигналчета точно и само на този процес, който те
интересува.

Поздрави,
Петър

-- 
Peter Pentchev  [EMAIL PROTECTED][EMAIL PROTECTED]