Sziasztok!
A Cron-nal van egy kis bajom. Feltünt hogy a syslog-ban a következő
bejegyzések vannak:
cron[30243]: Error: bad minute; while reading /etc/cron.d/apache
+ még hasonló bejyegyzés
Ugye a /etc/crontab fájlban lévő sorokról van szó, gondoltam el írtam az
időt. Javítgattam a crontabot,
Gergely Tamás írta:
szedi a beállításokat? Milyen beállító fájlt olvas most a gépem?
A /etc/cron.d alatt is, meg a userek sajat crontabjait is beolvassa.
_
linux lista - linux@mlf.linux.rulez.org
De nekem ezeken a helyeken nincs crontab file...
Hofferek Attila írta:
Gergely Tamás írta:
szedi a beállításokat? Milyen beállító fájlt olvas most a gépem?
A /etc/cron.d alatt is, meg a userek sajat crontabjait is beolvassa.
_
linux
hello,
Sziasztok!
A Cron-nal van egy kis bajom. Feltünt hogy a syslog-ban a következő
bejegyzések vannak:
cron[30243]: Error: bad minute; while reading /etc/cron.d/apache
+ még hasonló bejyegyzés
szerintem elso korben kellene egy
cat /etc/cron.d/apache
kimenet.
Ugye a /etc/crontab
Gergely Tamás írta:
De nekem ezeken a helyeken nincs crontab file...
Dehogynincs, ott írja: /etc/cron.d/apache
Az etc/cron.d alól mindent felnyal a cron, nem csak a crontab
nevűeket. Minden app oda teszi a saját cron feladatait, a saját nevén.
Lám, az apache is. Nézd meg mi lehet rossz benne!
ajjajj, akkor én ezt nagyon félreértettem. Én a saját szkriptjeimet
raktam ide amelyekre a crontabban hivatkozom (/etc/crontab). Így érthető
hogy nem tudja értelmezni a benne lévő tartalmat. Köszi, átvariálom.
Hofferek Attila írta:
Gergely Tamás írta:
De nekem ezeken a helyeken nincs
Gergely Tamás írta:
Most már eltünt a log-ból a hibaüzenet.
A szkriptjeimet beraktam a /etc/cron.scripts helyre.
a contabban az apache bejegyzés ami percenként reloadolja a szevert
*/1 * * * * root/etc/cron.scripts/apache
Ez a crontab a /etc/crontab fájl,
Gergely Tamás írta:
Nem crontab -e -vel szerkesztem, hanem mc-vel az /etc/crontab filet.
Jó is az, amikor az mc az utolsó sorból lekapja a sorvége jelet és a
crontab szépen kihagyja ;).
--
k-atti-
_
linux lista -
2009. szeptember 1. dátummal Gergely Tamás ezt írta:
Nem crontab -e -vel szerkesztem, hanem mc-vel az /etc/crontab
filet.
Aztán: crontab /etc/crontab
Ez így nem jó.
Megszerkeszted a rendszerszintű crontab-ot (/etc/crontab)
Aztán beteszed a root felhasználó cron-jába (crontab /etc/crontab)
A
2009. szeptember 1. dátummal Kosa Attila ezt írta:
On Tue, Sep 01, 2009 at 11:39:26AM +0200, Salamon Attila wrote:
2009. szeptember 1. dátummal Gergely Tamás ezt írta:
Majd: /etc/init.d/cron force-reload
Ez nem kell, mert automatikusan felolvassa a változást,
ellentétben a
Van egy nagy halom slow-query-m:
# Time: 090901 12:00:01
# u...@host: DBMail[DBMail] @ localhost []
# Query_time: 52.065513 Lock_time: 0.000205 Rows_sent: 0
Rows_examined: 307816
SET timestamp=1251799201;
SELECT message_idnr FROM dbmail_messages m JOIN dbmail_physmessage p ON
Rows_examined: 307816
++-++++--+-++--++
| id | select_type || type || key | key_len || rows |
++-++++--+-++--++
| 1 | SIMPLE || range || headername
Miloska wrote:
Rows_examined: 307816
++-++++--+-++--++
| id | select_type || type || key | key_len || rows |
++-++++--+-++--++
| 1 | SIMPLE || range ||
Az en multkori problemam?
Hasonlo lehet, csak a nagy tomegu insertnel latom, es kozben a
lekerdezesek gyorsak, ha a mar insertalt uzenetek nezem valami mail
klienssel, akkor 1000message/s-el jonnnek a headerek, kozben az insert
all. Viszont BTR_KEY nincs a forrasban, patkolni nem tudom.
Miloska wrote:
Az en multkori problemam?
Hasonlo lehet, csak a nagy tomegu insertnel latom, es kozben a
lekerdezesek gyorsak, ha a mar insertalt uzenetek nezem valami mail
klienssel, akkor 1000message/s-el jonnnek a headerek, kozben az insert
all. Viszont BTR_KEY nincs a forrasban, patkolni
Gabor HALASZ írta:
SELECT message_idnr FROM dbmail_messages m JOIN dbmail_physmessage p ON
m.physmessage_id=p.id JOIN dbmail_headervalue v ON v.physmessage_id=p.id
JOIN dbmail_headername n ON v.headername_id=n.id WHERE m.mailbox_idnr=29
AND n.headername IN ('resent-message-id','message-id')
Kovács Attila wrote:
Gabor HALASZ írta:
SELECT message_idnr FROM dbmail_messages m JOIN dbmail_physmessage p ON
m.physmessage_id=p.id JOIN dbmail_headervalue v ON v.physmessage_id=p.id
JOIN dbmail_headername n ON v.headername_id=n.id WHERE m.mailbox_idnr=29
AND n.headername IN
Gabor HALASZ írta:
Akkor forditva lene ;) Amugy melyik elso kettore is gondolsz? Es miert
lenne ez nekem jo?
Le is írtam oda neked fordítva :).
Mert akkor nem kell full table scant nyomni a sql motornak, feltéve ha
sikeresen tudsz szűrni (van index). Persze az is lehet hogy a
Gabor HALASZ írta:
v.headervalue='x...@x' AND p.internal_date NOW() - INTERVAL 3 DAY;
Hahh. Bele akartam kötni a now() függvényedbe, de ügyes ez a mysql.
A select indítása és befejezése között végig ugyanazt az értéket adja.
A sysdate viszont jól meglassítaná a selectedet ;).
--
k-atti-
Kovács Attila wrote:
Gabor HALASZ írta:
Akkor forditva lene ;) Amugy melyik elso kettore is gondolsz? Es miert
lenne ez nekem jo?
Le is írtam oda neked fordítva :).
Nem neztem vegig, amig nem ertem, minek.
Mert akkor nem kell full table scant nyomni a sql motornak, feltéve ha
Gabor HALASZ írta:
Nem neztem vegig, amig nem ertem, minek.
Nem is kell megfordítani, mert a
mailbox_idnr -re van index, mint a mellékelt adattáblákból látszik.
Jo, majd lesz.
Attól még az index nem árt a dátumra, bár szerintem a dátumszűrés
helyett sokkal jobb lenne
a státusz
21 matches
Mail list logo
