Такая ошибка появляется по многим причинам, но в основном при обновлении агента или сервера. Как итог, триггер больше не проверяется, а в Web-ке отображается серым цветом.
Исправить её напрямую нельзя, только через ручную правку значений в базе:
Такая ошибка появляется по многим причинам, но в основном при обновлении агента или сервера. Как итог, триггер больше не проверяется, а в Web-ке отображается серым цветом.
Исправить её напрямую нельзя, только через ручную правку значений в базе:
If you are running OpenVPN as a client, and the server you use is using push “redirect-gateway” then your client redirects all internet traffic over the VPN. Sometimes clients do not want this, but they can not change the server’s configuration. This page explains how to override redirect-gateway so the client does not need to redirect internet even though the server says to.
Один раз был крупный alter через репликацию на slave и он в этот момент ребутнулся по питанию. Сам mysql стартует нормально, но при попытке изменить одну из таблиц получаю сообщение:
ERROR 1050 (42S01): Table 'pirate/#sql-ib1293541' already exists
Захожу в папку базы pirate и вижу, что есть файлик #sql-ib1293541.ibd и больше ничего подозрительного. Пробую удалить разными методами:
Добавляем в раздел server/http такие строки:
gzip on
gzip_types text/plain application/xml application/x-javascript application/javascript text/javascript text/css text/xml;
gzip_comp_level 3;
gzip_buffers 128 4k;
По дефолту эта опция стоит в off. То есть, если вы забыли поставить её в on (или поставили уже после того, как заменили все диски), то для применения нужно использовать команду:
# zpool online -e ZPOOL DISK
для каждого диска из пула ZPOOL
При настраивании разного рода сервисов приходится сталкиваться с тем, что на одном интерфейсе, находится несколько алиасов. Всё бы ничего, но возникают вопросы: с каким src address будет уходить пакет?
Если алиасы из разных подсетей, то ответ сразу ясен. А если нет?
Я обновлялся с 12.10 до 14.04.
Что бы нормально обновить и без ругани, сначала нужно удалить все i386 пакеты (лучше сохранить их список куда-то в файл, что бы потом заново проинсталлить). Удаляем такой командой:
# for i in `dpkg -l | grep i386 | grep -v amd64 | awk '{print $2}'`; do dpkg -P $i; done
Причём это нужно будет делать не 1 раз, так как будут зависимости и не всё удалится с первого раза. Мне пришлось запустить команду раз 6.
Включить пробы dtrace для java, как оказалось, не совсем очевидно. А всё дело в механизме lazy load, который активирует их только тогда, когда явно к ним обратится и только при выполнении таких условий:
1) java должна поддерживать hotspot:
# java -version
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) Server VM (build 24.60-b09, mixed mode)
Если вы хотите пересобрать ядро через GCC, а не через CLANG, то нужно добавить в /etc/make.conf такие строки
WITHOUT_CLANG=YES
WITH_GCC=YES
WITH_GNUCXX=YES
CC=gcc
Описание лучше привести без перевода:
When rebooting after a panic, send an encrypted email containing basic
dump metadata along with a kernel backtrace, in order to assist FreeBSD
developers in identifying and fixing common panics.