Читать надо не отдельные слова, а целиком предложения. 777 - это не волшебное заклинание, которое автоматически решает все проблемы с правами. Оно, во-первых, вообще никак не поможет, потому что прав на папку /home/adminsa/ всё равно нет. А во-вторых, пермишены тут совсем не при чём. Оставьте их как были.
Чтобы выполнить скрипт из чужого домашнего каталога, вы должны в sudoers указать этого пользователя.
Что-то вроде
apache ALL=(adminsa) NOPASSWD: /bin/bash /home/adminsa/check.sh
"Выдал права 777" кому? Файлу? А на папку adminsa какие права? Правильно - никаких. То есть внутри чужой домашней папки давать 7 не имеет ни малейшего смысла
И зачем давать всем читать и писать в этот файл, если нужно только исполнение?
sudo -u apache ну так вы и выполняете эту команду под апачем, а не под рутом. Впрочем, под рутом всё равно не стоит.
Нельзя этот скрипт положить в любую другую папку, доступную всем? Чтобы запускать не из-под рута?
Shurik, да, надо постоянно запущенный сервер вебсокет. Это отдельный сервис, как постгрес или nginx. То есть он по определению не "запускается" по какому-то событию, а работает постоянно.
И кстати, поэтому его лучше запускать через supervisor.
А что непонятно про обращение из приложения? JS нативно работает с вебсокетом - соединяемся, отправляем, получаем. К РНР это уже не имеет никакого отношения.
Есть правда вопрос с авторизацией, тут надо подумать. Хотя нет, куки вроде бы отправляются на другой порт
Я правильно понимаю, что у вас на машине стоит один энжинкс, который проксирует запросы к контейнерам (как минимум одному, с php-fpm)? Если так, то да, надо будет добавить еще одно правило проксирования. На новый контейнер с вебсокетом.
И мне тоже интересен такой момент. В чем причина вашего повышенного интереса к юникс сокетам? Какую проблему вы решаете? У меня складывается ощущение, что вы её себе выдумали исходя их каких-то туманных теоретических представлений, при том что никакой реальной проблемы использовать tcp сокеты у вас нет. Я прав?
Shurik, я ж вроде несколько раз повторил - ни nginx, ни php-fpm не имеют к вебсокету никакого отношения :)
Их надо оставить в покое и вообще не трогать.
Независимо от них поставить вебсокет сервер и работать с ним напрямую с клиента.
В теории, можно конечно настроить прокси в nginx на определённый локейшен, чтобы обращение шло по 443 порту, которое потом тупо проксируется на вебсокет сервер, но мне это кажется лишним. По крайней мере для теста точно не нужно добавлять лишнюю точку отказа. Потом, когда всё заработает, можно будет добавить такое проксирование, чтобы не настраивать SSL отдельно для вебсокета. Хотя это не такая уж и сложность.
Сами комменты я читал, но конкретно ваш про бублики - разумеется нет, поскольку вы его написали за две минуты до того, как написали этот. Теперь ваши проблемы с логикой становятся куда понятнее. Ну что ж, удачи вам в обучении. Её вам понадобится много раз уж с логикой не сложилось.
Я бы не рассматривал эту проблему как некий баг 11 версии.
А считаю, что это такой стандартный взбрык оптимизатора. Просто вот он вылез именно на этом запросе после апгрейда. Так совпало.
Хм. Кстати, а что за настройки-то?
Ну и традиционно - в первую очередь размер innodb_buffer_pool_size?
Может быть, 11-ке тупо требуется больше памяти, индекс не влезает в оперативку и она срывается в построчное чтение? Может, я конечно глупость говорю, но лишний раз проверить буфер innodb всё равно не помешает.
Сам недавно столкнулся с точно таким же поведением. Мария (впрочем, когда работал с Му, то же самое случалось) точно так же перекособочила порядок таблиц в запросе и получила какое-то дикое время выполнения. Заставил использовать мой порядок джойнов через STRAIGHT_JOIN, и всё залетало. Но вот как это лечить на системном уровне - и сам не знаю. Принимаю такие закидоны как данность и лечу вот хинтами.
Причём у меня БД не менялась, это новый запрос на старых данных.
Adamos, ему эту строчку показывает страница дебага в дев моде. Причём там должна быть и сама ошибка, но наш гений её в упор не видит. мда, там действительно будет пустой текст ошибки
Что странно - в этой строке кидается 404 исключение. Почему оно не обрабатывается корректно, а как обычная ошибка - загадка.
Тут наверно можно было бы подебажить, но только с нормальным челом, а не с этой истеричкой
Я предлагаю жаловаться не отдельный высер, а на весь вопрос целиком. Тем более, что он попадает сразу под несколько пунктов - и необходимо конкретизировать, и ищется поисковиком, и задание а не вопрос.
Чтобы выполнить скрипт из чужого домашнего каталога, вы должны в sudoers указать этого пользователя.
Что-то вроде
apache ALL=(adminsa) NOPASSWD: /bin/bash /home/adminsa/check.sh