1. Ctrl + Alt + L
2. gnome-screensaver-command -l
sadmin
Идеята е, че виждам един wifi сигнал и искам да го използвам ;) , но незна точно откъде идва. За да използвам неговия максимум трябва да насоча антената точно към него :) и за целта използвам едно простичко приложение wavemon .
wavemon -i wlan1
За да се случат нещата по- оптимален начин е необходимо да се ползва и добра антена разбира се. Аз използвам тази на Danets (danets.com).
Благодарности на онлайн магазина: restart.bg
Проблема е, че на лаптопа използвам usb мишка и не използвам touchpad–а. Когато пиша на клавиатурата много често местя мишката и това е изключително дразнещо. За да се оправи тази глупост просто ще деактивирам touchpad-а.
Метод 1:
Просто се изпълнява: synclient TouchpadOff=1
Метод 2:
apt-get update && apt-get install gpointing-device-settings
Проблема е, че докато си работи системата на Mint изведнъж диода на клавиатурата за Num Lock започва да светва и изгасва, т.е. вклчва се и се изключва от което приемането на команди от клавиатурата става доста трудничко :) Друго нещо което се забелязва е голямото използване на процесора от mate-settings-d
Ето и снимка:
Решение на тази глупост:
sudo apt-get update
sudo apt-get install numlockx dconf-tools
1. Изпълнява се dconf-editor
org > mate > desktop > peripherals > keyboard
Премахване на тикче на remember-numlock-state
2. Файл: /etc/mdm/Init/Default
преди "exit 0"
if [ -x /usr/bin/numlockx ]; then
exec /usr/bin/numlockx on
fi
Защо се случва грешката "413 Request Entity Too Large" в nginx?
В apache2 php е сетнат upload_max_filesize 60 MB , но е забравено в nginx да се сетне client_max_body_size също на 60 MB и затова.
Ето го решението:
Файл: /etc/nginx/sites-enabled/example.com.8133
server
{
…
location /
{
…
client_max_body_size 60m;
…
}
…
}
Файл: /etc/php5/apache2/php.ini
…
upload_max_filesize = 60M
…
/etc/init.d/apache2 reload;
/etc/init.d/nginx reload;
echo 1 > /proc/sys/vm/block_dump
tail -f /var/log/syslog
Резултат :)
Oct 28 16:02:49 beta kernel: [55628161.993810] kjournald(349): WRITE block 1983406184 on sda2
Oct 28 16:02:49 beta kernel: [55628161.993812] kjournald(349): WRITE block 2803287720 on sda2
Oct 28 16:02:49 beta kernel: [55628161.994474] rs:main Q:Reg(25405): WRITE block 429161088 on sda2
Oct 28 16:02:49 beta kernel: [55628161.994665] kjournald(349): WRITE block 1947309000 on sda2
Oct 28 16:02:51 beta kernel: [55628164.076174] flush-8:0(348): WRITE block 1997551216 on sda2
Oct 28 16:02:51 beta kernel: [55628164.076176] flush-8:0(348): WRITE block 1997551224 on sda2
Oct 28 16:02:51 beta kernel: [55628164.076178] flush-8:0(348): WRITE block 1997551232 on sda2
Oct 28 16:02:51 beta kernel: [55628164.076180] flush-8:0(348): WRITE block 1997551240 on sda2
Oct 28 16:02:51 beta kernel: [55628164.076183] flush-8:0(348): WRITE block 1997551248 on sda2
Oct 28 16:02:51 beta kernel: [55628164.076185] flush-8:0(348): WRITE block 1997551296 on sda2
Oct 28 16:02:51 beta kernel: [55628164.076188] flush-8:0(348): WRITE block 1997551328 on sda2
Oct 28 16:02:52 beta kernel: [55628164.624602] apache2(4498): dirtied inode 62352816 (other_vhosts_access.log) on sda2
Oct 28 16:03:14 beta kernel: [55628187.122972] pyzor(4521): dirtied inode 16826650 (snsqV8) on sda2
Oct 28 16:03:14 beta kernel: [55628187.123212] pyzor(4521): dirtied inode 16826650 (?) on sda2
Oct 28 16:03:14 beta kernel: [55628187.123933] pyzor(4521): dirtied inode 16826651 (?) on sda2
Oct 28 16:03:26 beta kernel: [55628198.518779] mysqld(26078): dirtied inode 63300606 (labdatastore.MYD) on sda2
Oct 28 16:03:26 beta kernel: [55628198.607859] mysqld(26078): dirtied inode 63300606 (labdatastore.MYD) on sda2
Oct 28 16:03:26 beta kernel: [55628198.607888] mysqld(26078): dirtied inode 63300605 (labdatastore.MYI) on sda2
Oct 28 16:03:26 beta kernel: [55628198.607891] mysqld(26078): dirtied inode 63300605 (labdatastore.MYI) on sda2
За да се спре дебуг-а
echo 0 > /proc/sys/vm/block_dump
Идеята е, че имаме много wordpress блогове на тази машина и много от тях са наспамени или просто имат много коментари. За да се следи прилагам просто решение:
find /var/lib/mysql/ -type f -size +1000k -name "*_comments.MYD" -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'
Резултат:
/var/lib/mysql/vhostext/wp_comments.MYD: 1,8M
Вижда, сече блога с база "vhostext" има таблица wp_comments от 1.8 MB, най- вероятно над 1000 коментара. Хубаво е да се провери.
Интересни аргументи:
аргумента 1000к всъщност е 1MB т.е. да показва файловете по- големи от 1MB.
Името което се търси е "*_comments.MYD" и има звезда защото не всички wordpress блогове ползват за префикс "wp_"
Това решение като цяло не казва какво трябва да се изтрие , а какво е хубаво да се погледне …
Всички коментари се записват в табицата "wp_comments"
mysql> describe wp_comments;
+----------------------+---------------------+------+-----+---------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------+---------------------+------+-----+---------------------+----------------+
| comment_ID | bigint(20) unsigned | NO | PRI | NULL | auto_increment |
| comment_post_ID | bigint(20) unsigned | NO | MUL | 0 | |
| comment_author | tinytext | NO | | NULL | |
| comment_author_email | varchar(100) | NO | | | |
| comment_author_url | varchar(200) | NO | | | |
| comment_author_IP | varchar(100) | NO | | | |
| comment_date | datetime | NO | | 0000-00-00 00:00:00 | |
| comment_date_gmt | datetime | NO | MUL | 0000-00-00 00:00:00 | |
| comment_content | text | NO | | NULL | |
| comment_karma | int(11) | NO | | 0 | |
| comment_approved | varchar(20) | NO | MUL | 1 | |
| comment_agent | varchar(255) | NO | | | |
| comment_type | varchar(20) | NO | | | |
| comment_parent | bigint(20) unsigned | NO | MUL | 0 | |
| user_id | bigint(20) unsigned | NO | | 0 | |
+----------------------+---------------------+------+-----+---------------------+----------------+
Стойностите на колоната comment_approved са: 0 , 1, spam
# Изтриване на всички not approved коментари
DELETE FROM wp_comments WHERE comment_approved = 0;
# Изтриване на всички approved коментари
DELETE FROM wp_comments WHERE comment_approved = 1;
# Изтриване на всички спам коментари
DELETE FROM wp_comments WHERE comment_approved = 'spam';
# Изтриване по дата
DELETE FROM wp_comments WHERE comment_date > '2004-11-15 01:10:04' AND comment_date <= '2004-11-20 00:10:04'
# Изтриване на всички коментари
TRUNCATE wp_comments;