Archive/Tar.php issues on the alpine demos in Administration->Backup

[bradymiller]

[25-Apr-2018 22:38:29 UTC] PHP Warning:  include_once(Archive/Tar.php): failed to open stream: No such file or directory in /var/www/localhost/htdocs/b/openemr/interface/main/backup.php on line 51
[25-Apr-2018 22:38:29 UTC] PHP Warning:  include_once(): Failed opening 'Archive/Tar.php' for inclusion (include_path='.:') in /var/www/localhost/htdocs/b/openemr/interface/main/backup.php on line 51

This does not break anything since OpenEMR has another backup mechanism when Archive/Tar.php does not exist.

have tried the following without success in the dockerbuild:
brought in php7-pear then followed by
pear install Archive_Tar
(it looks like it installs correctly, but the PHP warning still shows up)

low priority since backup still works and I plan to work on this.

[TheToolbox]

Hmm perhaps it's a permissions issue. I'll check shortly to see if that's the case.

[TheToolbox]

Odd. I wasn't able to replicate with :latest (successfully generated a tarfile). Is there anything else I should be doing to replicate?

[sjpadgett]

On linux, chance of catching the Archive/Tar fail is dependent on how error levels are set. Moreover, bumping the max memory size in php.ini will allow backup to work until a tar of greater size is downloaded i.e with memory_limit = 512M and tar is 550M will fail with out of memory. This most likely is due to output buffering being turn on. So I'm thinking a revisit to backup.php is in order namely to ensure output buffer is flushed and turned off before header is sent or convert to a stream.

[bradymiller]

Something interesting to note on the demo farm. The Ubuntu dockers have memory limit of 128 and do fine on the backup while Alpine dockers needed to be bumped to 256. I am thinking this is probably because the Ubuntu is using Archive/Tar, while Alpine is using the alternative backup method (when Archive/Tar does not exist).

[sjpadgett]

Also I believe swap memory may be turned off for Alpine

[TheToolbox]

(sorry, didn't get notifications for this issue) I could definitely be wrong, but this sounds like a bug in openemr/openemr. I feel like memory use increasing as db size increases ends up being unsustainable, and it would be better to stream to the file in chunks rather than (presumably) all at once. Again, definitely could be wrong, but maybe this is an issue to move over there?

[sjpadgett]

See my comment above. If y'all want to move issue to OpenEMR i'll try to fix but just can't now.

[jesdynf]

Could https://github.com/ifsnop/mysqldump-php be relevant to this issue? Odds are it's making more sensible decisions about memory management than our tool is.

[sjpadgett]

Agreed but one issue seems to not be creating the tar but instead app will load entire tar into memory for download thus we need to stream the tar or turn off the output buffer before sending the header then PHP should manage the memory. For some reason if output buffering is on, PHP wants to load entire tar into memory.

[bradymiller]

hi @sjpadgett ,
Is setting output buffering to off a feasible fix for this? If so, would be awesome, since starting to get reports of this bug on forum.
-brady

[sjpadgett]

I'll test it today.

…

On Fri, May 18, 2018 at 2:55 AM, Brady Miller ***@***.***> wrote: hi @sjpadgett <https://github.com/sjpadgett> , Is setting output buffering to off a feasible fix for this? If so, would be awesome, since starting to get reports of this bug on forum. -brady — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#128 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABxhkXtERV-1owrEZc99qJ1W1EF0zn-Hks5tznBGgaJpZM4TkiqB> .

-- Jerry Padgett Padgett's Consulting Brandon, Florida 33511 sjpadgett@gmail.com <sjpadgett@gmailo.com>

[sjpadgett]

openemr/openemr#1643
Works for me.

[bradymiller]

thanks @sjpadgett !