Partkeepr: Setup2/2 Pemanasan Cache - Respons Tidak Valid dari Server

Silakan lihat di log kesalahan server web Anda atau di mana instalasi PHP Anda mencatat kesalahannya

Pada instalasi stok debian/ubuntu, kesalahan masuk ke /var/log/Apache2/error_log

Ini adalah isi dari /var/log/Apache2/error.log

errorLog.txt

EDIT: Sepertinya kosong, menurut php.ini seharusnya menulis semua jenis kesalahan.
Umm, ini terdengar aneh tetapi berada di bawah Proxy dapat berdampak? Juga, saya melihat banyak kesalahan kode yang tidak digunakan lagi - tetapi sekali lagi tidak yakin apakah itu kesalahannya.

Berikut ini adalah kesalahan terakhir di bawah partkeepr/app/logs/setup.log

php.INFO: Mendefinisikan metode getGlobals() dalam ekstensi "assetic" tidak digunakan lagi tanpa secara eksplisit mengimplementasikan Twig_Extension_GlobalsInterface.
Setelah banyak teks saya melihat ini adalah panggilan pemanasan:
...,"class":"PartKeepr\SetupBundle\Controller\CacheWarmupSetupController"... {"function":"cacheWarmupAction"....

Sekarang lihat di awal, adalah orang yang memicu kesalahan ini:
...{"type":16384,"file":"/var/www/partkeepr-1.2.0/app/cache/setup/classes.php","line":3494,"level":28928," stack":[{"function":"handleError","class":"Symfony\Component\Debug\ErrorHandler","type":"->"},{"file":"/var/www/partkeepr- 1.2.0/app/cache/setup/classes.php","line":3494,"function":"trigger_error"},{"file":"/var/www/partkeepr-1.2.0/app/cache /setup/classes.php","line":3455,"function":"initGlobals","class":"Twig_Environment","type":"->"},{....
@felicitus

Hai
Cobalah
apt-get install php-apcu php-apcu-bc

@FinalHopee apakah perlu waktu lama hingga pesan respons yang tidak valid muncul?

Ya, sepertinya 2 menit. Saya memang mengonfigurasinya ke 120 seperti yang direkomendasikan.
Saya berhasil menginstal apcu - tidak ada peringatan lagi.
Tapi kesalahan yang sama.

Maka Anda harus meningkatkan max_execution_time - peringatan cache adalah operasi intensif disk yang dapat dengan mudah kehabisan waktu pada disk yang lambat.

Am 11. Februar 2017 12:02:22 MEZ schrieb FinalHopee [email protected] :

Ya, sepertinya 2 menit. Saya memang mengonfigurasinya ke 120 seperti yang direkomendasikan.
Saya berhasil menginstal apcu - tidak ada peringatan lagi.
Tapi kesalahan yang sama.

--
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment -279136866

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

atur max_execution_time ke 600, tetapi untuk beberapa alasan ini menunjukkan kesalahan tepat setelah berjalan 2 menit.
Saya me-restart layanan Apache2, bahkan me-reboot Host.

Besok saya akan mencoba instalasi baru pada PC fisik.
Akan membuat Anda tetap diposting, terima kasih atas bantuan apa pun!

Dapatkah Anda memverifikasi dengan menggunakan file phpinfo.php bahwa pengaturan telah berlaku?

Am 11. Februar 2017 13:20:32 MEZ schrieb FinalHopee [email protected] :

atur max_execution_time ke 600, tetapi untuk beberapa alasan ini menunjukkan kesalahan
tepat setelah berjalan 2 menit.
Saya me-restart layanan Apache2, bahkan me-reboot Host.

Besok saya akan mencoba instalasi baru pada PC fisik.
Akan membuat Anda tetap diposting, terima kasih atas bantuan apa pun!

--
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment -279140451

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

ya, terlihat bagus.
data phpinfo terlampir.
Mengekspor phpinfo ke html, Anda dapat mengedit akhir atau membuka melalui browser agar mudah dilihat.
Apakah semuanya tampak baik-baik saja di sana?
info.html.txt

Memperbarui:
Pertama terima kasih semua atas bantuan dan waktu!
Kedua, saya memang perlu menambah pengetahuan dalam hal ini untuk memberi masukan lebih banyak tentang bagaimana dan mengapa itu berhasil.

Lagi pula itu masalah proxy, seperti yang saya kira.
Apa yang saya lakukan hari ini adalah saya menggunakan mesin baru yang kami miliki, PC yang bagus - menginstal Ubuntu yang bersih dan semua yang diperlukan sesuai dengan panduan Partkeepr Wiki dan itu tidak berhasil.
Kemudian, saya ingin menguji proxy yang digunakan tempat kami, jika itu masalahnya.
Yang saya lakukan adalah mencabut kabel jaringan dari pc dan mencoba lagi proses setup dan setelah menunggu 5 - 10 detik pemanasan selesai!
Tes yang sama telah saya lakukan pada PC lain yang saya ingin gunakan Partkeepr, dan itu berhasil juga!

Menguji masalah lebih lanjut saya mencolokkan kabel dan meluncurkan pengaturan lagi.
Menggunakan alamat yang sama dan browser yang sama ( localhost/setup ) saya mendapatkan kesalahan itu lagi - Respons Server Tidak Valid
Tidak yakin bagaimana cara pergi dan men-debugnya lebih jauh dari sini, tetapi sepertinya ada sesuatu yang menghalangi dan itu ada hubungannya dengan proxy perusahaan kami. - Sekali lagi saya melakukan prosedur ini pada PC sendiri menggunakan alamat localhost. Dari jarak jauh itu tidak akan berfungsi juga tentu saja.

Singkatnya, ini berfungsi sekarang, tetapi mengapa itu tidak berhasil, saya belum yakin.

Hmm ini mungkin masalah karena PartKeepr benar-benar menjalankan cronjobs saat menghangatkan cache - mungkin itu alasan mengapa waktu habis pada posisi itu? Perlu menerapkan dukungan proxy untuk PartKeepr, membiarkan masalah terbuka

Masalah proxy lain yang saya temukan adalah dukungan octopart.
Tanpa proxy, ia berhasil menemukan item tetapi mengubah jaringan di bawah proxy gagal.

Ya, saat ini tidak ada dukungan untuk proxy di PartKeepr.

Punya masalah yang sama, tetapi tidak dapat menonaktifkan proxy. Apakah ada cara untuk mengubah langkah "pemanasan cache", agar berfungsi tanpa koneksi internet?

ya, Anda dapat mencoba menemukan baris yang relevan dalam kode dan menonaktifkannya. Saat ini saya tidak punya waktu untuk memperbaiki masalah ini, maaf :(

saya khawatir keterampilan perangkat lunak saya tidak cukup baik untuk itu :(

Sepertinya web/setup/js/Cards/UserSetupCard.js
Baris komentar // this.tests.push(New PartKeeprSetup.WarmupCacheSetup());

Mengomentari bagian pemanasan cache juga membantu saya (Windows VM dengan proxy).

Harap dicatat bahwa pemanasan cache diperlukan agar PartKeepr berjalan dengan benar - Saya TIDAK merekomendasikan melakukannya - jika tidak maka akan menyebabkan masalah seperti #962

PartKeepr mengasumsikan bahwa ia memiliki konektivitas internet yang fungsional.

Untuk mengatasi masalah ini, saya melakukan hal berikut:
1) Saya menghapus php7.2 dengan perintah berikut:
apt-get hapus php7.2*

2) Saya kemudian menginstal php7.1 (paket perangkat lunak php7.1 tidak lagi tersedia di repositori default Ubuntu 18.04.1 yang dikonfigurasi)

Silakan merujuk ke situs berikut untuk instruksi tentang cara menginstal php7.1:
https://Gist.github.com/wayanjimmy/f1679e4c9dc9251fd9df520f5bbe2b5b

Saya juga melihat gejala yang sama, tetapi tidak ada diskusi di sini yang tampaknya berlaku untuk situasi saya. Beberapa info:

• Kesalahan muncul cukup banyak tepat setelah 2 menit (seperti yang juga dikomentari @FinalHopee ), meskipun saya telah mengatur max_execution_time menjadi 240 detik (saya juga memeriksa ini dengan phpinfo.php)
• Tidak ada server proxy yang digunakan. Karena @FinalHopee membuatnya bekerja dengan mencolokkan kabel, saya memotong akses internet sementara dengan memfilter ip di router saya, tetapi itu tidak ada bedanya.
• Saya menggunakan raspberry pi 2
• Php yang diinstal adalah versi 7.0
• File setup.log tidak mengandung kesalahan apa pun selain kesalahan yang "ditinggalkan", juga terlihat oleh orang lain.

Adakah yang tahu bagaimana saya bisa terus mencoba menyelesaikan masalah ini? Satu-satunya tebakan saya sejauh ini adalah bahwa ada batas waktu 2 menit, yang terutama terlalu sedikit untuk rpi.

Terima kasih sebelumnya!

Saya menghitungnya, dan itu tepat 2 menit, pada detik

Sama disini :(
Diinstal pada NAS synology.
Semua bagian penyiapan berjalan dengan benar setelah beberapa penyetelan di NAS-OS.
Tapi, pada "pemanasan cache" gagal setelah sekitar 2Minutes.

• Apache 2.2 & 2.4 diuji
• PHP 5.6, 7.0 & 7.2 diuji
• PHP Timeouts meningkat menjadi nilai yang sangat besar
• Pengaturan diuji dengan phpinfo setelah perubahan
• "Timeout 600" di "/usr/local/etc/Apache24/conf/httpd24.conf" disertakan

Tidak ada cara untuk membuatnya bekerja - Itu sedikit membuat frustrasi ...

Saya pikir itu dapat dipecahkan untuk menjalankan instalasi melalui baris perintah ssh.
Mungkin Anda dapat menemukan solusi membaca utas ini
https://github.com/partkeepr/PartKeepr/issues/916#issue -266508225
Saya menjalankannya di Synology, dan mengalami masalah yang sama.

Saya mengalami masalah ini hari ini dengan instalasi baru (FreeBSD 11, PHP 7.2) dan menemukan fungsi baris perintah untuk ini:

root<strong i="6">@server</strong>:/var/www/partkeepr # php ./app/console cache:warmup
 // Warming up the cache for the dev environment with debug true

 [OK] Cache for the "dev" environment (debug=true) was successfully warmed.

Sekarang saya sedang men-debug kesalahan berikutnya... yang tampaknya terkait dengan fungsi kompatibilitas mundur APCU.

baru saja mengalami masalah yang sama (di Ubuntu 16.04, PHP 7.0, Apache 2.4.18)
cache manual: pemanasan berfungsi (lihat posting di atas), tetapi pemanasan terus gagal melalui UI web
menginstal php-apcu-bc gagal: 'tidak memiliki kandidat instalasi'

saya akan mencoba lagi menginstal di ubuntu 18.04

@thijz masalah Anda melibatkan proxy (maju), yang tidak dapat Anda hindari?

Proksi terbalik nginx saya memiliki batas waktu default 60 detik, jadi ini membuat saya tersandung. Saya tidak yakin bahwa ini adalah masalah PartKeepr. Benar-benar terlihat seperti masalah konfigurasi proxy.

Mengatasi nilai batas waktu proxy yang tepat memperbaiki hal-hal untuk saya.

Referensi: https://www.smashinglab.com/fix-504-gateway-time-nginx/

Hai kawan! Saya ingin menambahkan bug ini. Saya menginstal PartKeepr di OrangePi (yang sama sekali tidak cepat) di mana pemanasan cache membutuhkan waktu 2,5 menit (dan max_execution_time diatur ke 3 menit). Namun, seperti yang saya pahami, batas waktu 2 menit diatur di suatu tempat di frontend:

Pada tangkapan layar, Anda dapat melihat 2 permintaan warmupCache, satu dari antarmuka web yang dibuat selama prosedur penyiapan, yang lain dibuat secara manual melalui Chrome devtools. Yang pertama dibatalkan pada 2m, yang lain berhasil setelah 2,5 menit (dan kembali OK). Jadi, saat pemanasan cache berfungsi, frontend menghentikan permintaan sebelum selesai. Apakah ada cara untuk meningkatkan batas waktu di sisi JS?

Ya, batas waktu ada di sini: https://github.com/partkeepr/PartKeepr/blob/master/web/setup/js/SetupTests/AbstractTest.js#L96
Entah bagaimana cara mengubahnya dengan benar hanya untuk permintaan ini

Saya melihat masalah yang sama ketika mencoba untuk mengatur pengembangan gambar buruh pelabuhan di Windows (menggunakan Docker w/ WSL2, yang memiliki kinerja sistem file yang sangat buruk). Log menunjukkan bahwa sisi server akhirnya mengembalikan respons yang berhasil, tetapi UI telah keluar kesalahan pada saat diterima, seperti yang ditunjukkan oleh @positron96 .

Saya akan mencoba dan menguji permintaan tarik @ positron96 untuk melihat apakah itu berfungsi untuk kasus penggunaan ini.