Guide to IP Layer Network Administration with Linux
Abstract This guide provides an overview of many of the tools available for IP network administration of the linux operating system, kernels in the 2.2 and 2.4 series. It covers Ethernet, ARP, IP routing, NAT, and other topics central to the management of IP networks. List of Examples 1.1. Sample ifconfig output1.2. Testing reachability of a locally connected host with ping1.3. Testing reachabilit
シグナルハンドラにprintf()を書いてはいけない - Qiita
三行でまとめると シグナルハンドラ内でprintf()してはいけない というより、余計な処理を書いてはいけない もう一度言う、シグナルハンドラで余計なことをするな、非常に大事なことだ はじめに シグナルハンドラでやってよい処理は非常に限られるのに、全くルールを守らないサンプルコードが世の中に大量に出回っている。printf()するなんてもってのほかなのだが、カジュアルにそこらじゅうで見かけて非常に悲しい。 この記事では、そんな状況を少しでも改善したいと思い初心者向きに書いたものだ。そのため、下記では、回避するにはどう実装すればよいのか、ルールを破るとどうなるのか、といった点を先に簡潔に記述する。 なぜしてはいけないのか、POSIXだとかリエントラントだとか、は下の方に追いやっている。玄人は読んでてウズウズするだろうが、細かい話はできるだけ目につかないような構成としたため了解いただきたい。
Rustの std::sync::RwLock はLinuxでwriter starvation問題を起こす (macOSなら平気)
まとめ: std::sync::RwLock::{write(), try_read()} を併用した場合には「書き込みロックを最優先」という挙動は必ずしも期待できない (LinuxではNG) Pthread の規約が挙動に自由度をもたせており、Linuxにおけるデフォルト実装では writer starvation が発生する Rustにおいて writer starvation を回避しつつ readers-writer lock を使うには parking_lot::RwLock を使うと良い 目次 背景: Readers-writer lock とは？ 背景: Rustにおける readers-writer lock 背景: RwLock::write() と RwLock::try_read() 再現コード 原因分析 修正: parking_lot::RwLock を使う おわり
20分で分かるDirty Pipe（CVE-2022-0847） - knqyf263's blog
極限まで詳細を省けば何とか20分で雰囲気だけでも伝えられるんじゃないかと思って書きました。書き終えてから見返したら多分無理なので誇大広告となったことを深くお詫び申し上げます。 背景 概要 脆弱性の影響 ページキャッシュやsplice パイプ マージの可否 下準備 攻撃手順 まとめ 背景 先日Dirty PipeというLinuxカーネルの脆弱性が公表されました。 dirtypipe.cm4all.com Linuxのパイプに関する脆弱性なのですが、仕組みは意外とシンプルでぎりぎりブログでも伝わるかもしれないと思ったので自分の理解を書きました。あといつも細かく書きすぎて長くなるので、今回は雰囲気だけでも伝わるようにとにかく説明を簡略化し、ふわっとした概要だけでも理解してもらえるように頑張りました。その結果、若干正確性に欠ける部分があるかもしれませんがお許しください。細かい部分はまた別の記事でま
Landing a new syscall: What is futex?
Over the past 18 months, we have been on a roller-coaster ride developing futex2, a new set of system calls. As part of this prolonged effort, the futex_waitv() syscall has now successfully landed in Linux 5.16. A followup of the initial futex syscall, this new interface aims to overcome long term issues that have been limiting the way applications use the Linux kernel. But what exactly is futex?
リモートの Linux サーバを開発環境にする
これまで Macbook Pro を開発環境としていたんだけど、価格は高いし Docker for Mac は重いしでいいことないなということで Linux の開発環境に移ることにした。前職の最初の数年はすべて VM（当初は jail）にログインして開発していたのでその頃に戻った感じ。ただ GUI は macOS が何かと楽なので Intel NUC を購入して自宅に置いてリモートでログインして使っている。Core i7、メモリ 64GB で10万ちょいと安いのにめちゃくちゃ快適でさいこう。 ここからは備忘録としてリモートを開発環境とするうえで実施した作業を残す。あと作ったものもあるので宣伝。 外部からログインしたい自宅以外からも使うだろうということで（最近京都からリモートで働くこともあり）、VPN サービスとして Tailscale を導入した。 Best VPN Service for
Get started with eBPF using BumbleBee
What is eBPF? eBPF stands for extended Berkeley Packet Filter. The Linux kernel has been around for a long time, however, it is not easy to modify or extend the kernel unless you know how to patch it. If you are familiar with Kubernetes’s custom resources or Envoy filters, you understand how important it is to build extensions based on your specific scenarios. What eBPF provides to the Linux kerne
How eBPF will solve Service Mesh - Goodbye Sidecars - Isovalent
Service mesh is a concept describing the requirements of modern cloud native applications with regards to communication, visibility, and security. Current implementations of this concept involve running sidecar proxies in each workload or pod. This is a pretty inefficient way of solving these requirements. In this post, we will look at an alternative to the sidecar model that provides a transparen
Kernel Queue: The Complete Guide On The Most Essential Technology For High-Performance I/O
Kernel Queue: The Complete Guide On The Most Essential Technology For High-Performance I/O When talking about high-performance software we probably think of server software (such as nginx) which processes millions requests from thousands clients in parallel. Surely, what makes server software work so fast is high-end CPU running with huge amount of memory and a very fast network link. But even the
LinuxサーバーのTCPネットワークのパフォーマンスを決定するカーネルパラメータ – 1編 | NHN Cloud Meetup
1.はじめに ネットワークのパフォーマンスを決定付ける最も重要な要素は、最終的にはアプリケーションにあるでしょう。ただ、ワークロードの特性によっては、デフォルト設定されたTCPカーネルパラメータが制約となり、パフォーマンスを発揮できないときもありますね。 非常にたくさんのカーネルパラメータがありますが、本文では、ネットワーク帯域幅（bandwidth）のカーネルパラメータ、ネットワーク容量（capacity）のカーネルパラメータを主に扱います。 2.準備 Linuxはsysctlコマンドで簡単にカーネルパラメータを実行時に変更できます。 次のようなコマンドを使用すると、現在のカーネルパラメータ設定値の全体を閲覧できます。 $ sysctl -a ここで取り上げるネットワークは、特にTCPのcapacityとbandwidthなどを調整（tuning）できるカーネルパラメータのごく一部を紹介
<title>Linuxでもゲームをしたいというハナシ - No problem</title>
どうも、僕です。 この記事はPySpa Advent Calendar 2019 19 日目 の記事です。 今回はあまり書くことがなかったので、マイルドな内容になってしまいました。 ハイ。本当に書くことがないんですね。無.com です。 私は普段から Linux デスクトップを使ってるのですが、それなりにゲームをしていたりします。 あまりそーいう人が周りにいなかったのでその事についての戯言を書いてみたいと思います。 Linux でゲームをするLinux でゲームと言われるとターミナルベースのゲームを思い浮かべる人が多いかも知れません。 確かに昔はそうだったかも知れませんが、今ではそうではありません。 数年前から私が遊んでたゲームがどのように変化していったかを振り返って書いてみたいと思います。 あくまでの私が遊んだ経緯なので歴史的には前後してる部分はありますし、間違ってるかも知れません。 ま
Coping with the TCP TIME-WAIT state on busy Linux servers | Vincent Bernat
TL;DR Do not enable net.ipv4.tcp_tw_recycle—it doesn’t even exist anymore since Linux 4.12. Most of the time, TIME-WAIT sockets are harmless. Otherwise, jump to the summary for the recommended solutions. The Linux kernel documentation is not very helpful about what net.ipv4.tcp_tw_recycle and net.ipv4.tcp_tw_reuse do. This lack of documentation opens the path to numerous tuning guides advising to
よくわかるLinux帯域制限 | GREE Engineering
矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日本語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が
Linux OOM Killerについて - Qiita
OOMとは? Linuxは、メモリが不足してシステムが停止する恐れがある際、メモリリソースを多く消費しているプロセスを強制的に殺します。これをOOM Killerといいます。重要なプロセスでも問答無用で殺しにきます。 いるはずのプロセスがある日消えていたのなら、それはOOM Killerに殺されたのかもしれません 確認方法(CentOS) 5789のrubyのプロセスが殺されたことが分かります $ sudo cat /var/log/messages | grep Killed Oct 1 11:11:54 ip-xx-xx-xx-xx kernel: [1983378.957901] Killed process 5789 (ruby) total-vm:4957320kB, anon-rss:2717004kB, file-rss:0kB
消すだけなのに rm -rf がいっつも長くて待ちきれない問題 - kuenishi's blog
rmコマンドで大量のファイルを削除しようとするとjournaldがめっちゃリソース持っていく件— bokko (@cubicdaiya) 2017年8月3日 今時のファイルシステムはみんなジャーナルもってて何かあったときにそこからリカバリする仕組みになってるので、当たり前といえばそうなんだけども。 （TODO: ここにファイルシステムのツリー＋ジャーナルのポンチ絵を手描きでも何でも描く） ご本尊のデータのツリーと何らかのWALを1セットで持っておくのはRDBだろうがファイルシステムだろうがそうは変わらない、で、削除についても並行制御をうまくやるために削除フラグをログに入れておいてあとで本尊のデータを整理するというのが基本的な設計になる。そこで私は立ち上がった（TL;DR: 特にオチとかはないです）。 rm -rf が遅いのは人類にとって損失ではないか。もっと速く完了するようにすれば、 rm
How TCP backlog works in Linux
When an application puts a socket into LISTEN state using the listen syscall, it needs to specify a backlog for that socket. The backlog is usually described as the limit for the queue of incoming connections. Because of the 3-way handshake used by TCP, an incoming connection goes through an intermediate state SYN RECEIVED before it reaches the ESTABLISHED state and can be returned by the accept s
Helpful Linux I/O stack diagram
During one of my regular trips to reddit, I stumbled upon an amazingly helpful Linux I/O stack diagram: It’s quite comprehensive and it can really help if you’re digging through a bottleneck and you’re not quite sure where to look. The original diagram is available in multiple formats from Thomas Krenn’s website. If you combine that with this slide from Brendan Gregg’s Linux Performance Analysis a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rust no_stdで作るコンテナ
windhole booth - BOOTH
キューイング規則とバンド幅管理