killall больше не killall
Расскажите мне, чего я не знаю. После апдейта ОС команды killall и pgrep перестали видеть firefox:
vadim@aquila:~$ killall -KILL firefox firefox: процесс не найден Status: 1 vadim@aquila:~$ pgrep firefox Status: 1 vadim@aquila:~$ ps -A -o cmd | grep firefox | head -3 /usr/lib/firefox/firefox -ProfileManager --new-instance /usr/lib/firefox/firefox -contentproc -parentBuildID 20211121002925 -prefsLen 1 -prefMapSize 253532 -appdir /usr/lib/firefox/browser 5002 true socket /usr/lib/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 197 -prefMapSize 253532 -jsInit 278680 -parentBuildID 20211121002925 -appdir /usr/lib/firefox/browser 5002 true tab vadim@aquila:~$ 
wandrien ★★
02.12.21 11:14:20 MSK
Firefox почему-то для них теперь GeckoMain. В htop тоже при зависании был как GeckoMain, но сейчас как firefox-bin, но всё равно.
AVRS ★★
( 02.12.21 11:18:14 MSK )
Последнее исправление: AVRS 02.12.21 11:19:03 MSK (всего исправлений: 1)
Эти укурки зачем-то сменили названия процессов. Теперь пошло: GeckoMain, Web Content, вот это всё.
Korchevatel ★★★★★
( 02.12.21 11:19:39 MSK )
Ответ на: комментарий от Korchevatel 02.12.21 11:19:39 MSK
так можно убивать вкладки отдельно от самого браузера
пещерные регистранты как обычно
anonymous
( 02.12.21 11:22:03 MSK )
pgrep -f firefox gremlin_the_red ★★★★★
( 02.12.21 12:24:44 MSK )
Ответ на: комментарий от gremlin_the_red 02.12.21 12:24:44 MSK
Блин, точно. Thanks.
Однако у killall другой алгоритм, получается. Он ищет по /proc/PID/comm . А pgrep — по /proc/PID/cmdline .
wandrien ★★
( 02.12.21 12:34:15 MSK ) автор топика
Последнее исправление: wandrien 02.12.21 12:34:45 MSK (всего исправлений: 1)
Ответ на: комментарий от gremlin_the_red 02.12.21 12:24:44 MSK
И pkill -f туда же.
kardapoltsev ★★★★
( 06.12.21 04:40:00 MSK )
Harald ★★★★★
( 06.12.21 06:06:36 MSK )
Ответ на: комментарий от Harald 06.12.21 06:06:36 MSK
И rm /usr/lib/firefox/firefox , чтобы наверняка.
Nervous ★★★★★
( 06.12.21 06:30:04 MSK )
Ответ на: комментарий от AVRS 02.12.21 11:18:14 MSK
Получается как хочет себя называть процесс, так и называет. Какой простор для вредоносного ПО. Можно маскироваться под легитимное ПО, можно сделать чтобы находился не тот процесс.
X512 ★★★★★
( 06.12.21 06:38:05 MSK )
Просто тебе пришло обновление с руткитом, для твоего же блага.
anonymous
( 06.12.21 06:58:38 MSK )
Ответ на: комментарий от X512 06.12.21 06:38:05 MSK
t184256 ★★★★★
( 06.12.21 09:04:18 MSK )
После апдейта ОС команды killall и pgrep перестали видеть firefox
А крестик в углу окна для кого придумали?? Неужели фф настолько говно, что для его юзеров killall это уже привычный способ его прихлопнуть?
Crocodoom ★★★★★
( 06.12.21 09:57:23 MSK )
Ответ на: комментарий от X512 06.12.21 06:38:05 MSK
нету простора, по /proc/self/exe понятно кто это
anonymous
( 06.12.21 11:58:57 MSK )
Ответ на: комментарий от anonymous 02.12.21 11:22:03 MSK
Помнится в пещерные времена (году эдак в 2008) из-за кривостей браузеров и дыр в их API я наблюдал как одна вкладка открывала другую и стоило её закрыть, как она тут же открывалась. Браузер по закрытию окна не закрывался, а только убивался через xkill/killall/диспетчер задач в случае винды. Я помню тогда скрипт который это делал выдрал firebug-ом (в те времена нормального отладчика у браузеров не было, firebug был гораздо лучше) и где-то у меня он лежит до сих пор скорее всего в старых бекапах. Кстати, жил он долго. Года 1,5 во всех браузерах, прежде чем их пофиксили, хотя закрываться на крестик вроде раньше научили через год примерно. Конечно был ещё способ с выключением js-а, но далеко не все юзеры о нём знали.
А теперь похоже опять подобное можно будет запилить.
peregrine ★★★★★
( 06.12.21 12:14:40 MSK )
Последнее исправление: peregrine 06.12.21 12:15:36 MSK (всего исправлений: 1)
Ответ на: комментарий от Crocodoom 06.12.21 09:57:23 MSK
задолбаешься все 100500 крестиков нажимать, иногда из консолечки-пердолечки быстрее )
Abnormal memory consumption of process «GeckoMain» when uploading chunks of very large files in Firefox
I am trying to upload very large files (some are +30GB) by chunks. I was using Vue.JS and the dropzone library but noticed that when using Firefox (but not with Chrome) and uploading large files, the memory would blow up (the process «GeckoMain» seems to grow as big as the file itself). After writing my own chunk uploading code, the same problem appeared. So I reproduced the chunk uploading part in a smaller setup with just a bit of html/javascript and a flask server in the backend. You can see by uploading a large file the memory consumption growing in Firefox whereas using Chrome it does not. Does someone have an idea of what is going on here ? Should I use something different than file.slice ? While the process «GeckoMain» is growing in memory, if I use the developer tools and snapshot the memory, before, during and after the upload, it does not change. The frontend code :
File Uploader Here is the backend code as well :
import io from flask import Flask, request, render_template, jsonify from flask_cors import CORS app = Flask(__name__) CORS(app) @app.route("/", methods=["GET", "POST"]) def get_message(): return render_template("index.html") @app.route("/upload_static_file", methods=["POST"]) def upload_static_file(): file_form = request.form file = request.files.get("file") filepath = file.filename chunk_offset = int(file_form["chunkbyteoffset"]) with io.open(filepath, "ab") as f: f.seek(chunk_offset) chunk = file.stream.read() f.write(chunk) resp = return jsonify(resp), 200 if __name__ == "__main__": app.run(host="0.0.0.0", debug=True) UPDATE : TL;DR : Memory leak might come from very fast repeated calls to «file.slice» in Firefox, ReadableStream solves the memory problem but you lose the ability to read the file «anywhere» quickly. Following Keith advice to use a ReadableStream instead of file.slice, it is indeed possible to then upload chunks without the memory leak. This could suggest that fast repeated calls to file.slice in Firefox may cause some kind of memory leak. I couldn’t find any issue or statements about that behavior. ReadableStream solves the memory issue but then you lose the ability to retrieve any «slice» of the file you want without having to read through the beginning and discard it. Is there another way that could help me with that ? (For resumable uploads, I need to be able to read any slice of the file I want)
GeckoMa process seems to consume lot of CPU
I have been getting this weird problem lately, gecko process seems to consume lot of CPU processing , and this is becoming irritating , is there any fix for this and why is it happening ?
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4454 atif 20 0 4202036 655248 181484 S 82.7 8.1 53:49.64 GeckoMa+ 1746 root 20 0 24.3g 96492 59060 R 55.1 1.2 39:53.31 Xorg 1877 atif 20 0 4727352 357880 92456 S 20.9 4.4 7:44.11 gnome-s+ 15959 atif 20 0 2741620 304772 105704 S 12.0 3.8 2:02.30 Isolate+ 3389 atif 20 0 436708 52336 37936 S 6.0 0.7 8:04.54 python3 1061 root -51 0 0 0 0 S 2.0 0.0 2:33.65 irq/148+ 5140 atif 20 0 830204 49108 37820 S 2.0 0.6 0:05.55 gnome-t+ 11009 atif 20 0 36.4g 84268 67616 S 1.3 1.0 0:25.86 webwork+ 957 www-data 20 0 1448184 144312 20224 S 1.0 1.8 0:17.73 apache2 20252 atif 20 0 20868 4276 3224 R 0.7 0.1 0:00.19 top 1922 atif 20 0 162916 5944 5724 S 0.3 0.1 0:01.48 at-spi2+ 2118 atif 20 0 1039496 22444 5556 S 0.3 0.3 0:05.80 snap-st+ 4454 atif 20 0 4202036 655248 181484 S 82.7 8.1 53:49.64 GeckoMa+ 1746 root 20 0 24.3g 96492 59060 R 55.1 1.2 39:53.31 Xorg 1877 atif 20 0 4727352 357880 92456 S 20.9 4.4 7:44.11 gnome-s+ 15959 atif 20 0 2741620 304772 105704 S 12.0 3.8 2:02.30 Isolate+ 3389 atif 20 0 436708 52336 37936 S 6.0 0.7 8:04.54 python3 1061 root -51 0 0 0 0 S 2.0 0.0 2:33.65 irq/148+ 5140 atif 20 0 830204 49108 37820 S 2.0 0.6 0:05.55 gnome-t+ 11009 atif 20 0 36.4g 84268 67616 S 1.3 1.0 0:25.86 webwork+
Ubuntu version
Description: Ubuntu 20.04.3 LTS Release: 20.04 Codename: focal Firefox (Gecko Main) using 100% CPU, unable to request pages, on Ubuntu 18
Shared components used by Firefox and other Mozilla software, including handling of Web content; Gecko, HTML, CSS, layout, DOM, scripts, images, networking, etc. Issues with web page layout probably go here, while Firefox user interface issues belong in the Firefox product. (More info)
Watch This Product
Networking ▾
Core :: Networking
For bugs in Mozilla’s modular networking library (aka «Netlib» or «Necko».) The networking library supplies the software interface that Mozilla uses to access physical transports (e.g. the Internet and local drives), perform URL resolutions, and handle a variety of networking protocols.