Got it, thanks @p44 and @jdaviescoates.
Best posts made by cbeams
-
Provide UI support for choosing app/package version during installation
This is a follow-up to the conversation at https://forum.cloudron.io/topic/2688/disaster-recovery-restoring-a-backup/2?_=1611914904153.
Currently, the only way to install a version of an app other than the current/latest version is to manually manipulate the
version
property in the query string during the installation process. This is basically an undocumented feature, and even when one knows about it, one doesn't have any simple way of knowing which versions are available.Ideally, the app installation dialog would present the user with a dropdown of available app versions, defaulting to the latest/current version. This is an important use case when recovering from a backup of an app older than the latest version. The user is instructed to make sure that the new app and the app being recovered have the same version, but there is no way to actually do that unless the user knows about this semi-hidden feature.
-
RE: Disaster recovery - Restoring a backup
@girish wrote:
Are you able to open a request [for this]?
Done, thanks: https://forum.cloudron.io/topic/4306/provide-ui-support-for-choosing-app-package-version-during-installation
-
RE: Remark
I'm also a bit frustrated with Commento, primarily due to the fact that migrating between domains is unsupported / undocumented, and in researching that, I've noticed a number of people complaining about support (on the paid product). I've noticed that the existing requests about domain migrations haven't been taken seriously by the app author. I'm just getting started migrating to Commento, and I've held off because of these concerns. For example, see https://gitlab.com/commento/commento/-/issues/225.
In the search for alternatives, I too found Remark42, and I've just added an issue to their tracker asking if they'd be interested in packaging it up for inclusion in the Cloudron app store. See/watch https://github.com/umputun/remark42/issues/865 for details.
-
RE: Read first before starting to package an app
What is the process for submitting a packaged app for inclusion in the app store? I see the "app wishlist" category here in the forum, but these seem to be user requests. If an app's project team goes through the process of properly packaging their app per the instructions above, what's the best way for them to request inclusion?
I am thinking in particular about BTCPay Server, which has been requested at https://forum.cloudron.io/topic/3956/btcpayserver. I'm asking the BTCPay team now if they'd be interested in doing the work, but want to make sure they'd have a reasonable chance of getting it added if they do so.
-
Unable to allocate more memory to PHP in order to avoid "PHP Fatal error: Allowed memory size of 134217728 bytes exhausted"
I have imported several years of data from Google Analytics into my Matomo instance, and upon attempting to view a multi-year range of Visits Over Time, I am getting the following error:
Oops… there was a problem during the request. Maybe the server had a temporary issue, or maybe you requested a report with too much data. Please try again. If this error occurs repeatedly please contact your Matomo administrator for assistance.
Looking at the logs, I see out of memory errors like the following:
Feb 08 06:39:17 [Mon Feb 08 05:39:17.396474 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 16384 bytes) in /app/code/libs/Zend/Db/Statement/Pdo.php on line 233, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1 Feb 08 06:39:17 [Mon Feb 08 05:39:17.399492 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 163840 bytes) in /app/code/vendor/composer/ClassLoader.php on line 444, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1 Feb 08 06:39:17 [Mon Feb 08 05:39:17.400723 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Uncaught Error: Class 'Zend_Db_Statement_Exception' not found in /app/code/libs/Zend/Db/Statement/Pdo.php:236\nStack trace:\n#0 /app/code/libs/Zend/Db/Statement.php(300): Zend_Db_Statement_Pdo->_execute(Array)\n#1 /app/code/libs/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Statement->execute(Array)\n#2 /app/code/libs/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('INSERT INTO ses...', Array)\n#3 /app/code/core/Db/Adapter/Pdo/Mysql.php(309): Zend_Db_Adapter_Pdo_Abstract->query('INSERT INTO ses...', Array)\n#4 /app/code/core/Session/SaveHandler/DbTable.php(122): Piwik\\Db\\Adapter\\Pdo\\Mysql->query('INSERT INTO ses...', Array)\n#5 /app/code/core/Session/SaveHandler/DbTable.php(156): Piwik\\Session\\SaveHandler\\DbTable->query('INSERT INTO ses...', Array)\n#6 [internal function]: Piwik\\Session\\SaveHandler\\DbTable->write('6543b55875760dd...', 'a:17:{s:12:"not...')\n#7 {main}\n thrown in /app/code/libs/Zend/Db/Statement/Pdo.php on line 236, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1 Feb 08 06:39:17 [Mon Feb 08 05:39:17.402563 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 163840 bytes) in /app/code/vendor/composer/ClassLoader.php on line 444, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1
The operative line there is:
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 450560 bytes)
Searching for this error, I came upon this page: https://matomo.org/docs/setup-auto-archiving/#increase-php-memory-limit
Which instructs me to add the following to my
php.ini
file:memory_limit = 512M
Note that based on the error message above, "Allowed memory size of 134217728 bytes exhausted", I assume I currently have 134217728/(1024*1024) = 128M allocated, so bumping to 512M should be more than enough.
Note also that I have allocated 768M RAM to the Matomo container in Config > Resources, so there should be enough to give 512M to PHP as directed in the php.ini file.
After adding this param to the php.ini file, I restarted Matomo. Everything comes back up fine, and I am able to view pages and queries that are less resource intensive, but when I attempt to load the same multi-year Views Over Time query, I end up with the same PHP Fatal Error, indicating that 134217728 of allocated memory has been exhausted.
This suggests to me that the settings in
data/php.ini
are not in fact being respected as advertised in its comments:; Settings here are merged with the package's built-in php.ini
Any ideas what could be the problem here? Thanks.
-
RE: Unable to fork the Box project in git.cloudron.io
@nebulon Thanks, I've successfully submitted a merge request at https://git.cloudron.io/cloudron/dashboard/-/merge_requests/2.
-
RE: Restricting app access to logged-in Cloudron users
@girish thanks for the response, makes sense. By the way, it looks like you pasted a screenshot from Bookstack's settings screen, as opposed to wiki.js. So far as I can tell, Wiki.js does not have equivalent "make this instance private to logged in users" functionality.
Also note that it looks like CloudFlare's "Access" feature could be a way to lock down whole subdomains/apps to logged in Cloudron users, regardless of whether the app explicitly supports doing so. https://www.cloudflare.com/teams/access/
-
RE: Updating Commento?
FYI, I just pinged the Commento team about merging the blocking merge request: https://gitlab.com/commento/commento/-/merge_requests/88#note_495324294
-
RE: Unable to fork the Box project in git.cloudron.io
I too am unable to fork either the box or dashboard projects. The fork button is available on both repositories, but unclickable. When I attempt to directly edit a file within the dashboard project, I am taken into the fork workflow, but then see the following error when actually trying to fork the project:
When clicking "Try to fork again", I see:
It appears that as a new user, I am unable to create any projects at all, and this is why I cannot fork. Indeed, if I return to the main GitLab dashboard and try to click "Create project", it is also unclickable:
Could you see about tweaking the quotas for new users to make this possible? Note that I've just signed the CLA as well.
The changes I'm going to propose are very minor, just some typo fixes. Thanks.
Latest posts made by cbeams
-
RE: Unable to allocate more memory to PHP in order to avoid "PHP Fatal error: Allowed memory size of 134217728 bytes exhausted"
@cbeams Everything works as expected now against v1.24.0, thanks!
-
RE: Unable to allocate more memory to PHP in order to avoid "PHP Fatal error: Allowed memory size of 134217728 bytes exhausted"
@girish Will do now, and will let you know, thanks!
-
Unable to allocate more memory to PHP in order to avoid "PHP Fatal error: Allowed memory size of 134217728 bytes exhausted"
I have imported several years of data from Google Analytics into my Matomo instance, and upon attempting to view a multi-year range of Visits Over Time, I am getting the following error:
Oops… there was a problem during the request. Maybe the server had a temporary issue, or maybe you requested a report with too much data. Please try again. If this error occurs repeatedly please contact your Matomo administrator for assistance.
Looking at the logs, I see out of memory errors like the following:
Feb 08 06:39:17 [Mon Feb 08 05:39:17.396474 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 16384 bytes) in /app/code/libs/Zend/Db/Statement/Pdo.php on line 233, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1 Feb 08 06:39:17 [Mon Feb 08 05:39:17.399492 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 163840 bytes) in /app/code/vendor/composer/ClassLoader.php on line 444, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1 Feb 08 06:39:17 [Mon Feb 08 05:39:17.400723 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Uncaught Error: Class 'Zend_Db_Statement_Exception' not found in /app/code/libs/Zend/Db/Statement/Pdo.php:236\nStack trace:\n#0 /app/code/libs/Zend/Db/Statement.php(300): Zend_Db_Statement_Pdo->_execute(Array)\n#1 /app/code/libs/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Statement->execute(Array)\n#2 /app/code/libs/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('INSERT INTO ses...', Array)\n#3 /app/code/core/Db/Adapter/Pdo/Mysql.php(309): Zend_Db_Adapter_Pdo_Abstract->query('INSERT INTO ses...', Array)\n#4 /app/code/core/Session/SaveHandler/DbTable.php(122): Piwik\\Db\\Adapter\\Pdo\\Mysql->query('INSERT INTO ses...', Array)\n#5 /app/code/core/Session/SaveHandler/DbTable.php(156): Piwik\\Session\\SaveHandler\\DbTable->query('INSERT INTO ses...', Array)\n#6 [internal function]: Piwik\\Session\\SaveHandler\\DbTable->write('6543b55875760dd...', 'a:17:{s:12:"not...')\n#7 {main}\n thrown in /app/code/libs/Zend/Db/Statement/Pdo.php on line 236, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1 Feb 08 06:39:17 [Mon Feb 08 05:39:17.402563 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 163840 bytes) in /app/code/vendor/composer/ClassLoader.php on line 444, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1
The operative line there is:
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 450560 bytes)
Searching for this error, I came upon this page: https://matomo.org/docs/setup-auto-archiving/#increase-php-memory-limit
Which instructs me to add the following to my
php.ini
file:memory_limit = 512M
Note that based on the error message above, "Allowed memory size of 134217728 bytes exhausted", I assume I currently have 134217728/(1024*1024) = 128M allocated, so bumping to 512M should be more than enough.
Note also that I have allocated 768M RAM to the Matomo container in Config > Resources, so there should be enough to give 512M to PHP as directed in the php.ini file.
After adding this param to the php.ini file, I restarted Matomo. Everything comes back up fine, and I am able to view pages and queries that are less resource intensive, but when I attempt to load the same multi-year Views Over Time query, I end up with the same PHP Fatal Error, indicating that 134217728 of allocated memory has been exhausted.
This suggests to me that the settings in
data/php.ini
are not in fact being respected as advertised in its comments:; Settings here are merged with the package's built-in php.ini
Any ideas what could be the problem here? Thanks.
-
RE: Matomo login timeout
@nebulon Thanks for looking into it further. It certainly is an annoying problem!
That's interesting regarding the
session
table, especially in light of this comment from https://github.com/matomo-org/matomo/issues/15625#issuecomment-770846839Maybe session file on your server gets removed for some reason. Don't know what could be the problem.
Perhaps he is confused about this too, but I assumed he was someone knowledgeable about Matomo.
-
RE: Matomo login timeout
@nebulon sigh... I take it back. I thought I had this sorted, but I've been getting logged out again as I was before.
A quick look at the session store reveals, that no sessions are saved to
/run/matomo/session
this is odd, but maybe matomo is actually using some other storage somewhere else...have to investigateIndeed my
/run/matomo/session
dir is empty as well, but I do notice that/run/matomo/tmp/sessions
is not:root@dc23980a-557c-4199-ad52-8d1139a19467:/app/code# ls -l /run/matomo/tmp/sessions/ total 16 -rw-r--r-- 1 www-data www-data 20 Feb 1 15:42 index.htm -rw-r--r-- 1 www-data www-data 20 Feb 1 15:42 index.php -rw------- 1 www-data www-data 278 Jan 16 16:58 sess_58ac4nlca9d8na9tb4selvf1mu -rw------- 1 www-data www-data 278 Jan 16 16:58 sess_b6ah1mt6739rjka699reutrf54
Both of the session files there are rather old, though, and neither match the active session ID I see in my browser's dev tools:
Perhaps this provides a clue.
P.S.: If you notice the longer-than-usual expiry period for my cookie, it's because I set
login_cookie_expire = 315360000
in config.ini per the instructions here as part of my previous attempts to solve this problem. The config parameter does in fact extend the expiry beyond the default, but does not have any effect on getting remember me functionality to actually work. -
RE: Matomo login timeout
@nebulon Thanks. As I mentioned in a follow-up to my comment above, I've actually now gotten everything working as expected, or at least it seems that way. I think it had something to do with one of or a combination of:
- clearing my cookies for the site
- logging out of matomo
- quitting my browser process
- restarting matomo itself
At some point in the process of doing all these things, I started getting the expected remember me' / persistent login behavior.
-
RE: Matomo login timeout
I'm still seeing this behavior (remember me not working) on the latest Matomo Package v1.23.1 / App v4.1.1. I see the fix for it happened quite a while ago at https://github.com/matomo-org/matomo/issues/15625#issuecomment-592580628, so I don't understand why it's still happening. See my comment about it at https://github.com/matomo-org/matomo/issues/15625#issuecomment-770823919.
-
RE: Syncthing on iOS
I’ve gotten Möbius set up in the meantime and it’s quite promising so far. My core use case works, which is syncing a few markdown files between my Mac and iPhone, so I can edit with Vim in the Mac and iaWriter on the phone, keeping them in sync as I do. This has so far been impossible for me to set up in any usable way (without resorting to Dropbox or iCloud), so syncthing and Möbius are really looking good.
Here are a couple issues and questions I’ve run into along the way:
https://github.com/MobiusSync/MobiusSync/issues/7#issuecomment-770217846
https://github.com/MobiusSync/MobiusSync/issues/26#issuecomment-770235377
-
RE: Syncthing on iOS
Just catching up on this thread, thanks, @necrevistonnezr for the writeup. Has anyone tried the Möbius Sync iOS client? I'm not sure how new it is, perhaps it wasn't around when this thread was active. In any case, I'd be interested to hear pros and cons between these two approaches.
-
RE: Provide UI support for choosing app/package version during installation
@nebulon Agreed, making, restoring an app from scratch would make things more intuitive and even easier. I did have to read and re-read and try things out manually to really figure out what I needed to do.
I think the dropdown would be good in any case though. It could be that a user simply wants to install an older version of an app, perhaps not for recovery, but for testing e.g. to reproduce a version-specific bug.