大阪フローメーター工業、なんか聞き覚えあるなーと思ってたら、こないだ普通に組み立てに使ってた
大阪フローメーター工業、なんか聞き覚えあるなーと思ってたら、こないだ普通に組み立てに使ってた
このアカウントは、notestockで公開設定になっていません。
AQUAの後ろ（トランクルーム）ドアが開いてる表示が「バックドアオープン」で、この車には深刻なセキュリティホールが存在する！って盛り上がってたのを思い出した
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
独立行政法人１０連ガチャ
N 産業技術総合研究所
R 森林総合研究所
JR 鉄道建設・運輸施設整備支援機構
N 日本学生支援機構
SR 国立印刷局
N 国立文化財機構
N 高齢・障害・求職者雇用支援機構
N 国立大学財務・経営センター
R 日本医療研究開発機構
R 海上技術安全研究所
#shindanmaker
https://shindanmaker.com/609040
鉄建公団が入ってるけど…
ジャパニーズレア…？
いまどきのバンパーじゃなくて基本的に70年代/80年代の中古車情報から取ってきてるからちゃんとメッキバンパーのことですね…
独立行政法人１０連ガチャ
SR 農林水産消費安全技術センター
N 航空大学校
R 電子航法研究所
N 労働政策研究・研修機構
N 駐留軍等労働者労務管理機構
N 国立病院機構
N 年金積立金管理運用独立行政法人
N 交通安全環境研究所
R 農業・食品産業技術総合研究機構
N 産業技術総合研究所
#shindanmaker
https://shindanmaker.com/609040
メッキバンパーって、いまどきのバンパーって樹脂製だから、どっちかというと蒸着バンパーなのでは？
Tsubame-KFCで爆笑したのを思い出す。Kepler Fluid Coolingって言い張ってるけどどこからどう見てもフライドチキン的なアレ。
このアカウントは、notestockで公開設定になっていません。
sidekiqの仕組みじゃなくて、sidekiqを管理してるsystemdの仕組みやね。
先生！systemdじゃないFreeBSDはどうすればいいですか！（自分でやれ）
sidekiqの定期再起動ですが、
sudo systemctl edit mastodon-sidekiq
として、開いたエディタで
[Service]
RuntimeMaxSec=3600
を書き加えると、この例では60秒×60（60分＝1時間）で再起動されます。時間は調整してください。ここでは秒で記載していますが、単位も書けたと思います。
何が行われているかというと、
/etc/systemd/system/mastodon-sidekiq.service.d/override.conf
というファイルが作成されて、既存の設定ファイルに対する上書きが行われます。
今回のように、一時的な変更を加えるときや、本家から配布されているファイルなどに手を加えず、変更部分だけを書きたい場合にお勧めです。
daemon-reloadは編集終了時点で実行されているようです。
@kanade_lab Synapticsの古いタイプのタッチパッド用ドライバがWindows 10で不安定になるので、新しいのに変えてみた次第。
設定用のUWPアプリは別立てになったのでこっちで。
https://www.microsoft.com/ja-jp/p/synaptics-touchpad-device-utility-for-panasonic-pc/9nnd0k13tq5d?rtc=1&activetab=pivot:overviewtab
上野東京ライン 桁架設機 [検索]
このアカウントは、notestockで公開設定になっていません。
@mayaeh とりあえずcronで定期プロセス再起動かけるぐらいかなあ…
あまり想像したくないですけど、万が一言語処理系レベルで駄目なバグなら、解決まで時間かかりそうだし…
#fedibird pushキューがつまる件、Fedibird固有の問題ではなさそうなので、解決の見通しが立つまで、pushキューを担っているsidekiqプロセスの、ローテーションによる定期再起動をかけて対応しています。
pullキューでも起きている可能性がありますが、こちらは様子見します。
@mayaeh main追従してます。ただ、mainの問題か言語処理系の問題か、あるいは外部依存関係の問題かさっぱり。
rubyの特定バージョンのバグだったらいやだなー的なアレで…
@mayaeh 2.7.2の時は起こった記憶がなくて、2.7.3に昨日上げてから起こったので、いやーな予感がするんですよね…
今の環境ってCPUパワーにまかせて脳筋計算したほうが高速な例のほうがどんどん多くなってるよね。
ruby 2.7.3に上げた直後に起こったんだけど、そもそもrubyが原因とかいうぜんぜんわからん度の高い地獄だけは見たくないところ。
とはいえぜんぜんわからん 
って感じなのでIssueにも投げられないでち。たぶんMastodon本体のコードとは関係ない外部依存関係のバグ。
redis側が「ワシもうだめじゃああ」ってなってたのならsidekiq再起動でなおるわけがないので、キューの管理がバグってものすごい勢いで無限クエリ打ってるとかそんなにおいがする。
コア1つを100%まで喰い潰してたので、同じようにredisの負荷で詰まってたんだと思うけど、なぜかsidekiq再起動で直るのさっぱりわからん。
元の記事が長いのでサムネイルがなんかものすごいアピールしてて爆笑してる
待機状態3000という表示を見て、朝っぱらから「なんじゃこりゃああああ」って感じだった
【お知らせ】
Mastodonの開発版勢(mainブランチ追っかけている人)の方々へ。現在原因不明のsidekiqが詰まる現象が発生しております。ご注意ください。
当方でも夜中に発生した様子なので、fedibirdさんの変更によるローカル問題ではない可能性が高いです。
#fedibird 約8時間ほど、各サーバへの配送が遅延しておりました。
約30〜40分前のオペレーションで解消し、一度に大量にFedibirdの投稿が配送されたかと思います。
各サーバの管理者の皆様、一度に大きな負荷をかけ、大変ご迷惑をおかけいたしました。
====
原因は調査中ですが、Redisの応答が極端に低下しているログがみられること、全サーバの再起動後、最終的にsidekiqプロセスの再起動で解消していることから、構成上の問題と、各種アップデート（最新追従）によるMastodon本体側の挙動の変化の両面から追っています。
また、不具合によりアカウント削除の最終処理が完了せず再試行されているフシがあり、再試行時の突発負荷により引き金を引いている可能性があると見ています。（おそらくFedibird拡張部分による固有の不具合）
不具合修正や構成等を再検討し、対策していきたいと思います。
@kanade_lab キーボード側とメインボード側をつなぐフレキケーブルが抜けかかってないかな…（分解しなきゃだけど）
