@Shiba 親子丼 #hanlunch
https://handon.club/media/4h2l7MjssTMvSBWltnY
名前は「はん」です。handon.club管理人です。
発言数多いです。空中リプライを多用します。内輪投稿が多いですが,どなたでも気軽に話しかけてください。
全ての投稿は個人の見解であり,所属する組織やはんドンクラブを代表する見解ではありません。
★Admin of handon.club.
★Inquiry for handon.club / 運営への問い合わせ
ダイレクトメッセージ or highemerly me.com ( → @ )
★Server info. / 運営情報
#handon_info or https://handon.hatenablog.jp/
その他は固定トゥート参照
★Patron / カンパ
https://fantia.jp/handon or https://www.amazon.jp/hz/wishlist/ls/2GFSVDC4FW72T
★Icon
@ech
mastodon、githubでProjectが立たなくなったし、当面大きなアップロードはないのかな。masterブランチはちょこちょこcommitされてるみたいだけど。
アカウント作った時に誰一人としてフォローしないような設定にしたいんだけどどうやればいいのかわからん(いまは私をフォローしちゃう)
@henkma 最初にフォローするアカウントは指定できるんですが、「指定しないとAdminになる」って仕様なんで、0にはできないのですよね。
あなたはシステム管理者から通常の講習を受けたはずです。
これは通常、以下の3点に要約されます:
#1) 他人のプライバシーを尊重すること。
#2) タイプする前に考えること。
#3) 大いなる力には大いなる責任が伴うこと。
このアカウントは、notestockで公開設定になっていません。
I'm at @Kichijōji Station (吉祥寺駅) [""] http://4sq.com/6atSC7
そもそも私の感覚があわないのが,「Twitterっていつから情報収集ツールになったんだ?」ってことなんだよな〜。少なくとも昔はただのSNSで人と繋がるものだったんだけど。だから話が合わない。
実は8月いっぱいで1つだけ旧WEBサーバーの契約が終わったので通常運用になりました。あなたの接続サーバーは https://handon.club/server-info.html で確認出来ます。
このアカウントは、notestockで公開設定になっていません。
【運営情報】はんドンクラブのメンテナンス情報・障害情報を配信するサイトを立ち上げました。
https://status.handon.highemerly.net/
これまで私のTLで告知していたメンテナンス情報や障害情報は原則こちらで配信します。サーバ,DNS,ネットワーク含めて本番サーバとは完全に別環境になっており,はんドンクラブの障害時にも情報を発信できる体制になっています。
#handon_info
handon.clubドメインにしちゃうとCloudFlareが死んだ時になにも出来なくなるので全くの別ドメインにしてみました。
TrendTag更新されない人はこれをcronで回せばいいよ
cd <mastodonディレクトリ> && echo 'TrendingTags.update!' | RAILS_ENV=production /home/<ユーザ名>/.rbenv/shims/bundle exec rails console
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
発生見込みの台風10号、近年にない勢力で日本列島へ 週末は未曾有の災害に厳重警戒
https://news.yahoo.co.jp/articles/f1a216294696fd178e6f59ff646121e4b6604169
このアカウントは、notestockで公開設定になっていません。
電子契約にしても、受領書とか作業報告書とか紙でもらっとかないと、監査通しにくいんだよなあ。結局、なんでデジタル化できないのかって、監査、SOX法あたりが根っこに来ると思ってる。デジタル庁どうにかして。
接触通知ログを解析した結果、
5件の陽性者が近くにいた記録が確認されました。
@hijouguchi あとクイックルワイパー本家は高いから、スーパーのプライベートブランド品とかにするだけで半額くらいになると思う
きょうの対処で間違いなく発生頻度は抑えられたので、別に見当違いのことをしたわけではなさそうなんだけど、一方で根本原因ではなかったようですね・・・
streamingサーバーがARPテーブルのキャッシュ切れでRedisサーバーのARP解決を試みる
→その直後、1秒間くらいその宛先へのTCPが全部落ちる(なんで?)
→TCP FIN & 再Handshake
→Redis上は全てのSUBSCRIBE要求を1パケットに乗せて送る
→Redisの1リクエストで許容できる上限を超えてしまいRedisがブチキレる
→Streamingは拗ねて二度とRedisにSUBSCRIBE要求を送らない
ARP解決のタイミングで落ちることは100%確定したので、
キャッシュを無限に残るようにすれば解決する気がするけど、
今日はもう寝ます。
違う気がするな。streamingホストでredisのreplicaを動かして、unix socketで繋いだ方がいい気がする。
信じられんのだけど5/5で再現してるから、このクラウド事業者のVPCがおかしくて、ARP解決(要するにブロードキャスト)がちゃんと通らんのかもしれん…