Owncloud + Nginx = scan.php cancelled requests ?

[eva2000]

Anyone using Owncloud and Nginx getting scan.php cancelled requests within browser ? The error log says the scan.php request = 200 status but browser says otherwise ? 

It is my first time installing Owncloud on Centmin Mod Nginx LEMP stack. I used the outlined steps to install and configure everything https://gist.github.com/centminmod/87f05fdce6b65435ceb2

Access log reports 200 status ok though


tail -50 /home/nginx/domains/owncloud1.com/log/access.log | grep scan

192.168.0.xxx - - [01/May/2014:05:30:43 +1000] "GET /index.php/apps/files/ajax/scan.php?force=false&dir=&requesttoken=8a899ccc1b5f3dfc7023 HTTP/1.1" 200 83 "https://owncloud1.com/index.php/apps/files" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.154 Safari/537.36 OPR/20.0.1387.91"

scan.php cancelled request

 

[wlanboy]

The "canceled" status might be a timeout problem.

Can you check the free memory?

And how much the php process is eating?

Maybe owncloud is hitting the RAM limit in php.ini?

 

[eva2000]

thanks, it's local virtualbox guest os with 3GB memory so should be sufficient

smem -kpt; free -m; php -i | grep memory_limit

  PID User     Command                         Swap      USS      PSS      RSS 
 1157 root     /sbin/mingetty /dev/tty1           0    80.0K   101.0K   560.0K 
 1163 root     /sbin/mingetty /dev/tty4           0    80.0K   101.0K   560.0K 
 1165 root     /sbin/mingetty /dev/tty5           0    80.0K   101.0K   560.0K 
 1159 root     /sbin/mingetty /dev/tty2           0    84.0K   105.0K   564.0K 
 1161 root     /sbin/mingetty /dev/tty3           0    84.0K   105.0K   564.0K 
 1171 root     /sbin/mingetty /dev/tty6           0    84.0K   105.0K   564.0K 
  385 root     /sbin/udevd -d                484.0K    76.0K   123.0K   440.0K 
 1169 root     /sbin/udevd -d                464.0K    84.0K   147.0K   444.0K 
 1168 root     /sbin/udevd -d                464.0K    84.0K   148.0K   456.0K 
 4078 nsd      /usr/local/sbin/nsd -c /etc        0    92.0K   241.0K   956.0K 
 4081 nsd      /usr/local/sbin/nsd -c /etc        0   156.0K   269.0K   612.0K 
  937 root     auditd                             0   320.0K   348.0K   824.0K 
  975 dbus     dbus-daemon --system               0   440.0K   461.0K   796.0K 
 4110 root     /bin/sh /usr/bin/mysqld_saf        0   304.0K   623.0K     1.4M 
    1 root     /sbin/init                     60.0K   584.0K   640.0K     1.3M 
 1144 root     crond                              0   680.0K   723.0K     1.3M 
 5452 nobody   /usr/local/bin/memcached -d        0   740.0K   765.0K     1.1M 
 1318 root     /usr/sbin/sshd                     0   712.0K   805.0K     1.2M 
  953 root     /sbin/rsyslogd -i /var/run/        0   916.0K   957.0K     1.5M 
12426 root     nginx: master process /usr/        0   272.0K   957.0K     2.5M 
 3901 root     /usr/libexec/postfix/master        0     1.1M     1.2M     2.1M 
22864 postfix  pickup -l -t unix -u               0     1.1M     1.8M     3.9M 
 3950 postfix  qmgr -l -t unix -u                 0     1.2M     1.9M     4.0M 
22940 root     sshd: root@pts/0                   0     1.8M     2.3M     4.1M 
12428 nginx    nginx: worker process              0     1.4M     2.6M     5.3M 
12427 nginx    nginx: worker process              0     1.5M     2.7M     5.3M 
22943 root     -bash                              0     2.6M     3.0M     3.9M 
 5234 root     /usr/sbin/haveged -w 3072 -        0     3.1M     3.1M     3.5M 
 4080 nsd      /usr/local/sbin/nsd -c /etc        0     4.2M     4.3M     4.7M 
21787 root     php-fpm: master process (/u        0     5.4M     5.5M     6.0M 
23019 root     python /usr/bin/smem -kpt          0     5.9M     6.0M     6.7M 
 7340 root     lfd - sleepin                      0    13.9M    13.9M    14.5M 
 5157 mysql    /usr/sbin/mysqld --basedir=        0    48.1M    48.5M    50.0M 
-------------------------------------------------------------------------------
   33 7                                        1.4M    97.2M   104.4M   132.0M 

             total       used       free     shared    buffers     cached
Mem:          2887       1995        891          0        109       1551
-/+ buffers/cache:        334       2552
Swap:         1839          0       1839

memory_limit => 128M => 128M

 

[splitice]

Is it a long running request (i.e with no data being transferred within read_timeout)?

 

[eva2000]

It shouldn't be a long running request as only me testing on local virtualbox with virtually very little data being served and fastcgi php connect, send and read time outs are all set to 180 seconds.

FYI, pretty much everything seems to work so far so not sure if this is a bug or a misconfiguration on my end seeing as it's my first time installing Owncloud

 

[splitice]

Enable error logging (try warning level) in nginx and look for a message. If the connection is terminated for any reason by nginx or prematurely by either party (backend or client) there will be a message.

 

[kcaj]

What does scan.php do? If I recall correctly it scans the physical file directory for any files not added to the user directory via supported channels?

It's tricky getting ownCloud to run on nginx anyway because of the amount of .htaccess code needed. Have you followed a specific tutorial or just chucked owncloud files onto a out of the box nginx config?

 

[eva2000]

Enable error logging (try warning level) in nginx and look for a message. If the connection is terminated for any reason by nginx or prematurely by either party (backend or client) there will be a message.

thanks nothing in the logs themselves

What does scan.php do? If I recall correctly it scans the physical file directory for any files not added to the user directory via supported channels?

It's tricky getting ownCloud to run on nginx anyway because of the amount of .htaccess code needed. Have you followed a specific tutorial or just chucked owncloud files onto a out of the box nginx config?

Using official manual install tutorial http://doc.owncloud.org/server/6.0/admin_manual/installation/installation_source.html but woven into Centmin Mod Nginx's structure/vhost setup outlined at https://gist.github.com/centminmod/87f05fdce6b65435ceb2

but no idea to be honest what scan.php does (having hard time even googling for it), literally first time using and installing OwnCloud heh.

from command line 


curl "https://owncloud1.com/index.php/apps/files/ajax/scan.php?force=false&dir=&requesttoken=035fd09b64080394496c" -H "pragma: no-cache" -H "dnt: 1" -H "accept-encoding: gzip,deflate,lzma,sdch" -H "accept-language: en-US,en;q=0.8" -H "user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.154 Safari/537.36 OPR/20.0.1387.91" -H "accept: text/event-stream" -H "cache-control: no-cache" -H "cookie: oc0584ded3c9=omj0kv3hsa21i9rgffh9ss1162; oc_username=admin; oc_token=881e7667c169eb9d60ccc7e83f652d27; oc_remember_login=1; PHPSESSID=1l5sn1squo6uq9h7ropd3g8sr2" -H "referer: https://owncloud1.com/index.php" --compressed -k
event: user
data: "admin"

event: done
data: 0

event: __internal__
data: "close"

maybe data 0 means nothing to do so close connection ? The connection is being closed from owncloud app itself it seems ?

 

[kcaj]

I've no idea then. Maybe ownCloud is closing itself, I doubt it should be scanning every time the web page is accessed anyway as that could use a lot of resources. It isn't needed if you're using the ownCloud interface to manage files anyway.

EDIT: That request shows as red for me but does return status 200.

 

[splitice]

If it its not nginx timeout it could be a browser timeout. 

Ive actually been thinking, XHR has an abort method are you sure its not just normal operating condtitions (i.e if a page is changed abort() current background requests)

 

[eva2000]

Thanks 1e10 for the confirmation.

Yeah could be just normal operations.. hence why I posted here to see if other Owncloud users experience the same.

 

[JahAGR]

Hi,



I'm seeing the same "cancelled" request to scan.php on my OwnCloud install which uses Apache, so it doesn't look like it's an issue specifically with nginx.

Whether it's normal or not I don't know, but I have several users on both the web interface + sync clients and there have been zero issues.

 

[splitice]

From memory, the only places where Chrome will cancel a request:

• The DOM element that caused the request to be made got deleted (i.e. an IMG is being loaded, but before the load happened, you deleted the IMG node)
• You did something that made loading the data unnecessary. (i.e. you started loading a iframe, then changed the src or overwrite the contents)
• There are lots of requests going to the same server, and a network problem on earlier requests showed that subsequent requests weren't going to work (DNS lookup error, etc)

http://stackoverflow.com/questions/12009423/what-does-status-canceled-for-a-resource-mean-in-chrome-developer-tools