Co s cachovanymi soubory v tempu, ktere vytvoril jiny uzivatel (cron kdyby command)
- Jan Mikeš
- Člen | 771
Ahoj, posledni dobou mam docela problemy s tim, ze vecer po deployi vymazu cache a nastavim prava (k tomu pouzivam automaticky deploy script, ktery provadi nasledujici):
rm -rf ./temp || echo "$(tput setaf 1)Failed removing ./temp directory$(tput sgr0)"
mkdir -p temp/cache && mkdir -p temp/proxies && chmod -R 777 ./temp && echo "$(tput setaf 2)Re-created ./temp directory$(tput sgr0)" || echo "$(tput setaf 1)Failed to create ./temp directory$(tput sgr0)"
echo 'flush_all' | nc localhost 11211 && echo "$(tput setaf 2)Memcached cache cleared$(tput sgr0)" || echo "$(tput setaf 1)Failed to clear memcached cache$(tput sgr0)"
cp ./libs/.htaccess ./temp/.htaccess || echo "$(tput setaf 1)Failed creating temp/.htaccess!$(tput sgr0)"
cp ./libs/web.config ./temp/web.config || echo "$(tput setaf 1)Failed creating temp/web.config!$(tput sgr0)"
Mazani cache by jeste takovy problem nebyl, problem ale nastava v pripade,
ze web nenavstivi zadny realny uzivatel → cache se nevytvori a vytvori se az
v pripade spusteni v noci nejakym cronem v podobe Kdyby\Console
command. Ty maji totiz jineho ownera a to root
(group
www-data
), kdezto pokud je cache vytvorena beznym zpusobem,
navstevou webu, je cache vytvorena s ownerem www-data
(group
www-data
).
Pote se zobrazuje klasicka chybova hlaska s pravy na souborech
[2016-02-17 01-25-49] PHP Warning: fopen(/var/www/XYZ/app/../temp/cache/_Doctrine.Annotations/_8f4d8cfd73d8af609f50010e195f267d): failed to open stream: Permission denied in /var/www/XYZ/vendor/nette/caching/src/Caching/Storages/FileStorage.php:148 @ http://XYZ/order-event/170/
Na VPS mi momentalne bezu Ubuntu 12.04, nejake napady co s tim? Zmenit uzivatele, ktery cronem spousti PHP?
Tento konkretni cronjob, ktery chybu zpusobuje mam nastaven klasicky:
1 * * * * php /var/www/XYZ/www/index.php app:my-random-command >/dev/null 2>&1
- snake.aas
- Člen | 25
greeny: pokud jsem to pochopil, tak řeší přesně opačný problém. Že crony běží pod rootem a chyba je pak na webu
Lexi: Crony bych nepouštěl pod rootem, ale pod nějakým jiným
uživatelem. Klidně www-data. Dá se to nastavit buď přes crontab
crontab -u www-data -e
a nebo přímo v /etc/crontab
kde před příkaz ještě předřadíš uživatele, pod kterým má
cron běžet.
- Jan Mikeš
- Člen | 771
Presne jak pise @snake.aas crony mi spousti root a tudiz ten problem nema, ale pokud je prvni, prvni kdo vygeneruje cache (pokud ne, je to ok, protoze root je root :-) a precte vsechno). Proctu a vyzkousim, diky za tip.
** Edit: Funguje, parada diky! **
Editoval Lexi (17. 2. 2016 12:33)