Re: EXTERNAL: Re: [FOSSology] Quick Question

[Kline, Charles]

HmmmI had wondered if that was the case...having to store the file in 
memory...I will certainly try this...but since the memory_limit was previously 
702M and it seemed to handle files up to ~2G in size I'm not sure this will do 
it...but I am desperate!

I have updated the php.ini file to reflect updating memory_limit to 4096M.  I 
see the app is currently being used...I'll restart it and tomcat either later 
tonight or very early tomorrow morning and have them test. 

Thanks Michael!! Let me know if you, or Dan, has any other ideas. 

Charlie

-Original Message-
From: Michael C. Jaeger [mailto:m...@mcj.de] 
Sent: Wednesday, February 13, 2019 3:38 PM
To: Kline, Charles (US) 
Cc: Jaeger, Michael C. ; Stangel, Dan 
; fossol...@fossology.org; Shaver, Edward (US) 

Subject: Re: EXTERNAL: Re: [FOSSology] Quick Question

Hello,

I think your memory limit might be wrong (1024M ?) as the PHP code might need 
to store the file in memory. In general it should larger than postmaxsize / 
uploadmaxsize, so 4100 might be good value here.

Kind regards, Michael

> On 13. Feb 2019, at 21:12, Kline, Charles  wrote:
> 
> Hi Guys,
> Copying my server admin...Ed Shaver...
> 
> Grrr!!! We are still unable to upload a file >2G.  Apparently the user 
> can see it uploading and it gets to 100% (using Chrome) but then nothing...a 
> job ID never gets generated so obviously there is never anything to see for 
> the job under Show Jobs. 
> 
> We have done the following: 
> Updated /etc/php.ini as follows: 
> - post_max_size updated from 2048M to 4096M
> - upload_max_filesize updated from 2018M to 4096M
> - memory_limit updated from 702M to 1024M
> Note: on the Upload a New File screen we do see the following line right 
> about #1 where  you select the folder for storing the uploaded file..." Your 
> FOSSology server has imposed a maximum upload file size of 4096M bytes."
> 
> The RAM has been updated from 8G to 16G. 
> [crkline@averhart /etc 113]% cat /proc/meminfo
> MemTotal:   16329788 kB
> MemFree: 7762536 kB
> Buffers:  208940 kB
> Cached:  6587228 kB
> SwapCached:0 kB
> SwapTotal:   4193276 kB
> SwapFree:4193276 kB
> 
> This is from the current 'top -u fossy'. As you can see TOTAL 
> MEM=16,329,788k and the USED= 8,494,540k with FREE=7,835,248k top - 14:20:04 
> up 10:19,  2 users,  load average: 0.00, 0.07, 0.22
> Tasks: 203 total,   1 running, 202 sleeping,   0 stopped,   0 zombie
> Cpu(s):  0.1%us,  0.2%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:  16329788k total,  8494540k used,  7835248k free,   207872k buffers
> Swap:  4193276k total,0k used,  4193276k free,  6518428k cached
>  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> 2833 fossy 20   0  826m 2784 1956 S  0.0  0.0   0:00.94 fo_scheduler
> 
> Fossoloy and Tomcat have been restarted a number of times and the server has 
> been rebooted. 
> 
> What am I missing?!?!
> What would cause things just to stop after the file has uploaded...assuming 
> of course it has successfully uploaded which it would be nice to be able to 
> verify. 
> Is there any place I can look in fossology to try to see what is/isn't 
> happening? 
> 
> Any help would be appreciated. 
> Please note I will be out of office commencing today at 1600 returning Monday 
> morning at 0730. 
> 
> Thanks in advance...
> Charlie
> 
> Note: on the Upload a New File screen we do see the following line right 
> about #1 where  you select the folder for storing the uploaded file..." Your 
> FOSSology server has imposed a maximum upload file size of 4096M bytes."
> 
> 
> 
> 
> 
> 
> 
> -Original Message-
> From: Kline, Charles (US)
> Sent: Monday, February 4, 2019 4:07 PM
> To: 'Michael C. Jaeger' 
> Cc: 'Jaeger, Michael C.' ; 'Stangel, 
> Dan' ; 'fossol...@fossology.org' 
> 
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Any idea where the file is uploaded to (RAM or a specific location) from 
> which it is then unpacked? Will it unpack if it doesn't see enough RAM or 
> Storage to do the unpack? We just have no clue as to how an uploaded file is 
> processed from the perspective of where is it uploaded to...where is it 
> unpacked to before processing...etc. 
> 
> 
> charlie
> 
> -Original Message-
> From: Kline, Charles (US)
> Sent: Monday, February 4, 2019 3:23 PM
> To: 'Michael C. Jaeger' 
> Cc: 'Jaeger, Michael C.' ; 'Stangel, 
> Dan' ; 'fossol...@fossology.org' 
> 
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Hi guys...this is kil

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Kline, Charles]

Hi Guys, 
Copying my server admin...Ed Shaver...

Grrr!!! We are still unable to upload a file >2G.  Apparently the user can 
see it uploading and it gets to 100% (using Chrome) but then nothing...a job ID 
never gets generated so obviously there is never anything to see for the job 
under Show Jobs. 

We have done the following: 
Updated /etc/php.ini as follows: 
- post_max_size updated from 2048M to 4096M
- upload_max_filesize updated from 2018M to 4096M
- memory_limit updated from 702M to 1024M
Note: on the Upload a New File screen we do see the following line right about 
#1 where  you select the folder for storing the uploaded file..." Your 
FOSSology server has imposed a maximum upload file size of 4096M bytes."

The RAM has been updated from 8G to 16G. 
[crkline@averhart /etc 113]% cat /proc/meminfo
MemTotal:   16329788 kB
MemFree: 7762536 kB
Buffers:  208940 kB
Cached:  6587228 kB
SwapCached:0 kB
SwapTotal:   4193276 kB
SwapFree:4193276 kB

This is from the current 'top -u fossy'. As you can see TOTAL MEM=16,329,788k 
and the USED= 8,494,540k with FREE=7,835,248k
top - 14:20:04 up 10:19,  2 users,  load average: 0.00, 0.07, 0.22
Tasks: 203 total,   1 running, 202 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.1%us,  0.2%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  16329788k total,  8494540k used,  7835248k free,   207872k buffers
Swap:  4193276k total,0k used,  4193276k free,  6518428k cached
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 2833 fossy 20   0  826m 2784 1956 S  0.0  0.0   0:00.94 fo_scheduler

Fossoloy and Tomcat have been restarted a number of times and the server has 
been rebooted. 

What am I missing?!?!
What would cause things just to stop after the file has uploaded...assuming of 
course it has successfully uploaded which it would be nice to be able to 
verify. 
Is there any place I can look in fossology to try to see what is/isn't 
happening? 

Any help would be appreciated. 
Please note I will be out of office commencing today at 1600 returning Monday 
morning at 0730. 

Thanks in advance...
Charlie

Note: on the Upload a New File screen we do see the following line right about 
#1 where  you select the folder for storing the uploaded file..." Your 
FOSSology server has imposed a maximum upload file size of 4096M bytes."







-Original Message-
From: Kline, Charles (US) 
Sent: Monday, February 4, 2019 4:07 PM
To: 'Michael C. Jaeger' 
Cc: 'Jaeger, Michael C.' ; 'Stangel, Dan' 
; 'fossol...@fossology.org' 
Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question

Any idea where the file is uploaded to (RAM or a specific location) from which 
it is then unpacked? Will it unpack if it doesn't see enough RAM or Storage to 
do the unpack? We just have no clue as to how an uploaded file is processed 
from the perspective of where is it uploaded to...where is it unpacked to 
before processing...etc. 


charlie

-Original Message-
From: Kline, Charles (US)
Sent: Monday, February 4, 2019 3:23 PM
To: 'Michael C. Jaeger' 
Cc: 'Jaeger, Michael C.' ; 'Stangel, Dan' 
; 'fossol...@fossology.org' 
Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question

Hi guys...this is killing me!  
Another question on uploads...currently php.ini has been updated setting 
upload_max_filesize and post_max_size  to 4096M and on the Upload a New File 
screen I see " FOSSology server has imposed a maximum upload file size of 4096M 
bytes."...which is interesting because last week after making the property 
updates I still saw it indicating "2048M bytes".   I thought maybe a server 
reboot had been done while I was out...but using 'uptime' indicates the server 
has been up for 22 days.  

Anyways...the user tried uploading a 2.8G file using Chrome. When initiated she 
saw the %complete in the lower left hand corner and the spinning thing at the 
upper left hand corner which they always see.  The upload reached 100% and the 
spinning stopped but no job id was generated with the link you could click on 
despite waiting a while. We are at a loss as to what is going on...mostly from 
our general ignorance.  Not sure if at this point it is determining there isn't 
sufficient RAM to process the uploaded file (I am currently trying to get the 
RAM increased on this box from 8G to 24G) or what.  There would appear to be 
plenty of actual storage available. Any thoughts on what is going on at this 
point and why we are not processing the file that appeared to upload 
successfully? 

Charlie

-Original Message-
From: Kline, Charles (US)
Sent: Thursday, January 31, 2019 8:26 AM
To: 'Michael C. Jaeger' 
Cc: 'Jaeger, Michael C.' ; 'Stangel, Dan' 
; 'fossol...@fossology.org' 
Subject: RE: EXTERNAL: Re: 

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Michael C. Jaeger]

Hello,

I think your memory limit might be wrong (1024M ?) as the PHP code might need 
to store the file in memory. In general it should larger than postmaxsize / 
uploadmaxsize, so 4100 might be good value here.

Kind regards, Michael

> On 13. Feb 2019, at 21:12, Kline, Charles  wrote:
> 
> Hi Guys, 
> Copying my server admin...Ed Shaver...
> 
> Grrr!!! We are still unable to upload a file >2G.  Apparently the user 
> can see it uploading and it gets to 100% (using Chrome) but then nothing...a 
> job ID never gets generated so obviously there is never anything to see for 
> the job under Show Jobs. 
> 
> We have done the following: 
> Updated /etc/php.ini as follows: 
> - post_max_size updated from 2048M to 4096M
> - upload_max_filesize updated from 2018M to 4096M
> - memory_limit updated from 702M to 1024M
> Note: on the Upload a New File screen we do see the following line right 
> about #1 where  you select the folder for storing the uploaded file..." Your 
> FOSSology server has imposed a maximum upload file size of 4096M bytes."
> 
> The RAM has been updated from 8G to 16G. 
> [crkline@averhart /etc 113]% cat /proc/meminfo
> MemTotal:   16329788 kB
> MemFree: 7762536 kB
> Buffers:  208940 kB
> Cached:  6587228 kB
> SwapCached:0 kB
> SwapTotal:   4193276 kB
> SwapFree:4193276 kB
> 
> This is from the current 'top -u fossy'. As you can see TOTAL MEM=16,329,788k 
> and the USED= 8,494,540k with FREE=7,835,248k
> top - 14:20:04 up 10:19,  2 users,  load average: 0.00, 0.07, 0.22
> Tasks: 203 total,   1 running, 202 sleeping,   0 stopped,   0 zombie
> Cpu(s):  0.1%us,  0.2%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:  16329788k total,  8494540k used,  7835248k free,   207872k buffers
> Swap:  4193276k total,0k used,  4193276k free,  6518428k cached
>  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> 2833 fossy 20   0  826m 2784 1956 S  0.0  0.0   0:00.94 fo_scheduler
> 
> Fossoloy and Tomcat have been restarted a number of times and the server has 
> been rebooted. 
> 
> What am I missing?!?!
> What would cause things just to stop after the file has uploaded...assuming 
> of course it has successfully uploaded which it would be nice to be able to 
> verify. 
> Is there any place I can look in fossology to try to see what is/isn't 
> happening? 
> 
> Any help would be appreciated. 
> Please note I will be out of office commencing today at 1600 returning Monday 
> morning at 0730. 
> 
> Thanks in advance...
> Charlie
> 
> Note: on the Upload a New File screen we do see the following line right 
> about #1 where  you select the folder for storing the uploaded file..." Your 
> FOSSology server has imposed a maximum upload file size of 4096M bytes."
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-
> From: Kline, Charles (US) 
> Sent: Monday, February 4, 2019 4:07 PM
> To: 'Michael C. Jaeger' 
> Cc: 'Jaeger, Michael C.' ; 'Stangel, Dan' 
> ; 'fossol...@fossology.org' 
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Any idea where the file is uploaded to (RAM or a specific location) from 
> which it is then unpacked? Will it unpack if it doesn't see enough RAM or 
> Storage to do the unpack? We just have no clue as to how an uploaded file is 
> processed from the perspective of where is it uploaded to...where is it 
> unpacked to before processing...etc. 
> 
> 
> charlie
> 
> -Original Message-
> From: Kline, Charles (US)
> Sent: Monday, February 4, 2019 3:23 PM
> To: 'Michael C. Jaeger' 
> Cc: 'Jaeger, Michael C.' ; 'Stangel, Dan' 
> ; 'fossol...@fossology.org' 
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Hi guys...this is killing me!
> Another question on uploads...currently php.ini has been updated setting 
> upload_max_filesize and post_max_size  to 4096M and on the Upload a New File 
> screen I see " FOSSology server has imposed a maximum upload file size of 
> 4096M bytes."...which is interesting because last week after making the 
> property updates I still saw it indicating "2048M bytes".   I thought maybe a 
> server reboot had been done while I was out...but using 'uptime' indicates 
> the server has been up for 22 days.
> 
> Anyways...the user tried uploading a 2.8G file using Chrome. When initiated 
> she saw the %complete in the lower left hand corner and the spinning thing at 
> the upper left hand corner which they always see.  The upload reached 100% 
> and the spinning stopped but no job id 

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Kline, Charles]

Please see below…



-Original Message-
From: Michael C. Jaeger [mailto:m...@mcj.de]
Sent: Tuesday, February 5, 2019 12:51 PM
To: Kline, Charles (US) 
Cc: Jaeger, Michael C. ; Stangel, Dan 
; fossol...@fossology.org
Subject: Re: EXTERNAL: Re: [FOSSology] Quick Question

Hi,



so did not like the idea of segmentation.



I am also not sure what was going on. A geneal place to look at is the apache 
log



  sudo tail -n 1000 /var/log/apache2/error.log>>>>> /var/log/apache2, 
apache or tomcat do not exist.



or the fossology log



  sudo tail -n 1000 /var/log/fossology/fossology.log >>>>> we have 
/app/fossology/log/fossology  where fossology is a file.  While I do see ERROR 
messages (e.g. “xxx_pffile already exists”, FATAL messages like for the 
database for connection issues…it has been a while since there have been any 
issues…for the most part this file is showing Fossology scheduler started or 
closed messages.



maybe something is written there which gives to you some hint about what is 
going on your machine.



Another thing is that you mention only two php.ini settings changed, but also a 
third one requires changes:



  memory_limit   >>> I checked this out in the php.ini file…it is currently set 
to 128M.



please see more details here:



  
https://github.com/fossology/fossology/blob/master/install/scripts/php-conf-fix.sh
   >>> I checked this out…I recall seeing this in my wanderings through the 
fossology sites, per this site I see the following that I assume possibly 
default OOTB settings maybe???
if [ -e $phpIni ]


then


echo 'Copies php.ini to current directory and creates a backup file'


echo 'Modifies it and then displays variance for confirmation.'


cp $phpIni php.ini.orig


cp php.ini.orig php.ini


echo 'If happy with changes you should save original and move new one back.'


echo 'Setting max execution time to 300 seconds (5 mins)'


sed -i 's/^\(max_execution_time\s*=\s*\).*$/\1300/' php.ini


echo 'Setting memory limit to 702M'


sed -i 's/^\(memory_limit\s*=\s*\).*$/\1702M/' php.ini


echo 'Setting post max size to 701M'


sed -i 's/^\(post_max_size\s*=\s*\).*$/\1701M/' php.ini


echo 'Setting max upload filesize to 700M'


sed -i 's/^\(upload_max_filesize\s*=\s*\).*$/\1700M/' php.ini


echo "Setting timezone to $TIMEZONE"


sed -i "s%.*date.timezone =.*%date.timezone = $TIMEZONE%" php.ini


echo 'php.ini adjusted!'


echo


echo 'Display the changes made'


diff php.ini.orig php.ini


echo $1




If I look at our /etc/php.ini I see the following:

Max_execution_time: 300>>> do you see a need for increasing this value. I 
understand one needs to be careful with this setting in particular on 
production servers so you don’t have unexpectedly long running scripts that 
could potentially impact other jobs/users.

Memory_limit: 702M>>>>>>>>>>>>> Do you have a suggestion as to what this 
should be increased to Should it be the same as post_max_size???

Post_max_size: 4096M (we had manually updated the php.ini file to increase this 
from 2048M)

Upload_max_filesize: 4096M (we had manually updated the php.ini file to 
increase this from 2048M)





Kind regards, Michael



> On 4. Feb 2019, at 21:22, Kline, Charles 
> mailto:charles.kl...@lmco.com>> wrote:

>

> Hi guys...this is killing me!

> Another question on uploads...currently php.ini has been updated setting 
> upload_max_filesize and post_max_size  to 4096M and on the Upload a New File 
> screen I see " FOSSology server has imposed a maximum upload file size of 
> 4096M bytes."...which is interesting because last week after making the 
> property updates I still saw it indicating "2048M bytes".   I thought maybe a 
> server reboot had been done while I was out...but using 'uptime' indicates 
> the server has been up for 22 days.

>

> Anyways...the user tried uploading a 2.8G file using Chrome. When initiated 
> she saw the %complete in the lower left hand corner and the spinning thing at 
> the upper left hand corner which they always see.  The upload reached 100% 
> and the spinning stopped but no job id was generated with the link you could 
> click on despite waiting a while. We are at a loss as to what is going 
> on...mostly from our general ignorance.  Not sure if at this point it is 
> determining there isn't sufficient RAM to process the uploaded file (I am 
> currently trying to get the RAM increased on this box from 8G to 24G) or 
> what.  There would appear to be plenty of actual storage available. Any 
> thoughts on what is going on at this point and why we are not processing the 
> file that appeared to upload succes

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Kline, Charles]

Please see below.



-Original Message-
From: Michael C. Jaeger [mailto:m...@mcj.de]
Sent: Tuesday, February 5, 2019 12:47 PM
To: Kline, Charles (US) 
Cc: Jaeger, Michael C. ; Stangel, Dan 
; fossol...@fossology.org
Subject: Re: EXTERNAL: Re: [FOSSology] Quick Question



Hello,



the default location "from which it is then unpacked" is:



  /srv/fossology/repository/localhost/gold/ 
/app/fossology/srv/fossology/repository/localhost/gold



check



   /etc/fossology

Yeah had looked at this previously…

[fossy@averhart /etc/fossology 119]% ls -ltr

total 32

-rw-rw-rw- 1 fossy fossy  122 Apr  8  2014 sampleheader.txt

-rw-rw-rw- 1 fossy fossy   11 Apr  8  2014 samplefooter.txt

-rw-rw-rw- 1 fossy fossy 2445 Apr  8  2014 fossology.conf.20141118

-rw-rw-rw- 1 fossy fossy   70 Apr  8  2014 VERSION

-rw-r- 1 fossy fossy   62 Apr  8  2014 Db.conf, just dbname, host, user and 
password

drwxr-xr-x 2 fossy fossy 4096 Nov 14  2014 conf/, has fo-apache.conf file, 
AllowOverride None, Options FollowSymLinks MultiView, Order allow deny, Allow 
from all

-rw-rw-rw- 1 fossy fossy 2512 Nov 18  2014 fossology.conf  <<<<< I don’t see 
any settings here

drwxrwxr-x 2 fossy fossy 4096 Nov 19  2014 mods-enabled/, has the following…

drwxr-xr-x 3 fossy fossy 4096 Nov 14  2014 lib/

drwxr-xr-x 4 fossy fossy 4096 Nov 14  2014 maintagent/

drwxr-xr-x 4 fossy fossy 4096 Nov 14  2014 copyright/

drwxr-xr-x 4 fossy fossy 4096 Nov 14  2014 delagent/

drwxr-xr-x 4 fossy fossy 4096 Nov 14  2014 nomos/

drwxr-xr-x 3 fossy fossy 4096 Nov 14  2014 scheduler/

drwxr-xr-x 4 fossy fossy 4096 Nov 14  2014 pkgagent/

drwxr-xr-x 4 fossy fossy 4096 Nov 14  2014 buckets/

drwxr-xr-x 4 fossy fossy 4096 Nov 14  2014 mimetype/

drwxr-xr-x 4 fossy fossy 4096 Nov 14  2014 adj2nest/

drwxr-xr-x 4 fossy fossy 4096 Nov 14  2014 ununpack/

drwxr-xr-x 4 fossy fossy 4096 Nov 14  2014 wget_agent/

drwxr-xr-x 3 fossy fossy 4096 Nov 19  2014 www/



for settings.



Kind regards, Michael



> On 4. Feb 2019, at 22:06, Kline, Charles 
> mailto:charles.kl...@lmco.com>> wrote:

>

> Any idea where the file is uploaded to (RAM or a specific location) from 
> which it is then unpacked? Will it unpack if it doesn't see enough RAM or 
> Storage to do the unpack? We just have no clue as to how an uploaded file is 
> processed from the perspective of where is it uploaded to...where is it 
> unpacked to before processing...etc.

>

>

> charlie

>

> -Original Message-

> From: Kline, Charles (US)

> Sent: Monday, February 4, 2019 3:23 PM

> To: 'Michael C. Jaeger' mailto:m...@mcj.de>>

> Cc: 'Jaeger, Michael C.' 
> mailto:michael.c.jae...@siemens.com>>; 'Stangel,

> Dan' mailto:dan.stan...@hpe.com>>; 
> 'fossol...@fossology.org'

> mailto:fossol...@fossology.org>>

> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question

>

> Hi guys...this is killing me!

> Another question on uploads...currently php.ini has been updated setting 
> upload_max_filesize and post_max_size  to 4096M and on the Upload a New File 
> screen I see " FOSSology server has imposed a maximum upload file size of 
> 4096M bytes."...which is interesting because last week after making the 
> property updates I still saw it indicating "2048M bytes".   I thought maybe a 
> server reboot had been done while I was out...but using 'uptime' indicates 
> the server has been up for 22 days.

>

> Anyways...the user tried uploading a 2.8G file using Chrome. When initiated 
> she saw the %complete in the lower left hand corner and the spinning thing at 
> the upper left hand corner which they always see.  The upload reached 100% 
> and the spinning stopped but no job id was generated with the link you could 
> click on despite waiting a while. We are at a loss as to what is going 
> on...mostly from our general ignorance.  Not sure if at this point it is 
> determining there isn't sufficient RAM to process the uploaded file (I am 
> currently trying to get the RAM increased on this box from 8G to 24G) or 
> what.  There would appear to be plenty of actual storage available. Any 
> thoughts on what is going on at this point and why we are not processing the 
> file that appeared to upload successfully?

>

> Charlie

>

> -Original Message-

> From: Kline, Charles (US)

> Sent: Thursday, January 31, 2019 8:26 AM

> To: 'Michael C. Jaeger' mailto:m...@mcj.de>>

> Cc: 'Jaeger, Michael C.' 
> mailto:michael.c.jae...@siemens.com>>; 'Stangel,

> Dan' mailto:dan.stan...@hpe.com>>; 
> 'fossol...@fossology.org'

> mailto:fossol...@fossology.org>>

> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question

>

> Tried

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Kline, Charles]

Sorry Michael,
I have been changing the format to HTML so I can use all the pretty colors, 
etc. ☺ That may be contributing to your issues….

I’ll address your items directly here…hopefully this will work better. My 
numbers will reference the order of your bullets…

1.   Hmmm, I checked out the info from the link you had below…Under 
Resource Limits I see memory_limit listed…Default 128M, Changeable PHP_INI_ALL, 
Changelog “8M” before PHP 5.2.0, “16” in PHP 5.2.0….so not quite sure what to 
do here…was thinking of maybe increasing the value of this in the /etc/php.ini 
from 702M to 1024M. But that’s just pulling out of it out of my butt.

2.   For stopping Apache I run the following…. Sudo 
/etc/init.dl/tomcat.init   … under /etc there is a httpd directory 
that has a conf.d subdir but I am unable to get to it with my current sudo 
authorization.

3.   I believe the way the startup is SUPPOSED to take place and pretty 
what has been happening is that the DB starts first before the fossology 
scheduler. So I think we are OK from that perspective.

4.   Sorry on the fossology.conf…I looked at the link you provided…our 
fossology.conf looks very similar…I guess what I meant was there were no 
settings similar to the upload max size etc….but yeah there are settings for 
all the other variables.

As I may have mentioned…I am trying to get the RAM on this server increased 
from 8G to 16G…The guy I have to work with just returned from vacation so I am 
working that angle. When we get it I plan on increasing the properties I 
recently changed from 2048M to 4096M to at least 8196M if not 16,392….I don’t 
plan on leaving a very high memory setting as that could potentially cause 
other problems.  Once we have that we will be doing additional testing even 
with smaller files…like ~4G.  Do you have any feedback on whether or not you 
believe this might help our current situation…That being so far even with the 
those 2 properties set to 4096M it looks like the file is successfully loading 
but we never generate a job number so it never shows up in the Jobs tab. Like 
it uploads then says it can’t process it…hmmm, maybe this is associated with 
the memory_limit.

I’m trying to get support shifted another admin as I will be retiring early 4th 
quarter…not having much luck so far…figured with all of this activity this 
would be a good time to bring in someone else.

charlie

From: Jaeger, Michael C. [mailto:michael.c.jae...@siemens.com]
Sent: Wednesday, February 6, 2019 10:22 AM
To: Kline, Charles (US) ; Michael C. Jaeger 

Cc: Stangel, Dan ; fossol...@fossology.org
Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question

Hello Charles,

  frankly, it is maybe because I am using a dumb e-mail client. But response it 
really hard to follow for me. A few notes:


· memory_limit in php.ini. Yes, I would increase this value accordingly 
for your case (larger than post max size / request size) as it is also 
explained here: https://secure.php.net/manual/en/ini.core.php

· If you do not have a /var/log/apache2 it is likely because the Apache 
Web server is located under a different name (I remember faintly ‘httpd’ on 
some rpm-based system. Unfortunately it is up to you to find out where your OS 
installs the Web server folders for log files.

· From what you summarizes the log it seems like the database server is 
not up when fossology is started (but maybe, due to the startup process or 
startup order on your system, later). So while I am not sure why it happens, I 
think you could restart fossology (sudo service fossology stop and then … 
start, or how this is configured for your system)

· /etc/fossology/fossology.conf should look similar to 
https://github.com/fossology/fossology/blob/master/install/defconf/fossology.conf.in
-> is the file on your file system really empty? Because from your listing is 
shows it has 2512 bytes.

Kind regards, Michael




From: Kline, Charles [mailto:charles.kl...@lmco.com]
Sent: Mittwoch, 6. Februar 2019 15:17
To: Michael C. Jaeger
Cc: Jaeger, Michael C. (CT RDA SSI); Stangel, Dan; 
fossol...@fossology.org<mailto:fossol...@fossology.org>
Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question


Please see below…



-Original Message-
From: Michael C. Jaeger [mailto:m...@mcj.de]
Sent: Tuesday, February 5, 2019 12:51 PM
To: Kline, Charles (US) mailto:charles.kl...@lmco.com>>
Cc: Jaeger, Michael C. 
mailto:michael.c.jae...@siemens.com>>; Stangel, 
Dan mailto:dan.stan...@hpe.com>>; 
fossol...@fossology.org<mailto:fossol...@fossology.org>
Subject: Re: EXTERNAL: Re: [FOSSology] Quick Question

Hi,



so did not like the idea of segmentation.



I am also not sure what was going on. A geneal place to look at is the apache 
log



  sudo tail -n 1000 /var/log/apache2/error.log>>>>> /var/log/apache2, 
apache or tomcat do not exist.



or the fossology log



  sudo tail -n 1000 /var/log

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Kline, Charles]

Hi Michael, Thanks for the info. I was out yesterday. I will review your 
emails...
charlie

-Original Message-
From: Michael C. Jaeger [mailto:m...@mcj.de] 
Sent: Tuesday, February 5, 2019 12:51 PM
To: Kline, Charles (US) 
Cc: Jaeger, Michael C. ; Stangel, Dan 
; fossol...@fossology.org
Subject: Re: EXTERNAL: Re: [FOSSology] Quick Question

Hi,

so did not like the idea of segmentation.

I am also not sure what was going on. A geneal place to look at is the apache 
log

  sudo tail -n 1000 /var/log/apache2/error.log 

or the fossology log

  sudo tail -n 1000 /var/log/fossology/fossology.log

maybe something is written there which gives to you some hint about what is 
going on your machine.

Another thing is that you mention only two php.ini settings changed, but also a 
third one requires changes:

  memory_limit

please see more details here:

  
https://github.com/fossology/fossology/blob/master/install/scripts/php-conf-fix.sh

Kind regards, Michael


> On 4. Feb 2019, at 21:22, Kline, Charles  wrote:
> 
> Hi guys...this is killing me!  
> Another question on uploads...currently php.ini has been updated setting 
> upload_max_filesize and post_max_size  to 4096M and on the Upload a New File 
> screen I see " FOSSology server has imposed a maximum upload file size of 
> 4096M bytes."...which is interesting because last week after making the 
> property updates I still saw it indicating "2048M bytes".   I thought maybe a 
> server reboot had been done while I was out...but using 'uptime' indicates 
> the server has been up for 22 days.  
> 
> Anyways...the user tried uploading a 2.8G file using Chrome. When initiated 
> she saw the %complete in the lower left hand corner and the spinning thing at 
> the upper left hand corner which they always see.  The upload reached 100% 
> and the spinning stopped but no job id was generated with the link you could 
> click on despite waiting a while. We are at a loss as to what is going 
> on...mostly from our general ignorance.  Not sure if at this point it is 
> determining there isn't sufficient RAM to process the uploaded file (I am 
> currently trying to get the RAM increased on this box from 8G to 24G) or 
> what.  There would appear to be plenty of actual storage available. Any 
> thoughts on what is going on at this point and why we are not processing the 
> file that appeared to upload successfully? 
> 
> Charlie
> 
> -Original Message-
> From: Kline, Charles (US)
> Sent: Thursday, January 31, 2019 8:26 AM
> To: 'Michael C. Jaeger' 
> Cc: 'Jaeger, Michael C.' ; 'Stangel, 
> Dan' ; 'fossol...@fossology.org' 
> 
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Tried an upload using Chrome...I like that! Thanks...I have passed this on so 
> someone can test a large file using Chrome. 
> 
> Hey, any thoughts on this...this was posed by one of our administrators..." 
> The location where the file is uploaded to, does that have enough space to 
> read the file. I don’t know if fossoloy uploads to a local area first and 
> then puts the file in the define location so I can’t say where this location 
> would be."
> 
> While trying to test last night with >2G files I was running 'top -u 
> fossy'...as usual the only running was fo_scheduler...but this also show MEM 
> and SWAPthe Available memory showed 8G...the used showed 7.xG with ~500M 
> freeI never saw the free space fall much below this and I often see these 
> numbers. Later when testing a very very small file I did see the Used in the 
> 5G range. 
> 
> Charlie
> 
> -Original Message-
> From: Kline, Charles (US)
> Sent: Thursday, January 31, 2019 8:14 AM
> To: 'Michael C. Jaeger' 
> Cc: Jaeger, Michael C. ; Stangel, Dan 
> ; fossol...@fossology.org
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Hi Michael,
> Yeah, big thing is we are trying to ascertain whether or not the file is 
> actually uploaded...certainly the test file I can see uploaded as a job 
> number was assigned and the ununpack started. I'll check out Chrome. 
> 
> charlie
> 
> -Original Message-
> From: Michael C. Jaeger [mailto:m...@mcj.de]
> Sent: Thursday, January 31, 2019 7:10 AM
> To: Kline, Charles (US) 
> Cc: Jaeger, Michael C. ; Stangel, Dan 
> ; fossol...@fossology.org
> Subject: Re: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Hello,
> 
> looks good. it appears also to me that a part of your waiting time appears to 
> be the upload / transfer time. Not all browsers show the upload progress, 
> Chrome does in the lower left corner. On some OSes you can see the network 
> traffic. I think this is maybe also another effect 

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Michael C. Jaeger]

Hi,

so did not like the idea of segmentation.

I am also not sure what was going on. A geneal place to look at is the apache 
log

  sudo tail -n 1000 /var/log/apache2/error.log 

or the fossology log

  sudo tail -n 1000 /var/log/fossology/fossology.log

maybe something is written there which gives to you some hint about what is 
going on your machine.

Another thing is that you mention only two php.ini settings changed, but also a 
third one requires changes:

  memory_limit

please see more details here:

  
https://github.com/fossology/fossology/blob/master/install/scripts/php-conf-fix.sh

Kind regards, Michael


> On 4. Feb 2019, at 21:22, Kline, Charles  wrote:
> 
> Hi guys...this is killing me!
> Another question on uploads...currently php.ini has been updated setting 
> upload_max_filesize and post_max_size  to 4096M and on the Upload a New File 
> screen I see " FOSSology server has imposed a maximum upload file size of 
> 4096M bytes."...which is interesting because last week after making the 
> property updates I still saw it indicating "2048M bytes".   I thought maybe a 
> server reboot had been done while I was out...but using 'uptime' indicates 
> the server has been up for 22 days.
> 
> Anyways...the user tried uploading a 2.8G file using Chrome. When initiated 
> she saw the %complete in the lower left hand corner and the spinning thing at 
> the upper left hand corner which they always see.  The upload reached 100% 
> and the spinning stopped but no job id was generated with the link you could 
> click on despite waiting a while. We are at a loss as to what is going 
> on...mostly from our general ignorance.  Not sure if at this point it is 
> determining there isn't sufficient RAM to process the uploaded file (I am 
> currently trying to get the RAM increased on this box from 8G to 24G) or 
> what.  There would appear to be plenty of actual storage available. Any 
> thoughts on what is going on at this point and why we are not processing the 
> file that appeared to upload successfully? 
> 
> Charlie
> 
> -Original Message-
> From: Kline, Charles (US) 
> Sent: Thursday, January 31, 2019 8:26 AM
> To: 'Michael C. Jaeger' 
> Cc: 'Jaeger, Michael C.' ; 'Stangel, Dan' 
> ; 'fossol...@fossology.org' 
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Tried an upload using Chrome...I like that! Thanks...I have passed this on so 
> someone can test a large file using Chrome. 
> 
> Hey, any thoughts on this...this was posed by one of our administrators..." 
> The location where the file is uploaded to, does that have enough space to 
> read the file. I don’t know if fossoloy uploads to a local area first and 
> then puts the file in the define location so I can’t say where this location 
> would be."
> 
> While trying to test last night with >2G files I was running 'top -u 
> fossy'...as usual the only running was fo_scheduler...but this also show MEM 
> and SWAPthe Available memory showed 8G...the used showed 7.xG with ~500M 
> freeI never saw the free space fall much below this and I often see these 
> numbers. Later when testing a very very small file I did see the Used in the 
> 5G range. 
> 
> Charlie
> 
> -Original Message-
> From: Kline, Charles (US)
> Sent: Thursday, January 31, 2019 8:14 AM
> To: 'Michael C. Jaeger' 
> Cc: Jaeger, Michael C. ; Stangel, Dan 
> ; fossol...@fossology.org
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Hi Michael,
> Yeah, big thing is we are trying to ascertain whether or not the file is 
> actually uploaded...certainly the test file I can see uploaded as a job 
> number was assigned and the ununpack started. I'll check out Chrome. 
> 
> charlie
> 
> -Original Message-
> From: Michael C. Jaeger [mailto:m...@mcj.de]
> Sent: Thursday, January 31, 2019 7:10 AM
> To: Kline, Charles (US) 
> Cc: Jaeger, Michael C. ; Stangel, Dan 
> ; fossol...@fossology.org
> Subject: Re: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Hello,
> 
> looks good. it appears also to me that a part of your waiting time appears to 
> be the upload / transfer time. Not all browsers show the upload progress, 
> Chrome does in the lower left corner. On some OSes you can see the network 
> traffic. I think this is maybe also another effect when dealing with VLP- 
> "very large packages" Maybe FOSSology could improve on this by having an 
> upload status dialogue to inform the user more precisely.
> 
> I think the last two screenshots show the progress info after the file has 
> been uploaded to the FOSSology server.
> 
> Kind regards, Michael
> 
>> On 31. 

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Michael C. Jaeger]

Hello,

the default location "from which it is then unpacked" is:

  /srv/fossology/repository/localhost/gold/

check

   /etc/fossology

for settings.

Kind regards, Michael

> On 4. Feb 2019, at 22:06, Kline, Charles  wrote:
> 
> Any idea where the file is uploaded to (RAM or a specific location) from 
> which it is then unpacked? Will it unpack if it doesn't see enough RAM or 
> Storage to do the unpack? We just have no clue as to how an uploaded file is 
> processed from the perspective of where is it uploaded to...where is it 
> unpacked to before processing...etc. 
> 
> 
> charlie
> 
> -Original Message-
> From: Kline, Charles (US) 
> Sent: Monday, February 4, 2019 3:23 PM
> To: 'Michael C. Jaeger' 
> Cc: 'Jaeger, Michael C.' ; 'Stangel, Dan' 
> ; 'fossol...@fossology.org' 
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Hi guys...this is killing me!
> Another question on uploads...currently php.ini has been updated setting 
> upload_max_filesize and post_max_size  to 4096M and on the Upload a New File 
> screen I see " FOSSology server has imposed a maximum upload file size of 
> 4096M bytes."...which is interesting because last week after making the 
> property updates I still saw it indicating "2048M bytes".   I thought maybe a 
> server reboot had been done while I was out...but using 'uptime' indicates 
> the server has been up for 22 days.
> 
> Anyways...the user tried uploading a 2.8G file using Chrome. When initiated 
> she saw the %complete in the lower left hand corner and the spinning thing at 
> the upper left hand corner which they always see.  The upload reached 100% 
> and the spinning stopped but no job id was generated with the link you could 
> click on despite waiting a while. We are at a loss as to what is going 
> on...mostly from our general ignorance.  Not sure if at this point it is 
> determining there isn't sufficient RAM to process the uploaded file (I am 
> currently trying to get the RAM increased on this box from 8G to 24G) or 
> what.  There would appear to be plenty of actual storage available. Any 
> thoughts on what is going on at this point and why we are not processing the 
> file that appeared to upload successfully? 
> 
> Charlie
> 
> -Original Message-----
> From: Kline, Charles (US)
> Sent: Thursday, January 31, 2019 8:26 AM
> To: 'Michael C. Jaeger' 
> Cc: 'Jaeger, Michael C.' ; 'Stangel, Dan' 
> ; 'fossol...@fossology.org' 
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Tried an upload using Chrome...I like that! Thanks...I have passed this on so 
> someone can test a large file using Chrome. 
> 
> Hey, any thoughts on this...this was posed by one of our administrators..." 
> The location where the file is uploaded to, does that have enough space to 
> read the file. I don’t know if fossoloy uploads to a local area first and 
> then puts the file in the define location so I can’t say where this location 
> would be."
> 
> While trying to test last night with >2G files I was running 'top -u 
> fossy'...as usual the only running was fo_scheduler...but this also show MEM 
> and SWAPthe Available memory showed 8G...the used showed 7.xG with ~500M 
> freeI never saw the free space fall much below this and I often see these 
> numbers. Later when testing a very very small file I did see the Used in the 
> 5G range. 
> 
> Charlie
> 
> -Original Message-
> From: Kline, Charles (US)
> Sent: Thursday, January 31, 2019 8:14 AM
> To: 'Michael C. Jaeger' 
> Cc: Jaeger, Michael C. ; Stangel, Dan 
> ; fossol...@fossology.org
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Hi Michael,
> Yeah, big thing is we are trying to ascertain whether or not the file is 
> actually uploaded...certainly the test file I can see uploaded as a job 
> number was assigned and the ununpack started. I'll check out Chrome. 
> 
> charlie
> 
> -Original Message-
> From: Michael C. Jaeger [mailto:m...@mcj.de]
> Sent: Thursday, January 31, 2019 7:10 AM
> To: Kline, Charles (US) 
> Cc: Jaeger, Michael C. ; Stangel, Dan 
> ; fossol...@fossology.org
> Subject: Re: EXTERNAL: Re: [FOSSology] Quick Question
> 
> Hello,
> 
> looks good. it appears also to me that a part of your waiting time appears to 
> be the upload / transfer time. Not all browsers show the upload progress, 
> Chrome does in the lower left corner. On some OSes you can see the network 
> traffic. I think this is maybe also another effect when dealing with VLP- 
> "very large packages" Maybe FOSSology c

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Kline, Charles]

Any idea where the file is uploaded to (RAM or a specific location) from which 
it is then unpacked? Will it unpack if it doesn't see enough RAM or Storage to 
do the unpack? We just have no clue as to how an uploaded file is processed 
from the perspective of where is it uploaded to...where is it unpacked to 
before processing...etc. 


charlie

-Original Message-
From: Kline, Charles (US) 
Sent: Monday, February 4, 2019 3:23 PM
To: 'Michael C. Jaeger' 
Cc: 'Jaeger, Michael C.' ; 'Stangel, Dan' 
; 'fossol...@fossology.org' 
Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question

Hi guys...this is killing me!  
Another question on uploads...currently php.ini has been updated setting 
upload_max_filesize and post_max_size  to 4096M and on the Upload a New File 
screen I see " FOSSology server has imposed a maximum upload file size of 4096M 
bytes."...which is interesting because last week after making the property 
updates I still saw it indicating "2048M bytes".   I thought maybe a server 
reboot had been done while I was out...but using 'uptime' indicates the server 
has been up for 22 days.  

Anyways...the user tried uploading a 2.8G file using Chrome. When initiated she 
saw the %complete in the lower left hand corner and the spinning thing at the 
upper left hand corner which they always see.  The upload reached 100% and the 
spinning stopped but no job id was generated with the link you could click on 
despite waiting a while. We are at a loss as to what is going on...mostly from 
our general ignorance.  Not sure if at this point it is determining there isn't 
sufficient RAM to process the uploaded file (I am currently trying to get the 
RAM increased on this box from 8G to 24G) or what.  There would appear to be 
plenty of actual storage available. Any thoughts on what is going on at this 
point and why we are not processing the file that appeared to upload 
successfully? 

Charlie

-Original Message-
From: Kline, Charles (US)
Sent: Thursday, January 31, 2019 8:26 AM
To: 'Michael C. Jaeger' 
Cc: 'Jaeger, Michael C.' ; 'Stangel, Dan' 
; 'fossol...@fossology.org' 
Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question

Tried an upload using Chrome...I like that! Thanks...I have passed this on so 
someone can test a large file using Chrome. 

Hey, any thoughts on this...this was posed by one of our administrators..." The 
location where the file is uploaded to, does that have enough space to read the 
file. I don’t know if fossoloy uploads to a local area first and then puts the 
file in the define location so I can’t say where this location would be."

While trying to test last night with >2G files I was running 'top -u 
fossy'...as usual the only running was fo_scheduler...but this also show MEM 
and SWAPthe Available memory showed 8G...the used showed 7.xG with ~500M 
freeI never saw the free space fall much below this and I often see these 
numbers. Later when testing a very very small file I did see the Used in the 5G 
range. 

Charlie

-Original Message-
From: Kline, Charles (US)
Sent: Thursday, January 31, 2019 8:14 AM
To: 'Michael C. Jaeger' 
Cc: Jaeger, Michael C. ; Stangel, Dan 
; fossol...@fossology.org
Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question

Hi Michael,
Yeah, big thing is we are trying to ascertain whether or not the file is 
actually uploaded...certainly the test file I can see uploaded as a job number 
was assigned and the ununpack started. I'll check out Chrome. 

charlie

-Original Message-
From: Michael C. Jaeger [mailto:m...@mcj.de]
Sent: Thursday, January 31, 2019 7:10 AM
To: Kline, Charles (US) 
Cc: Jaeger, Michael C. ; Stangel, Dan 
; fossol...@fossology.org
Subject: Re: EXTERNAL: Re: [FOSSology] Quick Question

Hello,

looks good. it appears also to me that a part of your waiting time appears to 
be the upload / transfer time. Not all browsers show the upload progress, 
Chrome does in the lower left corner. On some OSes you can see the network 
traffic. I think this is maybe also another effect when dealing with VLP- "very 
large packages" Maybe FOSSology could improve on this by having an upload 
status dialogue to inform the user more precisely.

I think the last two screenshots show the progress info after the file has been 
uploaded to the FOSSology server.

Kind regards, Michael

> On 31. Jan 2019, at 09:53, Kline, Charles  wrote:
> 
> Hmmm, not sure I’m following you Michael….here’s some screenshots from 
> a test I did…  CLICK UPLOAD… 
>  Then I will see this…but this is after 
> the  uploaded has been completed and the ununpack has started as shown 
> below…   I 
> guess I was hoping there was a file or log on the fossology server that one 
> could tail to see the progress or at least repeatedly do a listing to see the 
> file

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Kline, Charles]

Hi guys...this is killing me!  
Another question on uploads...currently php.ini has been updated setting 
upload_max_filesize and post_max_size  to 4096M and on the Upload a New File 
screen I see " FOSSology server has imposed a maximum upload file size of 4096M 
bytes."...which is interesting because last week after making the property 
updates I still saw it indicating "2048M bytes".   I thought maybe a server 
reboot had been done while I was out...but using 'uptime' indicates the server 
has been up for 22 days.  

Anyways...the user tried uploading a 2.8G file using Chrome. When initiated she 
saw the %complete in the lower left hand corner and the spinning thing at the 
upper left hand corner which they always see.  The upload reached 100% and the 
spinning stopped but no job id was generated with the link you could click on 
despite waiting a while. We are at a loss as to what is going on...mostly from 
our general ignorance.  Not sure if at this point it is determining there isn't 
sufficient RAM to process the uploaded file (I am currently trying to get the 
RAM increased on this box from 8G to 24G) or what.  There would appear to be 
plenty of actual storage available. Any thoughts on what is going on at this 
point and why we are not processing the file that appeared to upload 
successfully? 

Charlie

-Original Message-
From: Kline, Charles (US) 
Sent: Thursday, January 31, 2019 8:26 AM
To: 'Michael C. Jaeger' 
Cc: 'Jaeger, Michael C.' ; 'Stangel, Dan' 
; 'fossol...@fossology.org' 
Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question

Tried an upload using Chrome...I like that! Thanks...I have passed this on so 
someone can test a large file using Chrome. 

Hey, any thoughts on this...this was posed by one of our administrators..." The 
location where the file is uploaded to, does that have enough space to read the 
file. I don’t know if fossoloy uploads to a local area first and then puts the 
file in the define location so I can’t say where this location would be."

While trying to test last night with >2G files I was running 'top -u 
fossy'...as usual the only running was fo_scheduler...but this also show MEM 
and SWAPthe Available memory showed 8G...the used showed 7.xG with ~500M 
freeI never saw the free space fall much below this and I often see these 
numbers. Later when testing a very very small file I did see the Used in the 5G 
range. 

Charlie

-Original Message-
From: Kline, Charles (US)
Sent: Thursday, January 31, 2019 8:14 AM
To: 'Michael C. Jaeger' 
Cc: Jaeger, Michael C. ; Stangel, Dan 
; fossol...@fossology.org
Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question

Hi Michael,
Yeah, big thing is we are trying to ascertain whether or not the file is 
actually uploaded...certainly the test file I can see uploaded as a job number 
was assigned and the ununpack started. I'll check out Chrome. 

charlie

-Original Message-
From: Michael C. Jaeger [mailto:m...@mcj.de]
Sent: Thursday, January 31, 2019 7:10 AM
To: Kline, Charles (US) 
Cc: Jaeger, Michael C. ; Stangel, Dan 
; fossol...@fossology.org
Subject: Re: EXTERNAL: Re: [FOSSology] Quick Question

Hello,

looks good. it appears also to me that a part of your waiting time appears to 
be the upload / transfer time. Not all browsers show the upload progress, 
Chrome does in the lower left corner. On some OSes you can see the network 
traffic. I think this is maybe also another effect when dealing with VLP- "very 
large packages" Maybe FOSSology could improve on this by having an upload 
status dialogue to inform the user more precisely.

I think the last two screenshots show the progress info after the file has been 
uploaded to the FOSSology server.

Kind regards, Michael

> On 31. Jan 2019, at 09:53, Kline, Charles  wrote:
> 
> Hmmm, not sure I’m following you Michael….here’s some screenshots from 
> a test I did…  CLICK UPLOAD… 
>  Then I will see this…but this is after 
> the  uploaded has been completed and the ununpack has started as shown 
> below…   I 
> guess I was hoping there was a file or log on the fossology server that one 
> could tail to see the progress or at least repeatedly do a listing to see the 
> file growth.
>  
> Charlie
>  
> From: Jaeger, Michael C. [mailto:michael.c.jae...@siemens.com]
> Sent: Thursday, January 31, 2019 1:50 AM
> To: Kline, Charles (US) ; Michael C. Jaeger 
> 
> Cc: Stangel, Dan ; fossol...@fossology.org
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
>  
> Hi,
>  
> If you upload a file, there will be a link presented in the “message bar” 
> right below the menus with the number (id) of the upload. Clicking this 
> number will show you a table with the progress.
>  
> If you have missed that you could click on “Jobs” in the top menu bar, as for 
&g

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Kline, Charles]

Tried an upload using Chrome...I like that! Thanks...I have passed this on so 
someone can test a large file using Chrome. 

Hey, any thoughts on this...this was posed by one of our administrators..." The 
location where the file is uploaded to, does that have enough space to read the 
file. I don’t know if fossoloy uploads to a local area first and then puts the 
file in the define location so I can’t say where this location would be."

While trying to test last night with >2G files I was running 'top -u 
fossy'...as usual the only running was fo_scheduler...but this also show MEM 
and SWAPthe Available memory showed 8G...the used showed 7.xG with ~500M 
freeI never saw the free space fall much below this and I often see these 
numbers. Later when testing a very very small file I did see the Used in the 5G 
range. 

Charlie

-Original Message-
From: Kline, Charles (US) 
Sent: Thursday, January 31, 2019 8:14 AM
To: 'Michael C. Jaeger' 
Cc: Jaeger, Michael C. ; Stangel, Dan 
; fossol...@fossology.org
Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question

Hi Michael,
Yeah, big thing is we are trying to ascertain whether or not the file is 
actually uploaded...certainly the test file I can see uploaded as a job number 
was assigned and the ununpack started. I'll check out Chrome. 

charlie

-Original Message-
From: Michael C. Jaeger [mailto:m...@mcj.de]
Sent: Thursday, January 31, 2019 7:10 AM
To: Kline, Charles (US) 
Cc: Jaeger, Michael C. ; Stangel, Dan 
; fossol...@fossology.org
Subject: Re: EXTERNAL: Re: [FOSSology] Quick Question

Hello,

looks good. it appears also to me that a part of your waiting time appears to 
be the upload / transfer time. Not all browsers show the upload progress, 
Chrome does in the lower left corner. On some OSes you can see the network 
traffic. I think this is maybe also another effect when dealing with VLP- "very 
large packages" Maybe FOSSology could improve on this by having an upload 
status dialogue to inform the user more precisely.

I think the last two screenshots show the progress info after the file has been 
uploaded to the FOSSology server.

Kind regards, Michael

> On 31. Jan 2019, at 09:53, Kline, Charles  wrote:
> 
> Hmmm, not sure I’m following you Michael….here’s some screenshots from 
> a test I did…  CLICK UPLOAD… 
>  Then I will see this…but this is after 
> the  uploaded has been completed and the ununpack has started as shown 
> below…   I 
> guess I was hoping there was a file or log on the fossology server that one 
> could tail to see the progress or at least repeatedly do a listing to see the 
> file growth.
>  
> Charlie
>  
> From: Jaeger, Michael C. [mailto:michael.c.jae...@siemens.com]
> Sent: Thursday, January 31, 2019 1:50 AM
> To: Kline, Charles (US) ; Michael C. Jaeger 
> 
> Cc: Stangel, Dan ; fossol...@fossology.org
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
>  
> Hi,
>  
> If you upload a file, there will be a link presented in the “message bar” 
> right below the menus with the number (id) of the upload. Clicking this 
> number will show you a table with the progress.
>  
> If you have missed that you could click on “Jobs” in the top menu bar, as for 
> the options choose “my recent jobs”, it should show what is currently ongoing.
>  
> Kind regards, Michael
>  
> From: Kline, Charles [mailto:charles.kl...@lmco.com]
> Sent: Donnerstag, 31. Januar 2019 00:53
> To: Jaeger, Michael C. (CT RDA SSI); Michael C. Jaeger
> Cc: Stangel, Dan; fossol...@fossology.org
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
>  
> Hi,
> Is there a way to monitor (whether it be via the fossology GUI or on the 
> fossology server) the progress of the upload of a file?  Is there a log or 
> something that can be monitored?  In a previous test with a 2G file it took 
> ~10 min to upload. I don’t know if this is a linear thing where a 4G file 
> will take 20 minutes, but it would certainly be nice if one could tell how 
> far along the upload was so you don’t abort the test prematurely because you 
> felt you had given it enough time. 
>  
> Thanks in advance
>  
> Charlie
>  
> From: Jaeger, Michael C. [mailto:michael.c.jae...@siemens.com]
> Sent: Tuesday, January 22, 2019 7:36 AM
> To: Kline, Charles (US) ; Michael C. Jaeger 
> 
> Cc: Stangel, Dan ; fossol...@fossology.org
> Subject: EXTERNAL: RE: EXTERNAL: Re: [FOSSology] Just curious...question 
> about your installation...
>  
> Hello,
>  
> uploading 15GB in a single upload is not advisable in any case, since it will 
> lead to speed issues when browsing the source in an aggregated view.
>  
> 15GB of compressed source code will be like  … 100GB of uncompressed files? 
> that will be that will be maybe like >1000 pack

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Kline, Charles]

Hi,
Is there a way to monitor (whether it be via the fossology GUI or on the 
fossology server) the progress of the upload of a file?  Is there a log or 
something that can be monitored?  In a previous test with a 2G file it took ~10 
min to upload. I don't know if this is a linear thing where a 4G file will take 
20 minutes, but it would certainly be nice if one could tell how far along the 
upload was so you don't abort the test prematurely because you felt you had 
given it enough time.

Thanks in advance

Charlie

From: Jaeger, Michael C. [mailto:michael.c.jae...@siemens.com]
Sent: Tuesday, January 22, 2019 7:36 AM
To: Kline, Charles (US) ; Michael C. Jaeger 

Cc: Stangel, Dan ; fossol...@fossology.org
Subject: EXTERNAL: RE: EXTERNAL: Re: [FOSSology] Just curious...question about 
your installation...

Hello,

uploading 15GB in a single upload is not advisable in any case, since it will 
lead to speed issues when browsing the source in an aggregated view.

15GB of compressed source code will be like  ... 100GB of uncompressed files? 
that will be that will be maybe like >1000 packages into a single upload? maybe 
magnitude of 1 mio files in one upload? -> that will lead to endlessly running 
queries in the aggregated view unless you are really good at tuning your 
postgresql server.

I would highly recommend to consider splitting your 15GB upload into 30 
packages or so.

Kind regards, Michael



From: fossology@lists.fossology.org 
[mailto:fossology@lists.fossology.org] On Behalf Of Kline, Charles
Sent: Montag, 21. Januar 2019 20:10
To: Michael C. Jaeger
Cc: Stangel, Dan; fossol...@fossology.org
Subject: Re: EXTERNAL: Re: [FOSSology] Just curious...question about your 
installation...


Hi Michael,

Yeah, this could certainly be an issue...they would like to be able to process 
a 15G file and I don't think that is going to happen...if we could get 4G that 
would be nice, but based on the info below that may not even be possible. I'll 
be testing tonight with the following php.ini properties updated to 4096M but 
I'm not holding out much hope...



Maximum allowed size for uploaded files.

 upload_max_filesize = 2048M

Maximum size of POST data that PHP will accept.

post_max_size = 2048M



Excerpt from a 'lscpu':

Architecture:  x86_64

CPU op-mode(s):32-bit, 64-bit

CPU(s):4



If I do a 'cat /proc/meminfo':

MemTotal:8056932 kB

MemFree:  430432 kB



And not much running right now...results of 'top -u fossy', seems like we might 
be up against the limit now...

top - 13:29:18 up 8 days, 20:01,  1 user,  load average: 1.00, 1.38, 1.81

Tasks: 210 total,   2 running, 208 sleeping,   0 stopped,   0 zombie

Cpu(s):  3.3%us,  0.8%sy,  0.0%ni, 94.8%id,  1.1%wa,  0.0%hi,  0.1%si,  0.0%st

Mem:   8056932k total,  7627692k used,   429240k free,17668k buffers

Swap:  4193276k total,   157492k used,  4035784k free,  5471620k cached



  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND

17259 fossy 20   0 99.1m  30m 2820 R 92.3  0.4  10:01.71 nomos

7075 fossy 20   0  836m 2960 1668 S  0.0  0.0   1:48.17 fo_scheduler



Charlie



-Original Message-
From: Michael C. Jaeger [mailto:m...@mcj.de]
Sent: Friday, January 18, 2019 5:29 AM
To: Kline, Charles (US) mailto:charles.kl...@lmco.com>>
Cc: Stangel, Dan mailto:dan.stan...@hpe.com>>; 
fossol...@fossology.org
Subject: EXTERNAL: Re: [FOSSology] Just curious...question about your 
installation...



Hello,



I think as for the PHP is it the question how much RAM you have (and ... do you 
run a 32-bit OS?)



restarting apache depends on your linux distro, in some cases



  sudo service apache2 restart



or  a tool from the apache web server software could also help (which could be 
installed on your system, I do not know)



  sudo apachectl restart



in other cases google will help. Reading into apachectl can help you to do a 
more careful handling, such as



apachectl configtest

apachectl graceful



...



Kind regards, Michael



> On 16. Jan 2019, at 20:07, Kline, Charles 
> mailto:charles.kl...@lmco.com>> wrote:

>

> Just curious...what you have in your pkp.ini file for these properties...or I 
> guess I should ask can you process files greater than 2G?

> ; Maximum allowed size for uploaded files.

> upload_max_filesize = 2048M

>

> ; Maximum size of POST data that PHP will accept.

> post_max_size = 2048M

>

> Oh, do you know how to restart Apache??? Trying to figure that out.

>

> Charlie

>

> -Original Message-

> From: Kline, Charles (US)

> Sent: Wednesday, January 9, 2019 2:31 PM

> To: 'Stangel, Dan' mailto:dan.stan...@hpe.com>>; 
> fossol...@fossology.org

> Subject: RE: Question on version 2.5.0

>

> Thanks so much Dan

>

> -Original Message-

> From: Stangel, Dan [mailto:dan.stan...@hpe

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Kline, Charles]

Hi Michael, 
Yeah, big thing is we are trying to ascertain whether or not the file is 
actually uploaded...certainly the test file I can see uploaded as a job number 
was assigned and the ununpack started. I'll check out Chrome. 

charlie

-Original Message-
From: Michael C. Jaeger [mailto:m...@mcj.de] 
Sent: Thursday, January 31, 2019 7:10 AM
To: Kline, Charles (US) 
Cc: Jaeger, Michael C. ; Stangel, Dan 
; fossol...@fossology.org
Subject: Re: EXTERNAL: Re: [FOSSology] Quick Question

Hello,

looks good. it appears also to me that a part of your waiting time appears to 
be the upload / transfer time. Not all browsers show the upload progress, 
Chrome does in the lower left corner. On some OSes you can see the network 
traffic. I think this is maybe also another effect when dealing with VLP- "very 
large packages" Maybe FOSSology could improve on this by having an upload 
status dialogue to inform the user more precisely.

I think the last two screenshots show the progress info after the file has been 
uploaded to the FOSSology server.

Kind regards, Michael

> On 31. Jan 2019, at 09:53, Kline, Charles  wrote:
> 
> Hmmm, not sure I’m following you Michael….here’s some screenshots from 
> a test I did…  CLICK UPLOAD… 
>  Then I will see this…but this is after 
> the  uploaded has been completed and the ununpack has started as shown 
> below…   I 
> guess I was hoping there was a file or log on the fossology server that one 
> could tail to see the progress or at least repeatedly do a listing to see the 
> file growth.
>  
> Charlie
>  
> From: Jaeger, Michael C. [mailto:michael.c.jae...@siemens.com]
> Sent: Thursday, January 31, 2019 1:50 AM
> To: Kline, Charles (US) ; Michael C. Jaeger 
> 
> Cc: Stangel, Dan ; fossol...@fossology.org
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
>  
> Hi,
>  
> If you upload a file, there will be a link presented in the “message bar” 
> right below the menus with the number (id) of the upload. Clicking this 
> number will show you a table with the progress.
>  
> If you have missed that you could click on “Jobs” in the top menu bar, as for 
> the options choose “my recent jobs”, it should show what is currently ongoing.
>  
> Kind regards, Michael
>  
> From: Kline, Charles [mailto:charles.kl...@lmco.com]
> Sent: Donnerstag, 31. Januar 2019 00:53
> To: Jaeger, Michael C. (CT RDA SSI); Michael C. Jaeger
> Cc: Stangel, Dan; fossol...@fossology.org
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
>  
> Hi,
> Is there a way to monitor (whether it be via the fossology GUI or on the 
> fossology server) the progress of the upload of a file?  Is there a log or 
> something that can be monitored?  In a previous test with a 2G file it took 
> ~10 min to upload. I don’t know if this is a linear thing where a 4G file 
> will take 20 minutes, but it would certainly be nice if one could tell how 
> far along the upload was so you don’t abort the test prematurely because you 
> felt you had given it enough time. 
>  
> Thanks in advance
>  
> Charlie
>  
> From: Jaeger, Michael C. [mailto:michael.c.jae...@siemens.com]
> Sent: Tuesday, January 22, 2019 7:36 AM
> To: Kline, Charles (US) ; Michael C. Jaeger 
> 
> Cc: Stangel, Dan ; fossol...@fossology.org
> Subject: EXTERNAL: RE: EXTERNAL: Re: [FOSSology] Just curious...question 
> about your installation...
>  
> Hello,
>  
> uploading 15GB in a single upload is not advisable in any case, since it will 
> lead to speed issues when browsing the source in an aggregated view.
>  
> 15GB of compressed source code will be like  … 100GB of uncompressed files? 
> that will be that will be maybe like >1000 packages into a single upload? 
> maybe magnitude of 1 mio files in one upload? -> that will lead to endlessly 
> running queries in the aggregated view unless you are really good at tuning 
> your postgresql server.
>  
> I would highly recommend to consider splitting your 15GB upload into 30 
> packages or so.
>  
> Kind regards, Michael
>  
>  
>  
> From: fossology@lists.fossology.org 
> [mailto:fossology@lists.fossology.org] On Behalf Of Kline, Charles
> Sent: Montag, 21. Januar 2019 20:10
> To: Michael C. Jaeger
> Cc: Stangel, Dan; fossol...@fossology.org
> Subject: Re: EXTERNAL: Re: [FOSSology] Just curious...question about your 
> installation...
>  
> Hi Michael,
> Yeah, this could certainly be an issue...they would like to be able to 
> process a 15G file and I don’t think that is going to happen…if we 
> could get 4G that would be nice, but based on the info below that may 
> not even be possible. I’ll be testing tonight with the following 
> php.ini properties updated to 4096M but I’m not holding out much hope…
>  

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Michael C. Jaeger]

Hello,

looks good. it appears also to me that a part of your waiting time appears to 
be the upload / transfer time. Not all browsers show the upload progress, 
Chrome does in the lower left corner. On some OSes you can see the network 
traffic. I think this is maybe also another effect when dealing with VLP- "very 
large packages" Maybe FOSSology could improve on this by having an upload 
status dialogue to inform the user more precisely.

I think the last two screenshots show the progress info after the file has been 
uploaded to the FOSSology server.

Kind regards, Michael

> On 31. Jan 2019, at 09:53, Kline, Charles  wrote:
> 
> Hmmm, not sure I’m following you Michael….here’s some screenshots from a test 
> I did…
> 
> CLICK UPLOAD…
> 
> Then I will see this…but this is after the  uploaded has been completed and 
> the ununpack has started as shown below…
> 
> 
> I guess I was hoping there was a file or log on the fossology server that one 
> could tail to see the progress or at least repeatedly do a listing to see the 
> file growth.
>
> Charlie
>
> From: Jaeger, Michael C. [mailto:michael.c.jae...@siemens.com] 
> Sent: Thursday, January 31, 2019 1:50 AM
> To: Kline, Charles (US) ; Michael C. Jaeger 
> 
> Cc: Stangel, Dan ; fossol...@fossology.org
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
>
> Hi,
>
> If you upload a file, there will be a link presented in the “message bar” 
> right below the menus with the number (id) of the upload. Clicking this 
> number will show you a table with the progress.
>
> If you have missed that you could click on “Jobs” in the top menu bar, as for 
> the options choose “my recent jobs”, it should show what is currently ongoing.
>
> Kind regards, Michael
>
> From: Kline, Charles [mailto:charles.kl...@lmco.com] 
> Sent: Donnerstag, 31. Januar 2019 00:53
> To: Jaeger, Michael C. (CT RDA SSI); Michael C. Jaeger
> Cc: Stangel, Dan; fossol...@fossology.org
> Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question
>
> Hi, 
> Is there a way to monitor (whether it be via the fossology GUI or on the 
> fossology server) the progress of the upload of a file?  Is there a log or 
> something that can be monitored?  In a previous test with a 2G file it took 
> ~10 min to upload. I don’t know if this is a linear thing where a 4G file 
> will take 20 minutes, but it would certainly be nice if one could tell how 
> far along the upload was so you don’t abort the test prematurely because you 
> felt you had given it enough time. 
>
> Thanks in advance
>
> Charlie
>
> From: Jaeger, Michael C. [mailto:michael.c.jae...@siemens.com] 
> Sent: Tuesday, January 22, 2019 7:36 AM
> To: Kline, Charles (US) ; Michael C. Jaeger 
> 
> Cc: Stangel, Dan ; fossol...@fossology.org
> Subject: EXTERNAL: RE: EXTERNAL: Re: [FOSSology] Just curious...question 
> about your installation...
>
> Hello,
>
> uploading 15GB in a single upload is not advisable in any case, since it will 
> lead to speed issues when browsing the source in an aggregated view.
>
> 15GB of compressed source code will be like  … 100GB of uncompressed files? 
> that will be that will be maybe like >1000 packages into a single upload? 
> maybe magnitude of 1 mio files in one upload? -> that will lead to endlessly 
> running queries in the aggregated view unless you are really good at tuning 
> your postgresql server.
>
> I would highly recommend to consider splitting your 15GB upload into 30 
> packages or so.
>
> Kind regards, Michael
>
>
>
> From: fossology@lists.fossology.org [mailto:fossology@lists.fossology.org] On 
> Behalf Of Kline, Charles
> Sent: Montag, 21. Januar 2019 20:10
> To: Michael C. Jaeger
> Cc: Stangel, Dan; fossol...@fossology.org
> Subject: Re: EXTERNAL: Re: [FOSSology] Just curious...question about your 
> installation...
>
> Hi Michael, 
> Yeah, this could certainly be an issue...they would like to be able to 
> process a 15G file and I don’t think that is going to happen…if we could get 
> 4G that would be nice, but based on the info below that may not even be 
> possible. I’ll be testing tonight with the following php.ini properties 
> updated to 4096M but I’m not holding out much hope…
>
> Maximum allowed size for uploaded files.
>  upload_max_filesize = 2048M 
> Maximum size of POST data that PHP will accept.
> post_max_size = 2048M
>
> Excerpt from a 'lscpu':
> Architecture:  x86_64
> CPU op-mode(s):32-bit, 64-bit
> CPU(s):4
>
> If I do a ‘cat /proc/meminfo’:
> MemTotal:8056932 kB
> MemFree:  430432 kB
>
> And not much running right now…results of ‘top –u fossy’, seems like we might 
&

Re: EXTERNAL: Re: [FOSSology] Quick Question

[Michael C. Jaeger]

Hi,

If you upload a file, there will be a link presented in the "message bar" right 
below the menus with the number (id) of the upload. Clicking this number will 
show you a table with the progress.

If you have missed that you could click on "Jobs" in the top menu bar, as for 
the options choose "my recent jobs", it should show what is currently ongoing.

Kind regards, Michael

From: Kline, Charles [mailto:charles.kl...@lmco.com]
Sent: Donnerstag, 31. Januar 2019 00:53
To: Jaeger, Michael C. (CT RDA SSI); Michael C. Jaeger
Cc: Stangel, Dan; fossol...@fossology.org
Subject: RE: EXTERNAL: Re: [FOSSology] Quick Question

Hi,
Is there a way to monitor (whether it be via the fossology GUI or on the 
fossology server) the progress of the upload of a file?  Is there a log or 
something that can be monitored?  In a previous test with a 2G file it took ~10 
min to upload. I don't know if this is a linear thing where a 4G file will take 
20 minutes, but it would certainly be nice if one could tell how far along the 
upload was so you don't abort the test prematurely because you felt you had 
given it enough time.

Thanks in advance

Charlie

From: Jaeger, Michael C. [mailto:michael.c.jae...@siemens.com]
Sent: Tuesday, January 22, 2019 7:36 AM
To: Kline, Charles (US) ; Michael C. Jaeger 

Cc: Stangel, Dan ; fossol...@fossology.org
Subject: EXTERNAL: RE: EXTERNAL: Re: [FOSSology] Just curious...question about 
your installation...

Hello,

uploading 15GB in a single upload is not advisable in any case, since it will 
lead to speed issues when browsing the source in an aggregated view.

15GB of compressed source code will be like  ... 100GB of uncompressed files? 
that will be that will be maybe like >1000 packages into a single upload? maybe 
magnitude of 1 mio files in one upload? -> that will lead to endlessly running 
queries in the aggregated view unless you are really good at tuning your 
postgresql server.

I would highly recommend to consider splitting your 15GB upload into 30 
packages or so.

Kind regards, Michael



From: fossology@lists.fossology.org<mailto:fossology@lists.fossology.org> 
[mailto:fossology@lists.fossology.org] On Behalf Of Kline, Charles
Sent: Montag, 21. Januar 2019 20:10
To: Michael C. Jaeger
Cc: Stangel, Dan; fossol...@fossology.org<mailto:fossol...@fossology.org>
Subject: Re: EXTERNAL: Re: [FOSSology] Just curious...question about your 
installation...


Hi Michael,

Yeah, this could certainly be an issue...they would like to be able to process 
a 15G file and I don't think that is going to happen...if we could get 4G that 
would be nice, but based on the info below that may not even be possible. I'll 
be testing tonight with the following php.ini properties updated to 4096M but 
I'm not holding out much hope...



Maximum allowed size for uploaded files.

 upload_max_filesize = 2048M

Maximum size of POST data that PHP will accept.

post_max_size = 2048M



Excerpt from a 'lscpu':

Architecture:  x86_64

CPU op-mode(s):32-bit, 64-bit

CPU(s):4



If I do a 'cat /proc/meminfo':

MemTotal:8056932 kB

MemFree:  430432 kB



And not much running right now...results of 'top -u fossy', seems like we might 
be up against the limit now...

top - 13:29:18 up 8 days, 20:01,  1 user,  load average: 1.00, 1.38, 1.81

Tasks: 210 total,   2 running, 208 sleeping,   0 stopped,   0 zombie

Cpu(s):  3.3%us,  0.8%sy,  0.0%ni, 94.8%id,  1.1%wa,  0.0%hi,  0.1%si,  0.0%st

Mem:   8056932k total,  7627692k used,   429240k free,17668k buffers

Swap:  4193276k total,   157492k used,  4035784k free,  5471620k cached



  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND

17259 fossy 20   0 99.1m  30m 2820 R 92.3  0.4  10:01.71 nomos

7075 fossy 20   0  836m 2960 1668 S  0.0  0.0   1:48.17 fo_scheduler



Charlie



-Original Message-
From: Michael C. Jaeger [mailto:m...@mcj.de]
Sent: Friday, January 18, 2019 5:29 AM
To: Kline, Charles (US) mailto:charles.kl...@lmco.com>>
Cc: Stangel, Dan mailto:dan.stan...@hpe.com>>; 
fossol...@fossology.org<mailto:fossol...@fossology.org>
Subject: EXTERNAL: Re: [FOSSology] Just curious...question about your 
installation...



Hello,



I think as for the PHP is it the question how much RAM you have (and ... do you 
run a 32-bit OS?)



restarting apache depends on your linux distro, in some cases



  sudo service apache2 restart



or  a tool from the apache web server software could also help (which could be 
installed on your system, I do not know)



  sudo apachectl restart



in other cases google will help. Reading into apachectl can help you to do a 
more careful handling, such as



apachectl configtest

apachectl graceful



...



Kind regards, Michael



> On 16. Jan 2019, at 20:07, Kline, Charles 
> mailto:charles.kl...@lmco.com>> w