Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.10.38 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Google zveřejnil seznam 1220 projektů od 195 organizací (Debian, GNU, openSUSE, Linux Foundation, Haiku, Python, …) přijatých do letošního, již dvacátého, Google Summer of Code.
Na základě DMCA požadavku bylo na konci dubna z GitHubu odstraněno 8535 repozitářů se zdrojovými kódy open source emulátoru přenosné herní konzole Nintendo Switch yuzu.
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.1.0. Po devíti letech od vydání předchozí verze 3.0.5. Doména dillo.org již nepatří vývojářům Dilla.
O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
Nová vývojová verze Wine 9.8 řeší mimo jiné chybu #3689 při instalaci Microsoft Office 97 nahlášenou v roce 2005.
Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Na EXIT_SUCCESS
ti skončí rodičovskej process, forknutej child ti IMHO pokračuje dál.
No normalne ten kod dejte za to TODO. Jestli vam jde o to ujistit se, ze na pozadi opravdu bezi vas kod, tak si treba zapiste nejakou hlasku do logu.
Jinak muzete vyuzit bud uz zminene volani daemon()
, nebo program daemon, ktery libovolny jiny program spusti na pozadi (dokaze ho taky znovu spustit, pokud chcipne, etc.).
Nedělal jsem tedy zápis do logu, ale v tom svém kódu zapisuji data do souboru, ale nic se neděje.
Flushnul jste je po tom zápisu? Jinak se v souboru typicky nic neobjeví, dokud jich nezapíšete 4 KB nebo soubor nezavřete.
A jseš si vědomej toho, že ten kód mění aktuální pracovní adresář na "/", takže pokuď zadáváš do open/fopen relativní cestu, snaží se ten soubor vytvořit v "/"? Mimochodem, kontroluješ návratové kódy toho zápisu?
Takže všchny návratový hodnoty jsou ok, přesto se soubor nevytvoří, ano? To je nějaký divný, nemyslíš?! Bohužel nám začínají docházet věštecký koule, takže co kdyby si sem konečně nahrál ten tvůj kód. Uštří to čas tobě i nám...
while(1) { fw1 = fopen("/home/pokus.txt", "a"); if (fw1 == NULL) { fprintf(stderr, "%s %i:", __FILE__, __LINE__); perror(NULL); abort(); return errno; } else { for (int i=1; i<10; i++) { fprintf(fw1, "%i ", i); } fprintf(fw1, "\n", ""); } fclose(fw1); sleep(10); }
Ok. Pokusím se ti popsat co dělá ten kód co kopíruješ odsuď v případě, že deamonize = 1 (respektive deamonize != NULL && deamonize != 0).
Zdá se, že spoléháte na to, že alokovaný struct obsahuje samé nuly. Což obecně nemusí být pravda, a nemusí to být ani vhodné. Každopádně pokud začínáte s prázdnou "struct termios", tak se doporučuje napřed použít cfmakeraw(). V některých distrech (verzích glibc?) se nám dokonce osvědčilo ještě před cfmakeraw() strčit bzero(&moje_termios,sizeof(moje_termios)); tj. zaručeně ten struct dospod vynulovat.
Takže vlastně ani není jisté, jestli máte zapnutý nebo vypnutý "canonical processing" (taková terminálová chytristika, která může žrát některé znaky).
Taky tam nikde nevidím flow control (CRTSCTS), což bych doporučoval. Používáte na fyzickém portu flow control nebo ne? Aby tam náhodou nepřetékalo FIFO...
S Vaším problémem to nesouvisí, ale taky není špatný nápad staré nastavení termios pro daný sériový port napřed zazálohovat, a při ukončení programu zase vrátit zpátky.
Tady je útržek zdrojáku z nějakého mého projektu, kde používám sériový port pro "surová data":
struct termios mine; line->saved = (struct termios*) malloc(sizeof(struct termios)); result = tcgetattr(fd,line->saved); // get the current serial line settings cfmakeraw(&mine); // a combo (see man cfmakeraw) cfsetispeed(&mine,mogrify_baud(line->baud)); // input speed cfsetospeed(&mine,mogrify_baud(line->baud)); // output speed mine.c_cflag |= (CLOCAL | CREAD); // not an owner of the tty; receiver on mine.c_cflag &= ~CSIZE; // set data bits mine.c_cflag |= mogrify_bits(line->bits); // actual number of data bits // parity: if (mogrify_par(line->parity) == ~PARENB) mine.c_cflag &= ~PARENB; // no parity else mine.c_cflag |= mogrify_par(line->parity); // some kinda parity is enabled // stop bits: if (mogrify_stopb(line->stopbits) == ~CSTOPB) mine.c_cflag &= ~CSTOPB; // only one stop bit, not two else mine.c_cflag |= CSTOPB; // two stop bits // flow control if (line->flow > 0) mine.c_cflag |= CRTSCTS; // hardware flow control else mine.c_cflag &= ~CRTSCTS; // no flow control //mine.c_cc[VMIN] = 10; // ? minimum volume (bytes) //mine.c_cc[VTIME] = 0; // ? timeout (if no data received) result = tcsetattr(fd,TCSANOW,&mine); // apply the settings
V tom kódu jsou odkazy na další moje pomocné funkce mogrify_*() které přepracovávají moji "lidskou" konfiguraci na nelidské opšny termios Celé to najdete tady, jmenuje se to "serial probes". Není to žádný výkvět programátorské čistoty a elegance... uvidíte sám.
[362032.304531] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [362032.304587] ftdi_sio 3-2:1.0: device disconnected [362044.324454] usb 1-7: USB disconnect, address 5 [362100.104117] usb 5-1: new full speed USB device using uhci_hcd and address 2 [362100.302338] ftdi_sio 5-1:1.0: FTDI USB Serial Device converter detected [362100.302504] usb 5-1: Detected FT232BM [362100.302513] usb 5-1: Number of endpoints 2 [362100.302521] usb 5-1: Endpoint 1 MaxPacketSize 64 [362100.302529] usb 5-1: Endpoint 2 MaxPacketSize 64 [362100.302536] usb 5-1: Setting MaxPacketSize 64 [362100.303369] usb 5-1: FTDI USB Serial Device converter now attached to ttyUSB0 [362182.533603] r8169 0000:01:00.0: eth1: link down [362189.364953] r8169 0000:01:00.0: eth1: link up [362396.131222] ttyUSB0: 6 input overrun(s) [363407.962925] ttyUSB0: 7 input overrun(s) [363719.626233] show_signal_msg: 12 callbacks suppressedTeď se dívám, že v dmesg je i toto:
[363719.626245] monkotel-daemon[23575]: segfault at 1 ip 00799b33 sp bfdfc0ec error 4 in libc-2.12.1.so[759000+157000] [364095.010147] ttyUSB0: 7 input overrun(s) [364557.204599] ttyUSB0: 7 input overrun(s)To je ten můj daemon. Můžete mi někdo naznačit co mi to říka? Jinak běžím na ITX desce s Atomem N270, čipová sada je tam nějaká ta intel945, nevím teď přesně.
nohup
.
Program se napise jako normalni aplikace a pak se spousti pomoci nohup /bin/program > /dev/null 2>&1 &napr. z /etc/rc.local Vysledek je stejny a clovek usetri dle meho nazoru zbytecnou praci. Tot jenom pro uplnost tematu. Jeste lepsi je mozna pouzit
start-stop-deamon
start-stop-daemon --pidfile /var/run/mujprogram.pid --start --background --exec /bin/sleep -- 10... kde jako bonus ziskame pidfile, a je tak otazka scriptu na 5 radku implementovat standardni
/etc/init.d/mujprogram start
, /etc/init.d/mujprogram restart
... atd ...
nohup
nemá se spuštěním na pozadí nic společného, to má na starosti ten ampersand na konci. Stejně tak se nestará ani o další opatření, která jsou u démonů běžná. Příkaz nohup
je jen wrapper, který zajistí, že váš program nebude ukončen signálem HUP
.
Tiskni Sdílej: