-ENOTTY

Szef kuchni poleca: Beefy Miracle t-shirts BO2015 O mnie Słoneczna Morena Social

Failure modes of incorrect Type= in systemd units (08 października 2014, 12:29:20)

Proper supervision of daemons requires knowledge which cannot be inferred automatically. Some aspects of service behaviour have to be described by administrator. Widely used upstart system manager has 3 type-like job properties: expect daemon, fork and stop. Their description starts with a warning:

This stanza is extremely important: read this section carefully!
The warning is no less true with systemd's Type=.

Wrong type specification impacts service monitoring, failure detection and dependencies handling. There are six service types in systemd. Three basic ones (simple, forking, oneshot) and three more sophisticated (dbus, idle, notify).

Failure to set proper type may not bite you immediately. Service may run for minute or two and then get killed mysteriously. Services depending on wrongly specified one won't be started, even if it appears to run fine; but systemd won't consider the service ready and will not start dependent units.

Type highlights

  • simple - default type; daemon has to stay in foreground. Ready: as soon as the binary is executed (which may be too soon, service may not be ready to serve requests yet).
  • forking - daemon must fork. Ready: after first process exits. If PIDFile= is defined, readiness is delayed until PID is written to the pidfile.
  • oneshot - suitable for running scripts; systemd waits until process finishes. Ready: when main process exits.
  • dbus - for D-Bus services. Ready: when specified BusName= is acquired.
  • idle - like “simple” , but with delayed execution.
  • notify - most flexible and robust type; by defining simple communication protocol between daemon and systemd, precise information about state can be provided. Requires simple patching, for scripts you can use systemd-notify helper. Ready: when service says so.

Basic type determination

Suitable type can be guessed correctly in 75% cases by just running the daemon binary. If it stays in foreground, connected to the terminal, the type is “simple”. If it forks into the background, the type is “forking” (suprisingly!)

 # /usr/sbin/daemon
Copyright 2014 Foo Baz Bar Corp.
Serving Requests…
→ Type=simple
# /usr/sbin/otherdaemon
#
→ Type=forking

If you need to run a program/script which does its jobs and exits (does not stay running), use oneshot. Please note: if you can choose how the daemon behaves, it generally better to go with "forking". This makes systemd declare "ready" after daemon is actually able to accept connections.

Failure modes

Most of the failures shown below happen after TimeoutStartSec=. By default it’s set to 90 seconds, so lets stick with this value.

Incorrectly selected Type=
simpleforkingoneshotnotify
Correct type simple killed after 90 s1 stays in “activating” state forever2 killed after 90 s3
forking killed almost immediately4 stays in “activating” state forever killed after 90 s
oneshot becomes “failed” after executing5 killed after 90 s killed after 90 s
notify probably works fine killed after 90 s stays in “activating” state forever
Notes:
  1. systemd expects process to fork and parent to exit. It waits until timeout.
  2. it never gets to the “ready” state, so no units depending on it will start; start timeout is ignored for “oneshot” units.
  3. systemd will wait for ready notification. Until timeout.
  4. ”main” process exits
  5. daemons should not exit, but “oneshot” units should

I hope that explains why sometimes systemd kills your service after a minute. Of course you should read man systemd.service, it contains much more details.

Dodaj komentarz | Trackback

Więcej sprywatyzować się nie da? (06 września 2014, 16:19:14)

Stany Zjednoczone Ameryki to ten dziwny kraj, który co jakiś czas zaskakuje pomysłami, na które nie wpadłby nawet Związek Radziecki.

Jakiś czas temu myślałem, że sprywatyzowanie więzień to jakiś żart. Jednak nie. Pierwsze było co prawda UK, ale dopiero USA rozkręciło to w duży biznes. Z więziennictwa zrobili tak dochodowy interes, że nawet sędziowe zaczęli dostawać łapówki za kierowanie skazanych do więzień i poprawczaków.

Podobnie z wojskiem. Private Military Company zaczęły się w UK, a rozkwitły za oceanem. Stoją za tyloma skandalami, że co kilka lat robią rebranding – wystarczy przypomnieć Blackwater/Xe/Academi/Constellis czy jak oni się teraz nazywają.

W mijającym tygodniu zaskoczył mnie felieton w Ars Technica dot. kontroli operacyjnej. U nas sprawę reguluje Prawo Telekomunikacjne w serii arykułów 180 i np. Ustawa o Policji w art. 20c. Za wielką wodą jest to CALEA. O ile u nas tymi kwestiami zajmują się służby (i część gastronomii), to w USA sprywatyzowano również podsłuchy. Firmy oficjalnie zajmują się pomaganiem małym ISP, których nie stać na infrastrukturę inwigilacyjną (takie np. AT&T radzi sobie samo, ale co roku fakturuje CIA na ponad 10 mln dolarów za tę usługę). Faktem jest jednak, że formacje broniące prawa outsource'ują podsłuchiwanie do prywatnych spółek.

Jak to się może rozwinąć? Zapraszam do obejrzenia krótkometrażówki sci-fi pt. From future with love.

3 komentarze | Trackback

Plussszz (18 sierpnia 2014, 14:13:17)

Zgodnie z panujący trendem, krótsze przemyślenia i pierdołki umieszczam w social network, dokładnie tu:

https://google.com/+TomaszTorcz

Na joggerze dalej mam zamiar publikować rzeczy dłuższe niż 2 akapity i takie, które powinny być googlalne (o ironio).

5 komentarzy | Trackback

Czy na stacji są pozytywne emocje? (10 lipca 2014, 09:13:42)

Tankowanie to chyba jakiś psychospołeczny eksperyment, opierający się na warunkowaniu negatywnym:

— Zbiera Pan punkty?
— Nie.
— A chce Pan?
— NIE.
— Może kawę i hotdoga do tego?
— NIE!
I wieńczące rozmowę:
— Fakturę?
— Nie.

Przy tak złym „standardzie” „obsługi” tym bardziej boli znikanie z Polski stacji samoobsługowych. Chociaż np. na Statoil ostatnio widuję automaty z czytnikami kart płatniczych.

Swoją drogą, informacje drogowe w lokalnym radio sponsoruje firma budująca blokowiska. Jej nazwa wyraźnie jest podana przez autopilotem i powtórzona po nim. Efekt? Ten deweloper kojarzy mi się jedynie z korkami na drogach. Pawłow się kłania!

5 komentarzy | Trackback

McInternet bez wartości odżywczych (17 czerwca 2014, 12:18:36)

Siedzisz sobie w McDonald. Jest rano, świeci słońce, popijasz dobrą kawę (kawę w McD mają świetną!). Humor się poprawia, postanawiasz zrobić coś produktywnego i wyciągasz laptopa. Świetnie, sieć chwali się, że we wszystkich lokalach są darmowe hotspoty z Internetem. Klik, klik, czekasz na nawiązanie połączenia, gdy wtem!

ssh: connect to host przecieki.wprost.pl port 22: Connection timed out

Jako, że usterki należy zgłaszać, skontaktowałem się z centralą McDonald. I uzyskałem odpowiedź — jest to sytuacja zamierzona. Otóż:

Ograniczenia dotyczą zablokowania wszystkich protokołów transmisyjnych innych niż HTTP, HTTPS oraz VPN (CiscoNortel). Ponadto zablokowany został dostęp do strony Allegro.pl oraz stron należących do spółki będącej właścicielem ww. serwisu np. otomoto.pl.

Tak więc siedząc w MacDonald z internetu nie pokorzystamy. Nie zalogujemy się nigdzie zdalnie, nie odbierzemy poczty, nie zadziała IM. Z pełnego spektrum protokołów internetowych został dostęp do trzech na krzyż. Ciekawe jest również specjalne traktowanie południowoafrykańczyków. Czyżby to foch po niegdysiejszej odmowie?

9 komentarzy | Trackback

I po Infoshare 2014 (23 maja 2014, 22:25:10)

Nie zwykłem recenzować wydarzeń, ale podzielę się kilkoma przemyśleniami po tegorocznym Infoshare. Organizatorzy po kilku latach mają już wprawę i wszystko odbywa się sprawnie i profesjonalnie. Świetna lokalizacja (i parking!), dobrej jakości technikalia oraz przyjemna atmosfera. Niemniej trudno z roku na rok utrzymać wyśrubowany poziom. Zeszłoroczna edycja dostarczyła więcej wrażeń i ciekawych wystąpień. W tym roku zabrakło porywających przemówień takich jak prelekcja Gabriela Baldinuciego z 2013 czy charakterystycznych postaci.

Dużo mówiło się o trendach i kierunku rozwoju. Wniosek jest smutny. Pierwszego dnia prelegent zastępczy mówił o „10 trendów tu i teraz”. Niemal wszystkie sprowadzały się do zbierania danych o użytkownikach po to, żeby targetować na nich reklamy. Wygląda na to, że nikt nie ma pomysłu na stworzenie czegoś wartościowego, na czym można zarabiać. Szczytem możliwości jest sprzedaż danych behawioralnych.

Jedynym wyróżniającym się trendem był druk 3D. Nie dziwię się, ludzie mają dosyć „tworzenia”, które kończy się milion pierwszą aplikacją dla jednego promila. Druk 3D pozwala zrobić coś, co da się dotknąć. Myślę, że zaczyna nam brakować takiej fizyczności. Dlatego też doceniony został startup robiący grę edukacyjną Professor Why. Clue zabawy w chemię jest rozszerzona rzeczywistość. Znowu – karty, które można dotknąć diametralnie zwiększają zaangażowanie najmłodszych.

Zresztą startupy były najciekawszym elementem tegorocznego Infoshare. Asia spędziła cały pierwszy dzień z zainteresowaniem słuchając pitchy.

Ja drugiego dnia popełniłem błąd taktyczny. Mając do wyboru „Architekturę Stack Oveflow“ i cośtam o Twitterze, poszedłem na to drugie. Sprawnie poprowadzona prezentacją o pierdołach. Ludzie oglądając telewizję twittują, że ogladają telewizję; dzięki temu BMW może puścić reklamę i napastować bezpośrednio (no, na twitterze) osoby oglądające reklamę w tym czasie. Znowu: reklamy, targetowanie, reklamy, reklamy. Rzyg. Podobnie z telewizorami hybrydowymi HbbTV. Pokazany przykład zastosowania — reklama samochodu.

Jednak spora część uczestników odnajdowała się w tematach odmóżdżających – reklamy i telewizja. Dlatego mimo najszczerszych chęci nie udało mi się nawiązać z nimi rozmowy w czasie imprezy integracyjnej na stadionie. Ani z ludźmi, których celem życia jest stworzenie kolejnej stronki.

Z nieoczekiwanych plusów: pierwszego dnia miałem okazję naprawić bankomat bitcoinowy. Ha!

Dodaj komentarz | Trackback

Partyzanckie utrzymywanie usługi w działaniu (z systemd) (27 marca 2014, 12:46:50)

Używam socket activation w systemd do odpalania demona FTPD. Plus jest taki, że jak na dłoni widzę wszystkie sesje i mogę je wybiórczo ubijać. Chociaż raczej nie ma potrzeby, bo użycie zasobów jest skutecznie limitowane mechanizmami z systemd.

$ systemctl | grep vsftp
  vsftpd@406-109.107.25.117:21-93.154.247.87:43126.service            loaded active running   vsftpd instance service for /vsftpd@406.service (93.154.247.87:43126)
  vsftpd.socket                                                       loaded active listening vsftpd incoming socket


$ systemctl status vsftpd@406-109.107.25.117:21-93.154.247.87:43126.service
● vsftpd@406-109.107.25.117:21-93.154.247.87:43126.service - vsftpd instance service for /vsftpd@406.service (93.154.247.87:43126)
   Active: active (running) since Thu 2014-03-27 11:40:13 CET; 1min 9s ago
   CGroup: /system.slice/system-vsftpd.slice/vsftpd@406-109.107.25.117:21-93.154.247.87:43126.service
           ├─11643 vsftpd: ::ffff:93.154.247.87: connected
           └─11645 vsftpd: ::ffff:93.154.247.87/ftp: RETR pidora-18-r1c.img

Jest też niestety minus — jeśli demon vsftpd kilkukrotnie zakończy działanie błędem, to w końcu systemd wyłączy nasłuchujące gniazdko.

Przydałaby się więc automatyka włączająca je z powrotem. W pierwszym odruchu zrobiłem parę jednostek, które używają curl do sprawdzenia stanu usługi:

$ cat ftp-check.timer
[Timer]
OnCalendar=hourly

[Install]
WantedBy=vsftpd.socket

$ cat ftp-check.service
[Unit]
OnFailure=vsftpd.socket

[Service]
ExecStart=/usr/bin/curl --silent --noproxy localhost ftp://localhost:21 -o /dev/null

Jak to działa? Jednostka timer:

  • aktywowana jest co godzinę
  • polecenie enable spowoduje, że zaczyna działać razem z vsftpd.socket
  • ponieważ nie ma explicité podanego co jest włączane przez timer, to aktywowana jest usługa o takiej samej nazwie: ftp-check.timer->ftp-check.service

Działanie "usługi sprawdzającej" również zawiera się w kilku punktach:

  • start usługi powoduje próbę połączenia curlem do FTP
  • po zakończeniu curla sprawdzany jest jego kod wyjścia:
    • jeśli połączenie przebiegło pomyślnie, ftp-check.service po prostu się kończy
    • jeśli curl nie mógł się połączyć, to kod wyjścia wskazuje na błąd; usługa przechodzi w stan failed; ponieważ zdeklarowano OnFailure=, błąd powoduje, że systemd aktywuje wskazaną jednostkę. Powoduje to ponowne wprowadzenie gniazdka vsftpd w stan nasłuchujący — powrót do normalnego działania

Rozwiązanie działa, jednak z opóźnieniem. Zastanowiwszy się nad tym, wpadłem na prostsze rozwiązanie:

$ cat vsftpd@.service
[Unit]
Description=vsftpd instance service for %c
OnFailure=vsftpd.socket
[...]

W ten sposób padający vsftpd sam od razu podnosi gniazdo.

A tak w ogóle to yum install icinga.

Dodaj komentarz | Trackback

Półprzepuszczalne lustro (11 marca 2014, 11:18:56)

Korzystanie z Linuksa na dłuższą metę ma ten urok, że niejako naturalną jest obecność sterowników stworzonych przez analizę zachowania sprzętu i binarnych driverów. Przechodzi się do porządku dziennego nad utalentowanymi programistami, którzy pieczołowicie, funkcja po funkcji, piszą obsługę najnowszych zabawek.

Łatwo — bardzo łatwo! — zapomnieć, że sam sprzęt i binarne sterowniki nie wzięły się znikąd. Kod nie został stworzony przez milion małp uderzających w klawiaturę (chociaż w przypadku firmware można mieć takie wrażenie). Gdzieś tam są ludzie, projektanci, którzy układ tych bramek logicznych wymyślili; którzy rozrysowali sobie na kartce planowany schemat działania, na długo zanim w krzemie uformowano układ scalony.

Niesamowita asymetria wręcz uderza. Nie mamy najmniejszego pojęcia, dlaczego wymyślili układ tak, a nie inaczej. Jakie przesłanki nimi kierowały. Natomiast z drugiej strony? Mają dokładny wgląd w postępy prac nad reverse engineeringiem. Wszystkie listy mailowe są otwarte. Bez ograniczeń czytają dyskusje, zgadywanki. Przeglądają pieczołowicie odtwarzane listy rejestrów. Z pewnością chichoczą widząc znaki zapytania w tworzonej dokumentacji.

Sam chyba nie potrafiłbym znieść takiego napięcia. Widząc jak ktoś pakuje się w ślepy zaułek, bo wyszedł z błędnej hipotezy, nie wytrzymałbym. Napisałbym maila, wskazał kierunek. Zwykła ludzka przyzwoitość pchała by mnie do przekazaniu bratu-programiście wiedzy, którą ja mam.

Ale ci ludzie milczą. Z pewnością od czasu do czasu sprawdzają, na ile amatorzy rozgryźli zagadkę wyrytą przez nich w krzemie lata temu. Aż w końcu otwarty sterownik jest na tyle zaawansowany, że firma podejmuje decyzję o oficjalnym udzieleniu wsparcia.

I znów, firma nie jest jakiś sterowanym komputerowo bytem. Składa się z ludzi. I to ludzie ostatecznie podejmują decyzję: czy włączać się w rozwój open source czy jeszcze poczekać obserwując inkubację. Proces decyzyjny jest z pewnością równie fascynujący, co sama analiza sterowników.

Lustro półprzepuszczalne nazywa się fenickim, błędne jest określenie weneckie.

10 komentarzy | Trackback

GIODO nierychliwe (08 lutego 2014, 11:04:04)

Dzisiaj mija rok. Ósmego lutego 2013 Generalny Inspektor Ochrony Danych Osobowych wysłał mi pismo z informacją, że wszczął postępowanie po skardze. Skardze, którą złożyłem 17 stycznia 2013 i która jeszcze jest rozpatrywana. Od ponad roku.

Sprawa zaczęła wcześniej, w 2012. Stałem się wtedy świadkiem czynności, które wg mojej wiedzy prawnej są przestępstwem. O tym fakcie zawiadomiłem odpowiednią Instytucję, którą dalej będę nazywał Organem. Zawiadamiając wskazałem, kto popełnia przestępstwo i zastrzegłem sobie poufność moich danych osobowych.

W toku wyjaśniania, Organ skierował pismo do tegoż potencjalnego przestępcy. W swojej frywolności, Organ napisał, że otrzymał informację ode mnie i żeby winowajca wytłumaczył się z popełnianego przestępstwa. W kolejnych pismach jeszcze kilkukrotnie padło moje imię i nazwisko.

Po paru miesiącach postanowiłem sprawdzić jak zakończyła się sprawa. Organ odmówił mi podania informacji, gdyż nie jestem stroną. Sięgnąłem więc po Ustawę o Dostępie do Informacji Publicznej. Organ ponownie odmówił. Napisałem skargę do wyższej instancji organu, nota bene jedno z ładniejszych pism jakie kiedykolwiek mi wyszło („niechlujna forma”, „skandaliczne zachowanie”, „brak podstawowych elementów decyzji administracyjnej” itp.). To poskutkowało, otrzymałem żądane dokumenty sprawy wraz z pokrętnym tłumaczeniem wcześniejszej odmowy.

I wtedy zdębiałem, gdy w dokumentach kierowanych do przestępcy ujrzałem swoje imię i nazwisko.

Mleko się rozlało, ale wniosłem skargę do GIODO, aby na przyszłość nikomu się taka sytuacja ze strony Organu nie przydarzyła. Od tamtej pory co dwa miesiące dostawałem pismo, że Inspektor pracuje. Przez telefon nie uzyskałem więcej wyjaśnień. W grudniu 2013 dostałem monit o możliwości zajrzenia do akt sprawy (w Warszawie, bez możliwości przesłana do gdańskiej delegatury), co poprzedza wydanie decyzji. To było 2 miesiące temu.

Rozumiem, że Organ utrudniał prowadzenie dochodzenia. Pewnie tak, jak wcześniej mi, nie chciał wydać kopii korespondencji Inspektorowi. Prawdopodobnie udzielał odpowiedzi pokrętnych i nie na temat. Możliwe, że Organ przeciągał wszystkie terminy. Skłonny jest przypuszczać, że nie nie odebrał monitu o wglądzie w akta, co mogło przyblokować 7-dniowy (!) termin wydania decyzji.

Nie rozumiem natomiast dlaczego GIODO jest takie bezsilne. Czy nie mogą zwrócić się do sądu o wydanie z Organu korespondencji dot. sprawy? Czy nie mogą wnioskować o jakiś mandat za utrudnianie działania?

W kontekście tak długiego rozpatrywania skargi, słowa bez zbędnej zwłoki użyte kilkukrotnie w ustawie zakrawają na żart.

13 komentarzy | Trackback

Spóźnia mi się fedora (13 stycznia 2014, 09:09:35)

Posypał się tradycyjny harmonogram wydań Fedory. Czyli co 6 miesięcy + kilka tygodni tradycyjnego poślizgu. Dwudziestka wyszła w grudniu i najwyraźniej będzie takim pseudo długoterminowym wydaniem. Kolejna wersja nie pojawi się w okolicach czerwca — realny termin to jesień, możliwy jest nawet przyszły rok.

Wszystko przez hocki-klocki pod kryptonimem Fedora.Next. Celem jest wydawanie — zamiast jednego wydania dystrybucji "dla wszystkich" — kilku produktów pod konkretne zastosowania. Mało kto widzi różnicę, QA nie ma pojęcia jak to wytestować i w zasadzie nie wiadomo, czego się spodziewać.

Osobiście mam wrażenie, że większość deweloperów dystansuje się od całej inicjatywy Next i czeka, co z tego wyniknie. A może to tylkobłąd aktora-obserwatora, bo ja tak właśnie robię. Zajmuję się swoimi pakietami tak jak dawniej.

3 komentarze | Trackback

Archiwum :: 26.06.03-28.06.03 | 29.06.03-20.07.03 | 20.07.03-23.08.03 | 23.08.03-16.09.03 | 29.09.03-08.12.03 | 10.12.03-08.01.04 | 12.01.04-22.02.04 | 27.02.04-02.04.04 | 03.04.04-14.05.04 | 14.05.04-10.06.04 | 14.06.04-07.07.04 | 07.07.04-04.08.04 | 08.08.04-29.08.04 | 08.09.04-24.09.04 | 24.09.04-29.11.04 | 29.11.04-22.01.05 | 26.01.05-22.02.05 | 22.02.05-03.04.05 | 04.04.05-03.06.05 | 08.06.05-13.07.05 | 13.07.05-23.08.05 | 24.08.05-31.10.05 | 02.11.05-04.01.06 | 06.01.06-13.03.06 | 20.03.06-19.04.06 | 19.04.06-25.05.06 | 29.05.06-25.06.06 | 04.07.06-13.08.06 | 28.08.06-15.10.06 | 17.10.06-19.11.06 | 20.11.06-20.12.06 | 29.12.06-20.01.07 | 22.01.07-28.02.07 | 07.03.07-24.04.07 | 02.05.07-08.06.07 | 20.06.07-07.09.07 | 10.09.07-22.10.07 | 31.10.07-06.02.08 | 14.02.08-02.06.08 | 16.06.08-09.10.08 | 28.10.08-26.01.09 | 15.03.09-10.05.09 | 24.05.09-06.09.09 | 08.09.09-06.01.10 | 30.01.10-04.08.10 | 05.08.10-22.08.10 | 29.08.10-03.01.11 | 05.02.11-29.09.11 | 05.10.11-08.03.12 | 18.04.12-07.07.12 | 16.07.12-13.05.13 | 17.07.13-26.12.13 | 13.01.14-08.10.14 |
Dodatki :: Nagłówki RSS ATOM
Powered by Jogger. © 2002-2003 Justin Mecham oraz JabberPL Group.
Wszystkie prawa zastrzeżone. Legalność; Informacje
Technorati Profile; ikonki z Tango. Z wyłączeniem komentarzy i zaznaczonych inaczej, autorem tekstów jest zdzichu.