если хакнули, то это охуенно ))) в былые времена канпеляли! а теперь жабка, лол

очень суровые хипстахакеры, похоже, жава да телеграмчик :)

https://github.com/rubenlagus/TelegramBots/releases/tag/2.4.4.1

поищи конфиг, может api ключи от групп нахаляву отхватишь

а ещё лучше собрать всё и телеграмму зарепортить.

...а потом ключи биткоенов выцепить!

забавно

это не телеграм с собой притягивает?

в портах такого вроде не нашёл…

проблема в том, что у фряхи нет "middle-level FS". UFS - дерьмище страшное, и fsck на 1тб диске делается до 4 часов, а zfs при его плюшках всё-таки достаточно нишевое решение. Особенно когда памяти мало.

Тащемта, скорость работы fsck зависит даже не от объёма раздела, а от количества inode на файловой системе. Потребление памяти, кстати, тоже. И эта проблема касается не только UFS, а вообще всех файловых систем, где inode выделены статически.

поищи конфиг, может api ключи от групп нахаляву отхватишь

проблема что я толком сделать ничего не могу удаленно, постояно виснет терминал...

nice им сделай))

можно попробовать выполнять по одной команде: ssh xxx@yyy "sockstat | grep java"

ssh user@host 'pkill -9 java'

Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 anti3z.ru.10124 178.34.160.248.21183 TIME_WAIT tcp4 0 0 anti3z.ru.10123 ip-176-194-141-1.23179 TIME_WAIT tcp4 0 0 anti3z.ru.https es93.mirohost.ne.65052 TIME_WAIT tcp4 0 0 anti3z.ru.10122 192.168.1.27.48517 SYN_SENT tcp4 0 0 anti3z.ru.10120 server-52-85-184.http TIME_WAIT tcp4 0 0 anti3z.ru.10119 tracker1.resilio.4000 TIME_WAIT tcp4 0 0 anti3z.ru.10118 89.20.140.86.48517 SYN_SENT tcp4 0 0 tataserv.10117 192.168.100.134.58877 SYN_SENT tcp4 0 0 anti3z.ru.https 151-249-166-165..42420 ESTABLISHED tcp4 0 0 anti3z.ru.https es93.mirohost.ne.62554 TIME_WAIT tcp4 0 0 anti3z.ru.10114 109.238.92.96.55000 ESTABLISHED tcp4 0 64 anti3z.ru.ssh 89.20.140.86.51773 ESTABLISHED tcp4 0 0 anti3z.ru.https es93.mirohost.ne.60350 TIME_WAIT tcp4 0 0 anti3z.ru.10051 109.238.92.96.55000 TIME_WAIT tcp4 0 0 anti3z.ru.https es93.mirohost.ne.57938 TIME_WAIT ddos ?

спугнуть? лучше -STOP

первый раз ребутнулся - висел этот бот... ребутнулся еще раз - бота нет...

Может SA-17:06 сэксплойтили?

Может SA-17:06 сэксплойтили?

10.08.... я недели полторы назад на 11.1 апнулся

FreeBSD 11.1-RELEASE-p1

Хз, тогда возможно прийдётся потрошить всё что стоит на системе…

до логов бы добраться хотя бы

вроде отлетела пиявка

теперь копаться искать (((

вот предлагали же стопнуть

проще искать было бы

кого стопнуть? жаву я сразу же прибил

Внезапный вопрос: как на фре дела обстоят с гибридной графикой? Такая же боль как на лине?

Volodymyr Kostyrko "Krond" [E11??ZP], [27.09.17 14:08] Может SA-17:06 сэксплойтили? 27.09 14:09 AnTi3z to Volodymyr Kostyrko "Krond" [E11??ZP]: 10.08.... я недели полторы назад на 11.1 апнулся 27.09 14:10 AnTi3z: FreeBSD 11.1-RELEASE-p1 Volodymyr Kostyrko "Krond" [E11??ZP], [27.09.17 14:10] Хз, тогда возможно прийдётся потрошить всё что стоит на системе… 27.09 14:10 AnTi3z: до логов бы добраться хотя бы 27.09 14:11 AnTi3z: вроде отлетела пиявка 27.09 14:11 AnTi3z: теперь копаться искать ((( 27.09 14:11 Vadim Goncharov: вот предлагали же стопнуть 27.09 14:11 Vadim Goncharov: проще искать было бы 27.09 14:11 AnTi3z: кого стопнуть? жаву я сразу же прибил

чо-т мой sed-скрипт для копипасты не ест эмодзи, может кто на фревом проверить?

Странное предложение, сразу после взлома

https://m.geektimes.ru/post/293331/

Может кто-нибудь пояснить, с чем связан такой охеренный размер исполняемых бинарников монги? $ l /usr/local/bin/mongo* -rwxr-xr-x 1 root wheel 290430725 Sep 12 20:20 /usr/local/bin/mongo* -rwxr-xr-x 1 root wheel 858071999 Sep 12 20:23 /usr/local/bin/mongod* -rwxr-xr-x 1 root wheel 841549163 Sep 12 20:25 /usr/local/bin/mongoperf* -rwxr-xr-x 1 root wheel 393659622 Sep 12 20:35 /usr/local/bin/mongos*

Статическая сборка?

Из обычного бинарного пакета: pkg install mongodb34

ldd и file натрави да вывод покажи.

Бинарники не strip-нуты, после strip-а похудели раз в 10. Но всё-равно впечатлился размером пакета в 400+ метров…

ldd и file натрави да вывод покажи.

$ file mongod mongod: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.0 (1100122), FreeBSD-style, not stripped

А ldd?

Вывод ldd /usr/local/bin/mongod: https://pastebin.com/QRfvcYUu

В общем, вижу тут повод для PR, чтобы для порта STRIP включили.

Вот вам задачка по мотивам срачика в соседнем чятике: перечислите в порядке возрастания времени работы способы удаления файлов с использованием find и обоснуйте, почему.

в теории самый быстрый способ find /path -type f -name 'what_to_find' -print0 | xargs -0 -P X rm где X завист от типа диска (для SSD больше чем для SATA) и наличия raid (на stripe можно попробовать X в два раза больше чем без него), но проще подобрать X эксперементально. А вообще для быстрого удаления в POSIX не хватает syscall-а для удаления нескольких файлов в одной директории за раз. Внтури FS эту операцию можно соптимизировать но API для этого нет.

Sponsored by: Microsoft https://reviews.freebsd.org/D12430 This negotiation behaviour was introduced 11 years ago ... Sponsored by: TCP/IP Optimization Fundraise 2005

можно еще в середину папа pv вставить чтобы результаты find буферизировались и очередь файлов на удаление не была пустой (хотя буфера по умолчанию скорее всего хватит).

в теории самый быстрый способ find /path -type f -name 'what_to_find' -print0 | xargs -0 -P X rm где X завист от типа диска (для SSD больше чем для SATA) и наличия raid (на stripe можно попробовать X в два раза больше чем без него), но проще подобрать X эксперементально. А вообще для быстрого удаления в POSIX не хватает syscall-а для удаления нескольких файлов в одной директории за раз. Внтури FS эту операцию можно соптимизировать но API для этого нет.

Хороший вариант. Но он - единственный параллельный, поэтому вкупе с остальными рассматривать не стоит.

в теории самый быстрый способ find /path -type f -name 'what_to_find' -print0 | xargs -0 -P X rm где X завист от типа диска (для SSD больше чем для SATA) и наличия raid (на stripe можно попробовать X в два раза больше чем без него), но проще подобрать X эксперементально. А вообще для быстрого удаления в POSIX не хватает syscall-а для удаления нескольких файлов в одной директории за раз. Внтури FS эту операцию можно соптимизировать но API для этого нет.

не могу себе представить, зачем был бы нужен такой syscall

т.е. не для исправления факапов, а чтоб регулярно

не могу себе представить, зачем был бы нужен такой syscall

на StackOverflow вопросы как удалить папку с миллионами (если не миллиардами) файлов достаточно популярны. И все способы которые можно придумать работают медленно. Я сам с такими задачами не сталкивался. Если мне такое было бы нужно регулярно я наверно бы использовал ZFS и создавал отдельную FS для директории которую потом нужно будет удалить. zfs destroy должен отрабатывать быстро.

на StackOverflow вопросы как удалить папку с миллионами (если не миллиардами) файлов достаточно популярны. И все способы которые можно придумать работают медленно. Я сам с такими задачами не сталкивался. Если мне такое было бы нужно регулярно я наверно бы использовал ZFS и создавал отдельную FS для директории которую потом нужно будет удалить. zfs destroy должен отрабатывать быстро.

...и все эти вопросы - лечение факапов, обычно вида "PHP сессиями насрал"

Это всё хорошо, но будут ли ещё варианты с find и их аргументация?

а зачем?

лучший уже назвали :)

find ... -delete - вариант по умолчанию find .. -print0 | xargs -0 rm - чуть медленее из за того что нужно форкать rm но незначительно т. к. один форк на N файлов.

а зачем?

Академическая задача.

-exec rm -f {} \+

лучший уже назвали :)

Он кардинально отличается многопоточностью, не считается.

как это не считается, если он лучший? :)

Прочти предложение ДО запятой.

find ... -delete - вариант по умолчанию find .. -print0 | xargs -0 rm - чуть медленее из за того что нужно форкать rm но незначительно т. к. один форк на N файлов.

А -exec? На каком месте? ?

-exec самый медленный - по форку на файл.

а экзеков ДВА - один \; другой \+

и он должен быть чуть-чуть быстрее пайпа в xargs

ERROR: S client not available

хотя на практике слишком незначительно :)

сорри, на + не обратил внимание, тогда да - чуть быстрее xargs

Да, порядок возрастания времени выполнения таков: 1. -delete 2. -exec \+ 3. xargs 4. -exec \;

Да, порядок возрастания времени выполнения таков: 1. -delete 2. -exec \+ 3. xargs 4. -exec \;

Теперь бы ещё кто написал, почему. ?

-exec самый медленный - по форку на файл.

Не путай fork() и exec(). ?

это уже придирки: там и то и другое fork+exec

хотя на практике слишком незначительно :)

Ну, предположим, 100М файлов. Там разница ощутима должна быть. Если уж считать ощутимой и ту, которую я получил на Perl при сдвиге против умножения. ?

это уже придирки: там и то и другое fork+exec

Не возьмёт nginx от тебя pull request, бгг.

во первых nginx не принимает pull request-ы, им нужно слать патчи (hg changest patch) в maillist, а во вторых если буду писать патч то побольше времени потрачу на формулировки, чем для сообщения в чатике.

во первых nginx не принимает pull request-ы, им нужно слать патчи (hg changest patch) в maillist, а во вторых если буду писать патч то побольше времени потрачу на формулировки, чем для сообщения в чатике.

Радует, что хоть кто-то может аргументированно возражать. Если ещё завершишь мысль о find - будет и вовсе чудесно.

1. -delete - один unlink() на каждый файл 2. -exec \+ - то же самое полюс fork/exec на каждые N файлов 3. xargs - то же самое полюс передача списков файлов через pipe и связанный с этим overhead и задержки 4. -exec ; - fork/exec/unlink на каждый файл и если уж совсем погружаться в детали - запуск rm это не только fork/exec но и вся последовательность инициализации прочесса которая происходит после запуска процесса.

Вах, малаца! А вот дивапсы (@devops_ru) так и не шмогли ответить правильно. Да и вообще по делу ничего толком не сказали.

дык что еще ждать от девопсов

они только и умеют, что пиздокер

Ещё хуянсибл жи, который и настраивает пиздокер.

а шеф вагранта как же?

А сейчас в очередной раз думают, хорошо или плохо - RAID на SSD.

а шеф вагранта как же?

Это слишком сложно, о таком речь редко заходит.

Да в памяти все надо, в памяти

По заветам Энди Павло)

Да в памяти все надо, в памяти

Как find? ?

08:32 <Miha> а вот вам поржать https://github.com/andreevlex/vim-language-1c-bsl 08:39 <lavros> какие-то странные ощущения от наблюдения кода 1С в gvim. 08:44 <Miha> lavros, %анекдот про поклейку обоев гинекологом% 08:56 <mm> 1с - это не так смешно, там константы меняются редко по определению 09:02 <Miha> причём тут конкстанты и частота их изменения 09:02 <Miha> перестань разговаривать с голосами в своей голове уже 09:06 <Lazy> угу, довольно забавно. но почему бы и не па. :) 09:07 <Miha> Lazy, так кода в plain text нет там, выгрузки только что 09:07 <Miha> смысла в этой ебале примерно нихуя 09:08 <Miha> а сторонний редактор в конфигуратор 1сники не дают подключать, насколько я знаю 09:09 <Lazy> ну отчасти да, но, с другой стороны, даже для 7.7 есть приблуда, которая .md разбирает на тексты, чтоб можно было засунуть в vcs и развлекаться с ними групповухой. 09:10 <Miha> в 8.3 (вроде бы) появилась выгрузка конфигурации в 100500 xml'ек 09:10 <Miha> ну и обратное всасывание

щто ета было?

/me тоже не понял. @nuclight, какое отношение ванси имеет ко фре?

это #freebsd детка

Andrey, предлагаю почистить shitpost.

и эти люди смеялись над девопсами

лол.

зачем чистить. я придерживаюсь философии что бы тупость каждого видна была

Тоже вариант. Тогда пусть остаётся.

Ибо нехуй! ©