Is it possible to upload images directly from Picassa? (Would be nice!)
Amazing World - full of unexpected surprises!
Ranger187
Joined: 2005-12-02
Posts: 199
Posted: Sat, 2010-08-07 13:57
peterkr wrote:
Is it possible to upload images directly from Picassa? (Would be nice!)
Amazing World - full of unexpected surprises!
You mean import. That would be more like a plugin. ;)
nivekiam
Joined: 2002-12-10
Posts: 16503
Posted: Sat, 2010-08-07 14:44
Press Enter on the keyboard
Just
like
I'm
doing
now
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
dzm
Joined: 2004-08-11
Posts: 53
Posted: Sat, 2010-08-07 20:40
Feedback after initial install of missing Graphics toolkit was misleading.
My environment:
Sun Web Server 7
PHP 5.3.2 (FastCGI)
MySQL 5.0.75
Centos 5.3
After performing the initial install/configuration clicking the "Use Gallery" link sent me to a page that threw an error:
"error: Database_Exception [ 44 ]: #2006: MySQL server has gone away [ SHOW COLUMNS FROM `items` ]"
This caused me to go down a rat-hole of verifying system requirements, etc. I was eventually able to confirm that all the required PHP extensions were enabled and functioning, that MySQL was working fine (all the other MySQL/PHP driven apps on my site were still functioning just fine), etc.
After much digging I found the Gallery3 var/logs/ directory (it would be handy if the errors page pointed to this directory for G3 related errors logs). A look at the log file showed the error above, but also showed it immediately preceded with:
"error: load_user Exception: #2006: MySQL server has gone away [ SHOW COLUMNS FROM `vars` ]"
This error was not mentioned in the error page being thrown to the browser, but ultimately that didn't matter. It was also not the root of the problem.
After exhausting all apparent possible failure causes I used strace (with -ttt for microsecond time stamps) to see what interaction PHP and MySQL were having. I was able to see the connection get opened (FD 2), authentication happen, and several SQL commands and responses exchanged. Then, out of nowhere, I see this text written to FD 2:
18085 1281206332.496541 write(2, "which: no gm in (/export/WS7/bin:/export/WS7/lib:/bin:/usr/kerberos/sbin:/usr/kerberos/bin: /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/usr/local/bin:/opt/local/bin:/opt/bin)\n", 191) = 191
Shortly after that I see:
17442 1281206332.510898 read(2, "", 8192) = 0
17442 1281206332.510948 shutdown(2, 2 /* send and receive */) = -1 ENOTCONN (Transport endpoint is not connected)
17442 1281206332.510990 close(2) = 0
What APPEARS to have happened is that Gallery3 tried to find gm using which, was unable to find it, and spewed an error about that to the open MySQL socket. The MySQL server understandably was unhappy about this and dropped the socket.
After hunting down a copy of GraphicsMagick for Centos (not as easy as it sounds) and installing it the error immediately went away. Gallery3 is now working as expected.
So - G3 RC2 broke when GraphicsMagick was not installed, and the errors returned were not indicative of the core cause.
dzm
Joined: 2004-08-11
Posts: 53
Posted: Sat, 2010-08-07 20:46
Gallery2_Import fails when used with PHP 5.3.x
When attempting to use the Gallery2_Import module with PHP 5.3.x to migrate from Gallery2, this error is returned after specifying the path to embed.php:
ErrorException [ Deprecated ]: Assigning the return value of new by reference is deprecated
DOCROOT/var/modules/g2_import/a4cb62b7cd501da0c07d98078bf906ec/bootstrap.inc[ 44 ]
39 * the constructor registers a shutdown function and ties it to the instance in
40 * the constructor. This global should be the only one that Gallery requires.
41 * Everything else should be inside it so that we do not pollute the namespace
42 * (especially important when we're embedded inside another application).
43 */
44 $gallery =& new G2_Gallery();
45 $GLOBALS['gallery'] =& $gallery;
46
47 if (!defined('GALLERY_CONFIG_DIR')) {
48 define('GALLERY_CONFIG_DIR', '/mnt/home/httpd/photos/gallery2');
49 }
From what I can gather this method ( =& ) of assigning a return value by reference stopped working with the release of PHP 5.3.0.
bharat
Joined: 2002-05-21
Posts: 7985
Posted: Sat, 2010-08-07 22:52
@dzm: thanks for the detailed analysis. The write on FD 2 is happening for a different process (18085) than the subsequent read (17442). I'm dubious that those are shared file descriptors; that would be a pretty egregious problem. However, I don't doubt that there's some connection, I'm just not sure what it might be. Either way, I'm not sure what we can do about it :-/
For the G2 import issue; this problem should be breaking your G2 as well. Upgrade to Gallery 2.3.1, it supports PHP 5.3.x properly then your import should work properly.
---
Problems? Check gallery3/var/logs bugs/feature req's | upgrade to the latest code | use git
dzm
Joined: 2004-08-11
Posts: 53
Posted: Sun, 2010-08-08 02:39
Ahh! You're right bharat! I hadn't noticed the change in PHP PID. Interesting. Regardless, that "no gm in ..." error is not in any of my log files, so I'm not positive where it got written out to on FD2, AND immediately following that error MySQL dropped the connection. Installing GraphicMagick made that behavior go away.
Aaaand. Good call on the G2 problem. Digging around in the admin console for a while I was able to find: Gallery version = 2.3 core 1.3.0
I'll update to 2.3.1 and see if the problem persists.
Thanks!
Edit:
Looking through the strace output, 17442 is the parent of 18085. 1805 is created here:
There's a whole lot of standard library loading on FD3, then we get our error on FD2 (stderr()) from which:
18085 1281206332.495746 stat64("/export/WS7/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.495805 stat64("/export/WS7/lib/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.495862 stat64("/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.495912 stat64("/usr/kerberos/sbin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.495969 stat64("/usr/kerberos/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496025 stat64("/usr/local/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496080 stat64("/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496130 stat64("/usr/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496182 stat64("/usr/X11R6/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496244 stat64("/sbin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496296 stat64("/usr/sbin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496350 stat64("/usr/local/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496405 stat64("/opt/local/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496460 stat64("/opt/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496541 write(2, "which: no gm in (/export/WS7/bin:/export/WS7/lib:/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin: /bin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/usr/local/bin:/opt/local/bin:/opt/bin)\n", 191) = 191
18085 1281206332.496788 exit_group(1) = ?
17442 1281206332.496984 <... read resumed> "", 8192) = 0
17442 1281206332.497009 --- SIGCHLD (Child exited) @ 0 (0) ---
As you see, 18085 then terminates itself.
At that point 17442 immediately locates var.php (after the stat64 hunt through the includes paths), reads a couple of vars, closes vars.php and does the same hunt for MY_Var_Model.php (and fails since that files seems not to exist), tries to read from FD2 and fails:
Just before the crazy dance with GraphicsMagick G3 did the exact same dance with ImageMagick (which is installed) and a child process, except rahter than use which to determine if IM is installed G3 instead executes convert -v. G3 (or the PHP ppid) is getting results from this search via the child's FD1 (stdout) instead of FD2 (stderr).
Is it possible that the child PID returning data over stderr is somehow causing G3 and/or PHP 5.3.x to take that input and relay it to its own FD2?
Regarding how to fix ... Beats me. The only obvious thing I can think of is to do the tools check prior to the DB queries and allow the admin to "disable" not-found toolkits.
And more edit: You're right. Upgrading to G2.3.1 fixed the import problem.
nivekiam
Joined: 2002-12-10
Posts: 16503
Posted: Sun, 2010-08-08 02:51
I wonder if there's an issue with our detection of image toolkits on Solaris.
I know this guy had to specify the path in Advanced settings: http://gallery.menalto.com/node/93328
Those problems seem to be with G3 not finding IM, though IM is actually installed. In my case GM was NOT installed and the G3 was/is coping with the failure in a really ugly way. I solved the problem by hunting down GraphicsMagick for Centos and installing it (not easy since there is no official RPM package for GM for Centos, and because G3 gave no indication that this was the problem).
bharat
Joined: 2002-05-21
Posts: 7985
Posted: Sun, 2010-08-08 05:41
Hrm. Hard to tell what's going on here. Either way, we're forking subprocs to find and use GM andIM so it's not surprising to see the subproc start up and check every possible location on your path to find the binary then shut down. When we do image toolkit detection, we also run "convert -v" to figure out what version of ImageMagick you have installed. We run "gm version" to find the same value for GraphicsMagick. But those subprocs should be fully isolated and shouldn't be able to stomp on your MySQL connection -- that'd have to be a flaw in PHP of some kind..
---
Problems? Check gallery3/var/logs bugs/feature req's | upgrade to the latest code | use git
dzm
Joined: 2004-08-11
Posts: 53
Posted: Sun, 2010-08-08 07:13
I still have the strace output if you want it. I don't know if it would shed any more light on things than the snippets here do.
@dzm: got it. I don't see any connection there between the missing toolkit and the database connection going away. The only theory I have is that you have a very short idle timeout on your database connection and the various subproc calls are making the request take long enough (~1.1 seconds) that the connection goes away. That's pretty slim. I'm always in agreement that we could use some better error messages, but I'm not sure what we could add to make this problem better. Ideas welcome.
I spent a lot of time chasing the low-timeout theory. Here's every MySQL variable that involves the word "timeout":
connect timeout 10
delayed insert timeout 300
innodb lock wait timeout 50
innodb rollback on timeout OFF
interactive timeout 28,800
net read timeout 30
net write timeout 60
slave net timeout 3,600
table lock wait timeout 50
wait timeout 600
I see nothing at all that would be bothered by a ~1.1 second pause between queries. It's also worth noting that this MySQL and PHP config is driving without any problems two phpBB, three Drupal, and three G2 instances. They're all working fine. And this problem (the error page being thrown after the "Install successful, start using G3" page) was unchanged regardless of tuning I did to PHP and/or MySQL, but went away entirely once I installed GraphicsMagick.
I don't know what else I can contribute beyond this, but I'm certainly willing to prod things and return results if you'd like me to.
Just for fun I also just tried intentionally "breaking" GM by moving /usr/bin/gm to /usr/bin/gm-bkp. G3 continues to work as expected. So it seems that the problem is present ONLY immediately following installation while the vars are being gathered for storage into the DB. It's not something that continues to be broken post-installation if the toolkit disappears.
Also, new feedback: During a long G2 import the "thermometer" page needs to remain open. Unfortunately the JavaScript driving this page eventually causes Firefox 4b2 to complain that a "script has been running for a long time and may be hurting performance" (or something along those lines). Once the admin clears away the error the import must be "resumed" from the Maintenance page. It may be preferable to force the page holding the thermometer to do a reload of the entire page (including the JavaScript) from the server every five minutes or so in order to prevent the JavaScript engine from getting grumpy, and to force any accumulated cruft to be flushed (a pretty brute force garbage collection).
bharat
Joined: 2002-05-21
Posts: 7985
Posted: Sun, 2010-08-08 18:27
From your symptoms, this is definitely happening when we do the post-install call to graphics::detect_toolkits(). We could try avoiding using "which" to see if we can detect the binary by hand by parsing your PATH. Sigh. The point in supporting a standard platform is so that we don't have to deal with these kinds of issues, though. I'm going write this issue off as a problem with Sun Web Server 7 until we can reproduce it on Apache 2.
I'll try installing Firefox 4b2 and see if I can reproduce that problem -- it definitely shouldn't be happening so we might have to massage the JS a bit.
---
Problems? Check gallery3/var/logs bugs/feature req's | upgrade to the latest code | use git
dzm
Joined: 2004-08-11
Posts: 53
Posted: Sun, 2010-08-08 18:57
I also notice that the latter half of the import, the "importing tags" segment, seems really prone to stalling. The GUI gives no indication of the stall though. The Thermometer continues to sit on top of the window/tab, but no progress gets made. The only way I notice that work has stopped is that the progress number stops changing and the system load drops.
On the server side I notice that the tag importing seems to work PHP and MySQL really hard. System load on an Amazon EC21 "small" instance floats at around 2.0 (1min) during the image importing, and then at around 4-5(1min) during the tag import with PHP using ~20-25% of CPU and MySQL running at ~8-10% of CPU. I don't pretend to know what work is happening behing the scenes to copy the tags over, this seems like it's working awfully hard to do it.
Re the GM problem ... I'm not sure I understand how Sun Web Server 7 could be the culprit. The parentage of the processes is:
WS7 -> FCGI_Stub -> PHP -> "which gm"
In theory WS7 and its FCGI stub process should only be passing a FCGI request to the children and, when processing by PHP is complete, receiving a result. It's possible that WS7 is passing some environment variables to the children that are different than would get passed by Apache (or ligHTTPd, or NGinX, or IIS), but I'd be surprised if this were the cause.
I'll spin up a vanilla Centos 5.3 with Apache2 and see if I can reproduce the problem.
dzm
Joined: 2004-08-11
Posts: 53
Posted: Sun, 2010-08-08 19:36
Alrighty - It seems that there's a really easy fix to this. Just throw away stderr() from the which commands. Changing the which call from:
made the failure go away for me. Reverting it made the problem come back.
I'm sending you a PM with the URL for a two-line patch that makes this change for the IM and GM which lookups. The patch is yours if you want it.
bharat
Joined: 2002-05-21
Posts: 7985
Posted: Sun, 2010-08-08 19:53
I'm going to wait on doing that patch until we have a repeatable case of this on Apache 2, since we're in release candidate stages and I don't understand exactly why that fixes the problem and don't want to damage the experience for other users.
---
Problems? Check gallery3/var/logs bugs/feature req's | upgrade to the latest code | use git
dzm
Joined: 2004-08-11
Posts: 53
Posted: Sun, 2010-08-08 21:29
Understood.
I've also done some more experimentation. This seems 100% a problem (bug?) in PHP 5.3.2's handling of stderr() results from an exec().
ANY output (even valid output) from the exec() child on stderr makes G3 throw that error:
$path = exec("echo /usr/bin 1>&2");
The EXACT SAME output on sdtout() does NOT cause G3 to throw an error:
$path = exec("echo /usr/bin");
A quick PHP experiment that should just print the results of exec() from stdout() vs stderr() shows that the stderr() result just, kinda, evaporates. Some Googling tells me this is a pretty well-known phenomena. What I can't seem to find is any kind of correlation between this phenomena and a dropped MySQL connection.
What I do know is that if I fill $path with any value (or with no value, $path = "";, though I haven't tried with a null value) then the check works, the vars get created, and things proceed as expected. If $path is allowed to be filled with the output of an exec() that receives stderr() then things break.
This leads me to the output from which to stderr() doesn't need to be thrown away. Everything works as expected if it's simply rolled into stdout() with:
$path = exec("which gm 2>&1");
G3, just a few lines farther down, will check $path to make sure it holds a valid path, so this seems a legitimate way to work around this problem.
PHP bug 41874 (http://bugs.php.net/41874) is described as somehow impacting how stdout() and stderr() are treated by exec, but the PHP bug database is being non-responsive right now. I can't see any details on this.
@Raimo: where does your ImageMagick binary live? I'll add that to the list of directories that we scan.
We have ImageMagick at /usr/bin.
The IM detecting was with the help on exec():
// ImageMagick
$path = exec("which convert");
but it would be good to have a manual entry option.
nivekiam
Joined: 2002-12-10
Posts: 16503
Posted: Mon, 2010-08-09 15:05
@Raimo, You mean like under Admin > Settings > Advanced
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
antscran
Joined: 2008-03-04
Posts: 9
Posted: Mon, 2010-08-09 17:19
Hi,
Installed Gallery 3 RC2 over the weekend have to say looks great so thanks for all the hardwork!
I have been running it mainly on IE8 and Chrome5 it has come up with a few errors, also caused IE8 to lockup as seemed to stall. Now this could be down to my laptop which tends to overheat or my playing around installing modules, themes and generally messing about with it. I also noticed when uploading say 8 images the last one would sometimes stall on 100% and not complete even after leaving it for 5 minutes, it had uploaded correctly though just not completed.
Not sure how much use this will be but have attached the log file, I am suing HostGator who have been very helpful!
antscran,
Please start a new thread with your issues. It is hard to trck issue in thread that is 3 pages long.
@colors: a theme roller is planned and is in development.
Hello. just have tried to use Gallery 3 on Windows Server with PHP 5.2.13 on ISS 7.5 on subdomain in folder(not root). I have no problems while instalation process. In general it works, but some problem still exist:
* logout from gallery doesn't display home page. It display continue_url as "continue_url=http%3A%2F%2FTest.MyServer.comindex.php%2F". There are no slash! I think it must be like this "continue_url=http%3A%2F%2FTest.MyServer.com/index.php"? But it also tell "Dang... Something went wrong!".
* go back to site from admin panel cause same error - in url string of brouser i see "http://Test.MyServer.com/index.php/". It's also cause error.
Thanks.
floridave
Joined: 2003-12-22
Posts: 25961
Posted: Tue, 2010-08-10 14:43
Windows is not a supported platform.
The community might help you out if you start a new thread.
G3 works best on 2008 or 2008 R2. Use Web Install from iis.net to install php and modrewrite and you are good to go. End of story. You have an INCORRECT configuration. I think it's your web.config file or PHP settings. Uninstall PHP and reboot. Goto IIS.NET installed web install... Select php and modrewrite, reboot. Done.
nivekiam
Joined: 2002-12-10
Posts: 16503
Posted: Tue, 2010-08-10 15:13
Ranger187, Windows right now is only supported by you and you alone. You are the only person who has put forth effort to figure out what needs to be done. If you could create docs to help other people and put them on the Codex that would be great! http://codex.gallery2.org/
Nobody else, no developer, no support person, nobody has stepped up to the plate.
If you could help this guy that would be great: http://gallery.menalto.com/node/97219
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Ranger187
Joined: 2005-12-02
Posts: 199
Posted: Tue, 2010-08-10 15:17
Niv..... I can do that shortly. I just got back from Iraq but I can build a vmware box and document it for people.... Gimme some time.
Thanks. I already read that doc, created an account but didn't see any "create"... Maybe it's Firefox... Stupid 64bit beta. LOL
Thanks for making that page..... I gotta copy the old G2 doc into it and edit... You rock. ;)
JM|Tomi
Joined: 2004-10-11
Posts: 54
Posted: Fri, 2010-08-13 08:46
Hi there,
Guys, can you tell me an expected release date of g3 final? Or is it too early to talk about it?
Thanks,
JM|Tomi
luben
Joined: 2008-01-18
Posts: 5
Posted: Fri, 2010-08-13 09:42
Hi Guys,
Gallery 2 was able to automatically create a user album upon user creation & to set up the login in such a way that the user was automatically redirected to their album. Is this no longer possible in Gallery 3?
What I want to do is use Gallery 3 to show my wedding photography clients the photos from their wedding and get them to select the ones they want to purchase by deleting the ones they don't want. Gallery 2 could do all of that, but I can't seem to find a way to create the user album and add photos to it in Gallery 3 RC2.
Thanks in advance for your help.
Luben
JM|Tomi
Joined: 2004-10-11
Posts: 54
Posted: Fri, 2010-08-13 12:25
Hi all,
In G2 I used the 'hidden item' plug-in to hide the album from 'listing' but if the user knows the direct link, he/she was able to view it.
Is there any module or something that can provide a similar function in G3?
G3 also doesn't have as fine grained permissions as G2, so if you want to restrict access to these albums, right now you'd have to create a group, for each album or set of albums, put users in the group and assign permissions to the group.
For what you want, I'd probably stick with G2 and watch features and functionality of G3 progress...
@JM|Tomi, no hidden album feature yet.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
luben
Joined: 2008-01-18
Posts: 5
Posted: Fri, 2010-08-13 13:51
Thanks a lot for taking the time to answer my post nivekiam.
I know how busy you guys are with the pre-launch work on G3. I'll stick with G2 for the time being and will migrate when these features become available in G3.
Keep up the good work.
Luben
dhyde79
Joined: 2010-08-14
Posts: 1
Posted: Sat, 2010-08-14 07:02
well.....I thought my bug was dealing with the user_home module because I get a nice long crash message, but....BRAND NEW installation, added a theme and that's it, enabled recaptcha module and set it up, and now, if I try to add an album (with no user_home module enabled) I get the error in the attached screen capture....
tried it using opera and safari on OSX 10.6.4, hosting via lunarpages, can get specifics on the server config if needed..... I've got previous versions of gallery working fine on other sites on the same hosting account though....
Hello. Ranger187, i just setup modrewrite. It's looks to work. But one feature exist. When im logout from site it logout ok, but redirect to page "http://server.com/index.php/". The last slash is obvion and server get Error 404. Can I confure it in index.php?
Hello. Ranger187, i just setup modrewrite. It's looks to work. But one feature exist. When im logout from site it logout ok, but redirect to page "http://server.com/index.php/". The last slash is obvion and server get Error 404. Can I confure it in index.php?
Thanks.
User143, I need more info. Can you create a NEW thread, link me to it and I'll go from there.
Provide as much info. Windows version, 32/64bit, Apache / IIS...... Ya get the idea.........
Posts: 45
Is it possible to upload images directly from Picassa? (Would be nice!)
Amazing World - full of unexpected surprises!
Posts: 199
You mean import. That would be more like a plugin. ;)
Posts: 16503
Press Enter on the keyboard
Just
like
I'm
doing
now
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 53
Feedback after initial install of missing Graphics toolkit was misleading.
My environment:
Sun Web Server 7
PHP 5.3.2 (FastCGI)
MySQL 5.0.75
Centos 5.3
After performing the initial install/configuration clicking the "Use Gallery" link sent me to a page that threw an error:
"error: Database_Exception [ 44 ]: #2006: MySQL server has gone away [ SHOW COLUMNS FROM `items` ]"
This caused me to go down a rat-hole of verifying system requirements, etc. I was eventually able to confirm that all the required PHP extensions were enabled and functioning, that MySQL was working fine (all the other MySQL/PHP driven apps on my site were still functioning just fine), etc.
After much digging I found the Gallery3 var/logs/ directory (it would be handy if the errors page pointed to this directory for G3 related errors logs). A look at the log file showed the error above, but also showed it immediately preceded with:
"error: load_user Exception: #2006: MySQL server has gone away [ SHOW COLUMNS FROM `vars` ]"
This error was not mentioned in the error page being thrown to the browser, but ultimately that didn't matter. It was also not the root of the problem.
After exhausting all apparent possible failure causes I used strace (with -ttt for microsecond time stamps) to see what interaction PHP and MySQL were having. I was able to see the connection get opened (FD 2), authentication happen, and several SQL commands and responses exchanged. Then, out of nowhere, I see this text written to FD 2:
18085 1281206332.496541 write(2, "which: no gm in (/export/WS7/bin:/export/WS7/lib:/bin:/usr/kerberos/sbin:/usr/kerberos/bin: /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/usr/local/bin:/opt/local/bin:/opt/bin)\n", 191) = 191
Shortly after that I see:
17442 1281206332.510898 read(2, "", 8192) = 0
17442 1281206332.510948 shutdown(2, 2 /* send and receive */) = -1 ENOTCONN (Transport endpoint is not connected)
17442 1281206332.510990 close(2) = 0
What APPEARS to have happened is that Gallery3 tried to find gm using which, was unable to find it, and spewed an error about that to the open MySQL socket. The MySQL server understandably was unhappy about this and dropped the socket.
After hunting down a copy of GraphicsMagick for Centos (not as easy as it sounds) and installing it the error immediately went away. Gallery3 is now working as expected.
So - G3 RC2 broke when GraphicsMagick was not installed, and the errors returned were not indicative of the core cause.
Posts: 53
Gallery2_Import fails when used with PHP 5.3.x
When attempting to use the Gallery2_Import module with PHP 5.3.x to migrate from Gallery2, this error is returned after specifying the path to embed.php:
ErrorException [ Deprecated ]: Assigning the return value of new by reference is deprecated
DOCROOT/var/modules/g2_import/a4cb62b7cd501da0c07d98078bf906ec/bootstrap.inc[ 44 ]
39 * the constructor registers a shutdown function and ties it to the instance in
40 * the constructor. This global should be the only one that Gallery requires.
41 * Everything else should be inside it so that we do not pollute the namespace
42 * (especially important when we're embedded inside another application).
43 */
44 $gallery =& new G2_Gallery();
45 $GLOBALS['gallery'] =& $gallery;
46
47 if (!defined('GALLERY_CONFIG_DIR')) {
48 define('GALLERY_CONFIG_DIR', '/mnt/home/httpd/photos/gallery2');
49 }
From what I can gather this method ( =& ) of assigning a return value by reference stopped working with the release of PHP 5.3.0.
Posts: 7985
@dzm: thanks for the detailed analysis. The write on FD 2 is happening for a different process (18085) than the subsequent read (17442). I'm dubious that those are shared file descriptors; that would be a pretty egregious problem. However, I don't doubt that there's some connection, I'm just not sure what it might be. Either way, I'm not sure what we can do about it :-/
For the G2 import issue; this problem should be breaking your G2 as well. Upgrade to Gallery 2.3.1, it supports PHP 5.3.x properly then your import should work properly.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 53
Ahh! You're right bharat! I hadn't noticed the change in PHP PID. Interesting. Regardless, that "no gm in ..." error is not in any of my log files, so I'm not positive where it got written out to on FD2, AND immediately following that error MySQL dropped the connection. Installing GraphicMagick made that behavior go away.
Aaaand. Good call on the G2 problem. Digging around in the admin console for a while I was able to find: Gallery version = 2.3 core 1.3.0
I'll update to 2.3.1 and see if the problem persists.
Thanks!
Edit:
Looking through the strace output, 17442 is the parent of 18085. 1805 is created here:
17442 1281206332.448925 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7793928) = 18085
18085 immediately dupes its FD4 to FD1 and closes FD4, becomes an sh process, and then tries to find (with which of all things) gm:
18085 1281206332.459995 dup2(4, 1) = 1
18085 1281206332.460036 close(4) = 0
18085 1281206332.460083 execve("/bin/sh", ["sh", "-c", "which gm"], [/* 4 vars */]) = 0
There's a whole lot of standard library loading on FD3, then we get our error on FD2 (stderr()) from which:
18085 1281206332.495746 stat64("/export/WS7/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.495805 stat64("/export/WS7/lib/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.495862 stat64("/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.495912 stat64("/usr/kerberos/sbin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.495969 stat64("/usr/kerberos/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496025 stat64("/usr/local/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496080 stat64("/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496130 stat64("/usr/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496182 stat64("/usr/X11R6/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496244 stat64("/sbin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496296 stat64("/usr/sbin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496350 stat64("/usr/local/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496405 stat64("/opt/local/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496460 stat64("/opt/bin/gm", 0xbf973030) = -1 ENOENT (No such file or directory)
18085 1281206332.496541 write(2, "which: no gm in (/export/WS7/bin:/export/WS7/lib:/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin: /bin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/usr/local/bin:/opt/local/bin:/opt/bin)\n", 191) = 191
18085 1281206332.496788 exit_group(1) = ?
17442 1281206332.496984 <... read resumed> "", 8192) = 0
17442 1281206332.497009 --- SIGCHLD (Child exited) @ 0 (0) ---
As you see, 18085 then terminates itself.
At that point 17442 immediately locates var.php (after the stat64 hunt through the includes paths), reads a couple of vars, closes vars.php and does the same hunt for MY_Var_Model.php (and fails since that files seems not to exist), tries to read from FD2 and fails:
17442 1281206332.510839 poll([{fd=2, events=POLLIN|POLLPRI}], 1, 0) = 1 ([{fd=2, revents=POLLIN|POLLERR|POLLHUP}])
17442 1281206332.510898 read(2, "", 8192) = 0
17442 1281206332.510948 shutdown(2, 2 /* send and receive */) = -1 ENOTCONN (Transport endpoint is not connected)
17442 1281206332.510990 close(2) = 0
Just before the crazy dance with GraphicsMagick G3 did the exact same dance with ImageMagick (which is installed) and a child process, except rahter than use which to determine if IM is installed G3 instead executes convert -v. G3 (or the PHP ppid) is getting results from this search via the child's FD1 (stdout) instead of FD2 (stderr).
Is it possible that the child PID returning data over stderr is somehow causing G3 and/or PHP 5.3.x to take that input and relay it to its own FD2?
Regarding how to fix ... Beats me.
The only obvious thing I can think of is to do the tools check prior to the DB queries and allow the admin to "disable" not-found toolkits.
And more edit: You're right. Upgrading to G2.3.1 fixed the import problem.
Posts: 16503
I wonder if there's an issue with our detection of image toolkits on Solaris.
I know this guy had to specify the path in Advanced settings:
http://gallery.menalto.com/node/93328
So did this guy:
http://gallery.menalto.com/node/96037
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 53
Those problems seem to be with G3 not finding IM, though IM is actually installed. In my case GM was NOT installed and the G3 was/is coping with the failure in a really ugly way. I solved the problem by hunting down GraphicsMagick for Centos and installing it (not easy since there is no official RPM package for GM for Centos, and because G3 gave no indication that this was the problem).
Posts: 7985
Hrm. Hard to tell what's going on here. Either way, we're forking subprocs to find and use GM andIM so it's not surprising to see the subproc start up and check every possible location on your path to find the binary then shut down. When we do image toolkit detection, we also run "convert -v" to figure out what version of ImageMagick you have installed. We run "gm version" to find the same value for GraphicsMagick. But those subprocs should be fully isolated and shouldn't be able to stomp on your MySQL connection -- that'd have to be a flaw in PHP of some kind..
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 53
I still have the strace output if you want it. I don't know if it would shed any more light on things than the snippets here do.
Posts: 7985
Me neither, but I'm willing to take a look at it if you're willing to share
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 53
Private Message sent.
Posts: 7985
@dzm: got it. I don't see any connection there between the missing toolkit and the database connection going away. The only theory I have is that you have a very short idle timeout on your database connection and the various subproc calls are making the request take long enough (~1.1 seconds) that the connection goes away. That's pretty slim. I'm always in agreement that we could use some better error messages, but I'm not sure what we could add to make this problem better. Ideas welcome.
PS: I filed https://sourceforge.net/apps/trac/gallery/ticket/1275 and submitted a change to make the error page provide more details and starting points for debugging. Thanks for the reminder about that!
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 53
I spent a lot of time chasing the low-timeout theory. Here's every MySQL variable that involves the word "timeout":
connect timeout 10
delayed insert timeout 300
innodb lock wait timeout 50
innodb rollback on timeout OFF
interactive timeout 28,800
net read timeout 30
net write timeout 60
slave net timeout 3,600
table lock wait timeout 50
wait timeout 600
I see nothing at all that would be bothered by a ~1.1 second pause between queries. It's also worth noting that this MySQL and PHP config is driving without any problems two phpBB, three Drupal, and three G2 instances. They're all working fine. And this problem (the error page being thrown after the "Install successful, start using G3" page) was unchanged regardless of tuning I did to PHP and/or MySQL, but went away entirely once I installed GraphicsMagick.
I don't know what else I can contribute beyond this, but I'm certainly willing to prod things and return results if you'd like me to.
Just for fun I also just tried intentionally "breaking" GM by moving /usr/bin/gm to /usr/bin/gm-bkp. G3 continues to work as expected. So it seems that the problem is present ONLY immediately following installation while the vars are being gathered for storage into the DB. It's not something that continues to be broken post-installation if the toolkit disappears.
Also, new feedback: During a long G2 import the "thermometer" page needs to remain open. Unfortunately the JavaScript driving this page eventually causes Firefox 4b2 to complain that a "script has been running for a long time and may be hurting performance" (or something along those lines). Once the admin clears away the error the import must be "resumed" from the Maintenance page. It may be preferable to force the page holding the thermometer to do a reload of the entire page (including the JavaScript) from the server every five minutes or so in order to prevent the JavaScript engine from getting grumpy, and to force any accumulated cruft to be flushed (a pretty brute force garbage collection).
Posts: 7985
From your symptoms, this is definitely happening when we do the post-install call to graphics::detect_toolkits(). We could try avoiding using "which" to see if we can detect the binary by hand by parsing your PATH. Sigh. The point in supporting a standard platform is so that we don't have to deal with these kinds of issues, though. I'm going write this issue off as a problem with Sun Web Server 7 until we can reproduce it on Apache 2.
I'll try installing Firefox 4b2 and see if I can reproduce that problem -- it definitely shouldn't be happening so we might have to massage the JS a bit.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 53
I also notice that the latter half of the import, the "importing tags" segment, seems really prone to stalling. The GUI gives no indication of the stall though. The Thermometer continues to sit on top of the window/tab, but no progress gets made. The only way I notice that work has stopped is that the progress number stops changing and the system load drops.
On the server side I notice that the tag importing seems to work PHP and MySQL really hard. System load on an Amazon EC21 "small" instance floats at around 2.0 (1min) during the image importing, and then at around 4-5(1min) during the tag import with PHP using ~20-25% of CPU and MySQL running at ~8-10% of CPU. I don't pretend to know what work is happening behing the scenes to copy the tags over, this seems like it's working awfully hard to do it.
Re the GM problem ... I'm not sure I understand how Sun Web Server 7 could be the culprit. The parentage of the processes is:
WS7 -> FCGI_Stub -> PHP -> "which gm"
In theory WS7 and its FCGI stub process should only be passing a FCGI request to the children and, when processing by PHP is complete, receiving a result. It's possible that WS7 is passing some environment variables to the children that are different than would get passed by Apache (or ligHTTPd, or NGinX, or IIS), but I'd be surprised if this were the cause.
I'll spin up a vanilla Centos 5.3 with Apache2 and see if I can reproduce the problem.
Posts: 53
Alrighty - It seems that there's a really easy fix to this. Just throw away stderr() from the which commands. Changing the which call from:
// GraphicsMagick
$path = exec("which gm");
to
// GraphicsMagick
$path = exec("which gm 2>/dev/null");
made the failure go away for me. Reverting it made the problem come back.
I'm sending you a PM with the URL for a two-line patch that makes this change for the IM and GM which lookups. The patch is yours if you want it.
Posts: 7985
I'm going to wait on doing that patch until we have a repeatable case of this on Apache 2, since we're in release candidate stages and I don't understand exactly why that fixes the problem and don't want to damage the experience for other users.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 53
Understood.
I've also done some more experimentation. This seems 100% a problem (bug?) in PHP 5.3.2's handling of stderr() results from an exec().
ANY output (even valid output) from the exec() child on stderr makes G3 throw that error:
$path = exec("echo /usr/bin 1>&2");
The EXACT SAME output on sdtout() does NOT cause G3 to throw an error:
$path = exec("echo /usr/bin");
A quick PHP experiment that should just print the results of exec() from stdout() vs stderr() shows that the stderr() result just, kinda, evaporates. Some Googling tells me this is a pretty well-known phenomena. What I can't seem to find is any kind of correlation between this phenomena and a dropped MySQL connection.
What I do know is that if I fill $path with any value (or with no value, $path = "";, though I haven't tried with a null value) then the check works, the vars get created, and things proceed as expected. If $path is allowed to be filled with the output of an exec() that receives stderr() then things break.
This leads me to the output from which to stderr() doesn't need to be thrown away. Everything works as expected if it's simply rolled into stdout() with:
$path = exec("which gm 2>&1");
G3, just a few lines farther down, will check $path to make sure it holds a valid path, so this seems a legitimate way to work around this problem.
PHP bug 41874 (http://bugs.php.net/41874) is described as somehow impacting how stdout() and stderr() are treated by exec, but the PHP bug database is being non-responsive right now. I can't see any details on this.
Posts: 7985
Seems reasonable. I've created https://sourceforge.net/apps/trac/gallery/ticket/1277 for us to track this issue and fix it in 3.1.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 2
We have ImageMagick at /usr/bin.
The IM detecting was with the help on exec():
// ImageMagick
$path = exec("which convert");
but it would be good to have a manual entry option.
Posts: 16503
@Raimo, You mean like under Admin > Settings > Advanced
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 9
Hi,
Installed Gallery 3 RC2 over the weekend have to say looks great so thanks for all the hardwork!
I have been running it mainly on IE8 and Chrome5 it has come up with a few errors, also caused IE8 to lockup as seemed to stall. Now this could be down to my laptop which tends to overheat or my playing around installing modules, themes and generally messing about with it. I also noticed when uploading say 8 images the last one would sometimes stall on 100% and not complete even after leaving it for 5 minutes, it had uploaded correctly though just not completed.
Not sure how much use this will be but have attached the log file, I am suing HostGator who have been very helpful!
http://www.dslr-images.com/Gallery/
I used to use Gallery2 and seem to remember the themes being much more customisable i.e. colours etc, is this planned for Gallery3?
Thanks again,
Ant
Posts: 25961
antscran,
Please start a new thread with your issues. It is hard to trck issue in thread that is 3 pages long.
@colors: a theme roller is planned and is in development.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 6
Hello. just have tried to use Gallery 3 on Windows Server with PHP 5.2.13 on ISS 7.5 on subdomain in folder(not root). I have no problems while instalation process. In general it works, but some problem still exist:
* logout from gallery doesn't display home page. It display continue_url as "continue_url=http%3A%2F%2FTest.MyServer.comindex.php%2F". There are no slash! I think it must be like this "continue_url=http%3A%2F%2FTest.MyServer.com/index.php"? But it also tell "Dang... Something went wrong!".
* go back to site from admin panel cause same error - in url string of brouser i see "http://Test.MyServer.com/index.php/". It's also cause error.
Thanks.
Posts: 25961
Windows is not a supported platform.
The community might help you out if you start a new thread.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 199
I'm getting so sick of this. ;)
YES IT IS SUPPORTED. ;)
User143
G3 works best on 2008 or 2008 R2. Use Web Install from iis.net to install php and modrewrite and you are good to go. End of story. You have an INCORRECT configuration. I think it's your web.config file or PHP settings. Uninstall PHP and reboot. Goto IIS.NET installed web install... Select php and modrewrite, reboot. Done.
Posts: 16503
Ranger187, Windows right now is only supported by you and you alone. You are the only person who has put forth effort to figure out what needs to be done. If you could create docs to help other people and put them on the Codex that would be great!
http://codex.gallery2.org/
Nobody else, no developer, no support person, nobody has stepped up to the plate.
If you could help this guy that would be great:
http://gallery.menalto.com/node/97219
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 199
Niv..... I can do that shortly. I just got back from Iraq but I can build a vmware box and document it for people.... Gimme some time.
Posts: 7985
And Ranger187 -- we definitely appreciate that you support our Windows brethren!
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 199
Bharat, what you really mean: "I dislike Windows so much" ;)
I'm making a vmware session now..... I'll document the process.....
Posts: 16503
Ranger187, where did you see that? No results here (meaning this thread hasn't been crawled since your comment yet, give it a couple of hours).
http://www.google.com/search?domains=gallery.menalto.com&sitesearch=gallery.menalto.com&q=%22I+dislike+Windows+so+much%22&op=Search+with+Google
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 199
*GIGGLES*!!!
I'm joking brotha.... LOL
Posts: 199
Maybe it's the jetlag or lack of sleep, but how do I create a doc for: Gallery3:Installation on Windows Server 2008 and IIS7?
Posts: 16503
First you'll need to create an account and log into the Codex (upper-right corner)
http://codex.gallery2.org/
Then just go to the URL where you want the page and click create to get started. I created a holding page for you:
http://codex.gallery2.org/Gallery3:Installation_on_Windows_Server_2008_and_IIS7
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 199
Thanks. I already read that doc, created an account but didn't see any "create"... Maybe it's Firefox... Stupid 64bit beta. LOL
Thanks for making that page..... I gotta copy the old G2 doc into it and edit... You rock. ;)
Posts: 54
Hi there,
Guys, can you tell me an expected release date of g3 final? Or is it too early to talk about it?
Thanks,
JM|Tomi
Posts: 5
Hi Guys,
Gallery 2 was able to automatically create a user album upon user creation & to set up the login in such a way that the user was automatically redirected to their album. Is this no longer possible in Gallery 3?
What I want to do is use Gallery 3 to show my wedding photography clients the photos from their wedding and get them to select the ones they want to purchase by deleting the ones they don't want. Gallery 2 could do all of that, but I can't seem to find a way to create the user album and add photos to it in Gallery 3 RC2.
Thanks in advance for your help.
Luben
Posts: 54
Hi all,
In G2 I used the 'hidden item' plug-in to hide the album from 'listing' but if the user knows the direct link, he/she was able to view it.
Is there any module or something that can provide a similar function in G3?
Thanks,
JM|Tomi
Posts: 16503
@luben, About user ablum, close but not completely yet.
http://codex.gallery2.org/Category:Gallery_3:Modules
There's this module, but you'd have to manually create the albums, then set the user's "home" album.
http://codex.gallery2.org/Gallery3:Modules:user_homes
G3 also doesn't have as fine grained permissions as G2, so if you want to restrict access to these albums, right now you'd have to create a group, for each album or set of albums, put users in the group and assign permissions to the group.
For what you want, I'd probably stick with G2 and watch features and functionality of G3 progress...
@JM|Tomi, no hidden album feature yet.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 5
Thanks a lot for taking the time to answer my post nivekiam.
I know how busy you guys are with the pre-launch work on G3. I'll stick with G2 for the time being and will migrate when these features become available in G3.
Keep up the good work.
Luben
Posts: 1
well.....I thought my bug was dealing with the user_home module because I get a nice long crash message, but....BRAND NEW installation, added a theme and that's it, enabled recaptcha module and set it up, and now, if I try to add an album (with no user_home module enabled) I get the error in the attached screen capture....
tried it using opera and safari on OSX 10.6.4, hosting via lunarpages, can get specifics on the server config if needed..... I've got previous versions of gallery working fine on other sites on the same hosting account though....
Posts: 6
Hello. Ranger187, i just setup modrewrite. It's looks to work. But one feature exist. When im logout from site it logout ok, but redirect to page "http://server.com/index.php/". The last slash is obvion and server get Error 404. Can I confure it in index.php?
Thanks.
Posts: 25961
dhyde79,
The issue you are seeing has been fixed in a recent GIT version. Please start over with an experimental version:
http://codex.gallery2.org/Gallery3:Upgrading
Get the latest experimental release
Start a new thread if you still have issues and report you Apache version.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 199
User143, I need more info. Can you create a NEW thread, link me to it and I'll go from there.
Provide as much info. Windows version, 32/64bit, Apache / IIS...... Ya get the idea.........
Thanks!
Posts: 199
Just an update......
I have been slowly working on: http://codex.gallery2.org/Gallery3:Installation_on_Windows_Server_2008_and_IIS7
When I have spare time I update it... From the top downward. I figure in another week or so I'll have it done.
Posts: 21
Auto rotation would be VERY nice.
Thanks for all your work on this release.
-- Dick
Posts: 25961
@auto rotation some discussion and module development:
http://gallery.menalto.com/node/97270
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 3
I miss in gallery3 the password option for photoalbum. (only a passwordlogin for a album, no user auth)