I just started using plack yesterday and I ran the commands below to get started. Everything was fine. The next morning I found that plack daemon was not running. I needed to rerun both:
sudo koha-plack --enable <instancename> sudo koha-plack --start <instancename> Also, for a while now each morning I need to re-start zebra as it seems to stop on a daily basis sudo koha-start-zebra peischool
Potentially related is that timeout preference is not respecting the value from administration. I set it to both 7d and 604800. No matter what I choose I need to login again daily to koha administration site. Rebooting does not seem to be the cause of these problems. I just ran 'sudo reboot' and the server came back with all apache/mysql and daemons were running before and after the reboot. Also it didn't cause my session to timeout, which is good. I'm Running Koha 16.05.02 and Debian 8.5 Any Ideas to why the zebra and plack continue to need manual intervention daily and why timeout is not respecting the value from administration? -- View this message in context: http://koha.1045719.n5.nabble.com/Zebra-Plack-Timeout-Issue-tp5905919.html Sent from the Koha-general mailing list archive at Nabble.com.
Hi, try to swith the system preference SessionStorage to mysql instead of memcached 2016-10-04 19:31 GMT+02:00 rfblanchard <rfblanchard@hotmail.com>:
I just started using plack yesterday and I ran the commands below to get started. Everything was fine. The next morning I found that plack daemon was not running. I needed to rerun both:
sudo koha-plack --enable <instancename> sudo koha-plack --start <instancename> Also, for a while now each morning I need to re-start zebra as it seems to stop on a daily basis sudo koha-start-zebra peischool
Potentially related is that timeout preference is not respecting the value from administration. I set it to both 7d and 604800. No matter what I choose I need to login again daily to koha administration site.
Rebooting does not seem to be the cause of these problems. I just ran 'sudo reboot' and the server came back with all apache/mysql and daemons were running before and after the reboot. Also it didn't cause my session to timeout, which is good.
I'm Running Koha 16.05.02 and Debian 8.5 Any Ideas to why the zebra and plack continue to need manual intervention daily and why timeout is not respecting the value from administration?
-- View this message in context: http://koha.1045719.n5.nabble.com/Zebra-Plack-Timeout-Issue-tp5905919.html Sent from the Koha-general mailing list archive at Nabble.com. _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Jonathan has covered the session timeouts, as for the restarting, you should only ever have to do the enable once. Re the --start can you check if the time they are stopping is when logrotate is running? Or some other cron job Chris On 5 October 2016 6:31:31 AM NZDT, rfblanchard <rfblanchard@hotmail.com> wrote:
I just started using plack yesterday and I ran the commands below to get started. Everything was fine. The next morning I found that plack daemon was not running. I needed to rerun both:
sudo koha-plack --enable <instancename> sudo koha-plack --start <instancename> Also, for a while now each morning I need to re-start zebra as it seems to stop on a daily basis sudo koha-start-zebra peischool
Potentially related is that timeout preference is not respecting the value from administration. I set it to both 7d and 604800. No matter what I choose I need to login again daily to koha administration site.
Rebooting does not seem to be the cause of these problems. I just ran 'sudo reboot' and the server came back with all apache/mysql and daemons were running before and after the reboot. Also it didn't cause my session to timeout, which is good.
I'm Running Koha 16.05.02 and Debian 8.5 Any Ideas to why the zebra and plack continue to need manual intervention daily and why timeout is not respecting the value from administration?
-- View this message in context: http://koha.1045719.n5.nabble.com/Zebra-Plack-Timeout-Issue-tp5905919.html Sent from the Koha-general mailing list archive at Nabble.com. _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Upgraded to koha 16.05.04 and debian 8.6 today -my sessionStorage was mysql. I tried to change it to memcached to see if any better. -I checked and no crontab existed for /root/or the koha user on the server Not sure how to determine exactly when plack and zebra are being killed. -- View this message in context: http://koha.1045719.n5.nabble.com/Zebra-Plack-Timeout-Issue-tp5905919p590592... Sent from the Koha-general mailing list archive at Nabble.com.
Hi R. F.
-I checked and no crontab existed for /root/or the koha user on the server
Are you aware of the fact there are not only the crontabs for Linux user "root" and the one of your Linux user for Koha but also the cronjobs in the following files? * /etc/cron.d/koha-common * /etc/cron.hourly/koha-common * /etc/cron.daily/koha-common * /etc/cron.monthly/koha-common Hope this helps. Best wishes: Michael -- Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 261 55 61 · E mik@adminkuhn.ch · W www.adminkuhn.ch
And also the one that I suspect is doing it /etc/logrotate.d/koha-common Chris On 5 October 2016 at 08:20, Michael Kuhn <mik@adminkuhn.ch> wrote:
Hi R. F.
-I checked and no crontab existed for /root/or the koha user on the server
Are you aware of the fact there are not only the crontabs for Linux user "root" and the one of your Linux user for Koha but also the cronjobs in the following files?
* /etc/cron.d/koha-common * /etc/cron.hourly/koha-common * /etc/cron.daily/koha-common * /etc/cron.monthly/koha-common
Hope this helps.
Best wishes: Michael -- Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 261 55 61 · E mik@adminkuhn.ch · W www.adminkuhn.ch
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
I set the SessionStorage back to MySQL as it seems more reliable even through reboots. Thanks for letting me know about those other crons. I should have known about those. I see why you suspected logrotate as it shuts down and restarts plack and zebra. I manually triggered: sudo logrotate -f /etc/logrotate.d/koha-common It briefly took those items down but they came back up again no issue. Typically its been in the morning when I notice the zebra/plack is down. It down yesterday but OK today which is almost worse as I did nothing to fix it. I'll continue to monitor. -- View this message in context: http://koha.1045719.n5.nabble.com/Zebra-Plack-Timeout-Issue-tp5905919p590608... Sent from the Koha-general mailing list archive at Nabble.com.
For the timeout, you can also try to switch off SessionRestrictionByIP. Please keep us in touch if it fixes the issue. 2016-10-04 21:11 GMT+02:00 rfblanchard <rfblanchard@hotmail.com>:
Upgraded to koha 16.05.04 and debian 8.6 today -my sessionStorage was mysql. I tried to change it to memcached to see if any better. -I checked and no crontab existed for /root/or the koha user on the server
Not sure how to determine exactly when plack and zebra are being killed.
-- View this message in context: http://koha.1045719.n5.nabble.com/Zebra-Plack-Timeout-Issue-tp5905919p590592... Sent from the Koha-general mailing list archive at Nabble.com. _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
On 5 October 2016 at 08:59, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
For the timeout, you can also try to switch off SessionRestrictionByIP.
When I was having this problem it was unaffected by SessionRestrictionByIP, but I was able to fix it by setting SessionStorage = MySQL. Best regards, Magnus
participants (6)
-
Chris Cormack -
Chris Cormack -
Jonathan Druart -
Magnus Enger -
Michael Kuhn -
rfblanchard