Omarchy (Wikipedie) je linuxová distribuce s dlaždicovým správcem oken Hyprland. Založena je na Arch Linuxu. Vydána byla v nové verzi 4.5.0. Nově také pro Apple Silicon, konkrétně pro M1/M2/M3/Neo MacBooky.
Byla vydána nová stabilní verze 8.3 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 156 s bezpečnostními opravami z Chromia 157. Přehled novinek i s náhledy v příspěvku na blogu.
Multimediální přehrávač mpv byl vydán ve verzi 0.42.0. Jde o větší balík změn po bezmála roce. Mimo jiné se lépe integruje s Waylandem nebo rozšiřuje podporu DVD/Blu-ray, např. umožňuje přehrávat rovnou obrazy médií (soubory iso).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.5.0. Přehled novinek v poznámkách k vydání.
Byla vydána (𝕏) nová verze 8.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Byla vydána verze R14.1.7 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Bazzite (Wikipedie), tj. linuxová distribuce vycházející z Fedora Linuxu a optimalizována pro hraní počítačových her, byla vydána ve verzi 45. S Open Gaming Collective (OGC) jádrem a novým Easy Anti-Cheatem pro Linux (EAC Linux v2).
MikroTik zveřejnil vlastní bezpečnostní upozornění potvrzující, že zranitelnost linuxového jádra postihuje také RouterOS 7. Jde o use-after-free při zpracování IPv4 TCP spojení s IP options. Zranitelnost se týká provozu směřujícího na TCP službu samotného routeru, nikoli paketů, které router pouze přeposílá. Opraveno v long-term od 7.24.6, v stable od 7.25.1 a devel od 7.26beta5.
Ve správci balíčků APT, používaném v Debianu a odvozených distribucích, byla nalezena a opravena kritická zranitelnost CVE-2026-109518. Vzdálený útočník může obejít ověření stažených balíčků pomocí přesměrování a dočasných chyb HTTP serveru.
Řešení dotazu:
cron-u a čo urobí v iných prípadoch, je v tom, kam ten výstup ide. V prípad cron-u nejde nikam, alebo v lepšom prípade do mailu.
Príkaz wall zariadi, že to čo dostane na vstup zapíše na terminály všetkých prihlásených užívateľov (wall je "write all").
mail zadaný v terminálu.* * * * * echo "Upozorneni" crontab, pomocí crontab -e jste jen spustil příkaz k editaci souboru, který jste upravil a používá jej cron. Crron si jej ve „vlastním terminálu“ přečte a pokud nastane čas, příkazy spustí a obvykle celý výstup, který šel na stdout a stderr pošle do uživatelovi schránky.* * * * * echo "Upozorneni" | wallAhoj, restartoval jsi cron po tom, co jsi upravil ten jeho konfigurační soubor ? Pokud ne, tak /etc/init.d/cron restart
Nevím jak je to s tím echo. Radši bych zkusil vytvoři soubor. Tam si budeš jistý, jestli se vytvořil nebo ne. touch /home/xx/Desktop/zkouska_cronu.
mail.* * * * * echo "Upozorneni" | wall již fungovat bude, bo příkaz wall je to, co zařídí, že se to objeví v tom vašem terminálu.
To o schrance nikde, kde echo ukazovaly jako standardni prikaz, zmineno nebylo
Samozřejmě že ne, protože to není vlastnost příkazu echo, ale vlastnost cronu. Pokud (jakákoli) úloha spuštěná přes cron vygeneruje nějaký výstup (standardní nebo chybový), je ten výstup poslán mailem uživateli, z jehož cron tabulky se ta úloha spouštěla. Tak cron funguje a je to popsáno i v dokumentaci. Musíte si uvědomit, že v době, kdy se ta úloha spouští, může být už na daném terminálu přihlášen někdo úplně jiný nebo také nemusí být přihlášen vůbec nikdo, takže nemá smysl posílat výstup na terminál.
Cron searches /var/spool/cron for crontab files which are named after accounts in
crontabs found are loaded into memory. Cron also searches for /etc/crontab and the
files in the directory, which are in a different format (see crontab(5) ). Cron
then wakes up every minute, examining all stored crontabs, checking each command to
see if it should be run in the current minute. When executing commands, any output
is mailed to the owner of the crontab (or to the user named in the MAILTO environ-
ment variable in the crontab, if such exists).
Additionally, cron checks each minute to see if its spool directory’s modtime (or
the modtime on /etc/crontab) has changed, and if it has, cron will then examine the
modtime on all crontabs and reload those which have changed. Thus cron need not be
restarted whenever a crontab file is modified. Note that the crontab(1) command
updates the modtime of the spool directory whenever it changes a crontab.
Pomohlo by aj prehladat forum pred polozenim otazky; dotaz "nefunguje cron" sa tu riesi kazdy mesiac.
ale já opravdu prohledal celý internet
To myslíte vážně???
ostatne, ja jsem nikde netvrdil, ze mi nefunguje cron, ale prikaz echo
Jako začátečník se nepokoušejte kategoricky tvrdit, v čem je problém (nebo že "xyz nefunguje"), protože bez základních znalostí je to jen střelba naslepo. Místo to raději vždy co nejpřesněji popište (1) co jste udělal, (2) co se stalo, (3) proč si myslíte, že je to špatně a co se podle vás mělo stát.
jsem měl strach, že se na mne zesype spousta chytrých hlav, kteří místo aby poradili, mi vysvětlí, co jsem měl napřed udělat
Což není nutně chyba. Myslíte si snad, že tohle je poslední problém, který jste kdy měl?
hanpari trochu křivdíte. Možná že manuál ke cronu nečetl, což je jistě trestuhodné, ale i kdyby četl, stejně díky jeho malé informovanosti o fungování linuxu obecně by nebyl sto odvodit, že když se výstup posílá na mail, že to zároveň znamená, že se nevypisuje na terminál (což ani odvodit nelze!), takže by byl tam, kde je, tedy měl by za to, že echo nefunguje (navíc má asi i nenakonfigurovanou počtu, tak mu ani ty maily nechodí).
Pak také popis "echo nefunguje" se mi zdá správný, z pohledu uživatele echo nefunguje.
echo "Zprava" | /usr/bin/mailx -s "predmet zpravy" pavelPak také popis "echo nefunguje" se mi zdá správný, z pohledu uživatele echo nefunguje.
Podle mne správný není. Příkaz echo totiž v daném případě fungoval, protože dělal přesně to, co dělat měl. Že se stalo něco jiného, než uživatel očekával, je v tomto případě výhradně důsledkem neznalosti uživatele a ani v nejmenším nefunkčnosti příkazu echo. Prostě další příklad na téma "Počítač dělá to, o co si mu řeknete, ne to, co po něm chcete."
echo nefunguje".
…již fungovat bude, bo příkaz wall je to, co zařídí, že se to objeví v tom vašem terminálu.
Jakož i na všech ostatních. :-) Pro poslání zprávy na jeden konkrétní terminál slouží příkaz write.
/etc/crontab som ho otvoril pomocou VI
ale musel som dat uzivatela
* * * * * root echo "haloo" | write root
funguje aj
* * * * * root echo "haloo" | wall
ak ma uzivatel pravo menit crontab
tak sa potom nastavuje jeho crontab vo /var/spool/cron
a tam netreba zadavat uzivatela
Tiskni
Sdílej: