-ENOTTY

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

Cytat na dziś (20 lutego 2015, 19:45:33)

Świetnie spostrzeżnie usłyszałem dzisiaj w pracy. Odnośnie utrzymywania dwóch całkowicie odrębnych zespołów – jeden do opracowania i wdrożenia aplikacji, drugi do jej utrzymywania na produkcji.

To tak, jakby mieć dwie reprezentacje piłkarskie. Jedną szkolić i trenować, a drugą wysyłać na zawody i kazać grać na podstawie dokumentacji.

Dodaj komentarz | Trackback

No czo ten Infoshare znowu (16 stycznia 2015, 21:23:19)

Po ostatniej porażce postanowiłem odpuścić sobie Infoshare w roku powrotu do przyszłości. Ale po ostatnim tech.3camp chyba uległem magii marketingu, bo rozważam udanie się do Amber Expo w czerwcu.

Po pierwsze to organizator przyznał, że ostatnimi laty Infoshare za daleko oddaliło sie od twardych tematów technicznych. I że starają się to nadrobić w tym roku. Hmm. Plus dla nich. Oby się udało.

Druga sprawa: imprezy towarzyszące. Zwiedzanie zardzewiałej fanaberii za ćwierć miliarda mam już za sobą i nie widzę potrzeby powtórki. Natomiast ostatniego dnia szykuje się niezły kąsek. Sztuka wystawiona w naszym czarnym zigguracie, specjalnie dla uczestników konferencji. To jest coś, co mnie mocno przekonuje.

Dodaj komentarz | Trackback

Who wrote systemd? (30 grudnia 2014, 21:24:06)

When it comes to systemd middleware, Lennart Poettering often takes the blame and has sole authorship attributed. But there are many more developers (git shows 593 authors in total) – missing their portion of berating, thus unappreciated and unhappy. Over the Winter Holidays I’ve run LWN's “who wrote” scripts to gather more insight into systemd’s developer base.

Developers with most changesets

Developers with the most changesets
Lennart PoetteringRed Hat7104 38.5%
Kay SieversRed Hat371120.1%
Zbigniew Jędrzejewski-Szmekhobbyist14467.8%
Tom GundersenRed Hat9485.1%
Greg KHLinux Foundation6243.4%
Michal SchmidtRed Hat3692.0%
Thomas Hindoe Paaboel AndersenGNOME2531.4%
David Herrmannhobbyist2331.3%
Martin PittCanonical2311.3%
Harald HoyerRed Hat2071.1%
Dave ReisnerArch1480.8%

Lennart leads, but with less than 40% of all changesets. It seems he has written less than half of systemd. Sorry, Lennart :)
Kay Sievers earned second place mostly by maintaining udev for past couple of years. Majority of his commits were made while he was employed by Novell. Kay now works at Red Hat.
Third most active developer, Zbigniew Jędrzejewski-Szmek, commited less than 8% during the history of systemd. Nevertheless, Zbigniew steadily increases his productivity. OpenHub’s graphs for systemd shows he wrote 12% of changesets in 2014.
Clearly, systemd is driven by top five developers. There is a short drop afterwards. Eleventh person on list contributed less than 1% of all changesets. Red Hat as an affiliation appears few times. Further analysis is in the last section – ”Direct comitters”.

Developers with most changed lines

Developers with the most changed lines
Kay Sievers56561034.3%
Lennart Poettering43851326.6%
David Herrmann947535.7%
Tom Gundersen705414.3%
Greg KH669514.1%
Zbigniew Jędrzejewski-Szmek615063.7%
Michal Schmidt169481.0%
Patrik Flykt73860.4%

Per-line statistics looks a little bit different. Here Kay Sievers leads the pack with one-third of all lines changed. It is again mostly caused by the long history of udev, which was merged into systemd two and a half years ago – in April 2012.
Big individual counts by David Herrmann and Tom Gundersen can be attributed to non-init components they developed in systemd project. David wrote virtual console implementation, hacked on kdbus and logind. Tom created network configuration element of systemd.
Speaking of the networking, Patrik Flykt’s high position comes from refactoring ConnMan's DHCP client library into systemd-networkd. Recently, the library was utilised by NetworkManager 1.0.

Employers with the most hackers

Employers with the most hackers
Red Hat467.1%
Novell192.9%
Intel142.2%
IBM101.5%
Samsung91.4%
Canonical50.8%
Fujitsu40.6%
ProFUSION40.6%
Mandriva30.5%
Dell20.3%
Axis Communications20.3%
Linux Foundation20.3%
OLPC20.3%
SGI20.3%
HP20.3%

While LWN’s scripts try to map each author to his parent company, it’s less robust than other kinds of statistics. People change employers while contributing to the same project. I do not see “hobbyists” in the table above, while over 10% of systemd has been created by them. Some authors contribute patches in their free-time, without relation to the employer. Nevertheless, it is interesting to see more or less recognizable company names in the list.

Direct commiters

There are 26 people with commit access to systemd git. Biggest group – 9 people – work for Red Hat. This is not surprising. RH have choosen systemd as a foundation for their enterprise offering. They had to build expertise and assure sustainable development. Sure way for that is to hire people contributing to systemd.

Next groups come in threes. Three people without clear company ties – I call them hobbyist. Three Debian/Ubuntu developers, with at least one person employed by Canonical. There are also three names from Intel.

Two developers can be associated with GNOME project. There are single developers from openSUSE, Mageia, Arch and CoreOS. There are also single committers from companies: Pantheon Systems and Aldebaran Robotics.

Bear in mind, above only talks about people with direct commit access to systemd’s git. There are companies contributing many patches through the mailinglist, but without dedicated commiter. I can recall few names from Samsung, which has contributed quite a number of patches. Tangentailly, there were only 2 patches from Jolla, which produces mobile phones and tablets with systemd onboard.

Summary

Red Hat pays the bills for biggest number of systemd authors. But please note, some of them were hired by RH specifically because of their earlier contributions to systemd. Community around project contains representatives from other major distributions, some of them even with direct commit access. Tom Gundersen, for example, did majority of his work as an Arch developer.

Some parts of systemd came from specific needs of external users. For example: CoreOS sponsored development of systemd-networkd; Pengutronix contributed watchdog support; Pantheon improved scalability with thousand of units, etc.

12 komentarzy | Trackback

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

Archiwum :: 26.06.03-07.07.03 | 07.07.03-23.07.03 | 29.07.03-01.09.03 | 01.09.03-11.10.03 | 11.10.03-21.12.03 | 21.12.03-06.02.04 | 11.02.04-02.03.04 | 04.03.04-06.04.04 | 12.04.04-17.05.04 | 21.05.04-17.06.04 | 20.06.04-14.07.04 | 15.07.04-17.08.04 | 19.08.04-12.09.04 | 13.09.04-11.11.04 | 12.11.04-26.12.04 | 07.01.05-01.02.05 | 07.02.05-24.02.05 | 03.03.05-14.04.05 | 17.04.05-13.06.05 | 13.06.05-19.07.05 | 19.07.05-30.08.05 | 30.08.05-17.11.05 | 03.12.05-12.01.06 | 24.01.06-23.03.06 | 29.03.06-28.04.06 | 13.05.06-07.06.06 | 08.06.06-11.07.06 | 13.07.06-05.09.06 | 16.09.06-20.10.06 | 25.10.06-26.11.06 | 28.11.06-05.01.07 | 05.01.07-25.01.07 | 30.01.07-19.03.07 | 22.03.07-08.05.07 | 09.05.07-08.07.07 | 19.07.07-18.09.07 | 22.09.07-12.12.07 | 14.12.07-08.03.08 | 11.03.08-23.06.08 | 07.07.08-27.11.08 | 30.11.08-31.03.09 | 08.04.09-02.06.09 | 07.06.09-29.09.09 | 27.10.09-11.04.10 | 15.04.10-07.08.10 | 08.08.10-30.09.10 | 20.10.10-22.02.11 | 15.03.11-08.11.11 | 20.11.11-19.05.12 | 20.05.12-16.09.12 | 02.11.12-29.08.13 | 03.09.13-11.03.14 | 27.03.14-20.02.15 |
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.