ioFTPD v7.3.3 Released (Beta) - Page 3

Zer0Racer · 04-07-2010, 11:39 AM

In v7.3.2 "site symlink" works again.

No change for project-zs though. All files disappear even if the script exit with no error.

And the symlink created by the script is not resolved, even if site chattr +l "link" on the dir/link shows a valid target.

Yil · 04-07-2010, 12:11 PM

pion: Can you check the logfile for the "System detected loader lock compromised! Terminating!" message? And just to double check, the .ini file has the new option enabled and you can see the ioFTPD-Watch.exe running when you start the server?

Yil · 04-07-2010, 01:04 PM

Zero: I've tried a bunch of symlinks and everything appears to be working fine. I even found that relative symlink bug when I first looked at it. If you view the raw link target via "site chattr +l <dir>" like you did in your example can you CWD to that and have it work? Does restarting the server make the link work? If all that fails, send me the .ioFTPD file from the link directory and I'll check to see if it looks OK. I'm just not sure how the zipscript creates the link, i.e. via a !vfs style command which means the EXEC module, via the shared memory interface, or by manipulating the .ioFTPD file itself... If the last then it might be a stale cache issue which restarting would fix but wouldn't be an issue if the zipscript wasn't crashing and told the server to reload the dir's data... Just a thought...

Zer0Racer · 04-07-2010, 02:17 PM

Yil: Restarting ioFTPD didn't work and I can't CWD the symlink/dir. My flashfxp just reports that the dir/file doesn't exist (since ioFTPD tries to CWD into the symlink dir).

I have sent the .ioFTPD file to you. I think the zs uses shared memory.

Zer0Racer · 04-07-2010, 02:31 PM

Reverting to v6.9.3 (replacing ioFTPD.exe into the same config and adding php4ts.dll to /ioFTPD/system) and the zs works and no files disappear. Then I tried something as "old" as v7.0.3 and the same thing happens as in v7.3.2. So one of the changes from v7.0.0 or something brakes the compatibility with project-zs (at least). I haven't tried the zr-tools exes (zr-ban.exe etc.) yet.

Yil · 04-07-2010, 02:54 PM

Code:

v7.3.3 Release Notes:

1) Files in \System:
   Changed : ioFTPD.[exe,pdb] - Version 7.3.3.0.


*** Bug Fixes

2) Fixed a race condition during startup where the scheduler subsystem was
   started before the services subsystem.  This could result in the &reset
   scheduler event (which updates defined services) running before they have
   been configured for the first time.  I believe this is the cause of the
   server starting up but not accepting any connections at all.

3) Fixed a bug where '\r' wasn't being removed from the end of a line when
   processing ! redir commands issued in the EXEC module.

4) Fixed a bug with the !detach feature in the EXEC module where I flipped
   the meaning of the integer argument and was recording an error instead
   of success.

Yil · 04-07-2010, 02:56 PM

Some good stuff in this one... I think I fixed the server starting up but not responding bug and I think zero's problems with the EXEC module should be fixed.

Link: ioFTPD-v7.3.3.zip

Yil · 04-07-2010, 03:03 PM

zero: I should mention it because it's not obvious, but the problem with the symlinks turned out to be a creation problem. When the \r wasn't being removed from the end of the ! line in the EXEC module the !vfs:chattr function got a double quoted string with the \r on the end so it failed to remove both the \r and the double quotes so the link was wrong. I should have noticed the target from the site chattr +l command having quotes around it, but just thought that was the way it should be displayed... It's fixed now but the existing links will still be wrong (though with it deleting all files on upload it's unlikely you had a lot of them).

Zer0Racer · 04-07-2010, 03:06 PM

Yil, very nice! Now in ioFTPD v7.3.3 project-zs works just as it is supposed to and the zs-created symlinks work too. Solid work! Thanks!

Zer0Racer · 04-07-2010, 03:10 PM

Quote:

Originally Posted by Yil

zero: I should mention it because it's not obvious, but the problem with the symlinks turned out to be a creation problem. When the \r wasn't being removed from the end of the ! line in the EXEC module the !vfs:chattr function got a double quoted string with the \r on the end so it failed to remove both the \r and the double quotes so the link was wrong. I should have noticed the target from the site chattr +l command having quotes around it, but just thought that was the way it should be displayed... It's fixed now but the existing links will still be wrong (though with it deleting all files on upload it's unlikely you had a lot of them).

Okay. But the correct way of creating a symlink "the old way" is still like this (including the quotes)?

Code:

site chattr +l "dir" "virtual target"

Edit: Btw, creation problem you say. Does that mean there is a bug in the zipscript on symlink creation or just the EXEC module in ioFTPD?

pion · 04-07-2010, 04:50 PM

Nothing in log, and ioFTPD-Watch.exe is running using 996K ram. I did however notice something I haven't seen before when examining event prior to hangup:

sitebot only reported newdir creation on three different releases, as if zipscript stopped working entirely. Three minutes earlier it put out full output with a working zs. Type of files was excactly the same in both before and after. In addition to this, when examining logs, I noticed that io had stopped accepting new connections 20 MINUTES before. (I noticed this due to a user hammering every 20s but getting login refused in log) This particular user had been hammering for a full hour already, and is also the last entry in ioftpd.log so it's unlikely that he stopped hammering at that particular point.

This leads me to believe that already connected users aren't very much affected by the lockup bug, and that it is possibly connected with the execution of zipscript.

Using ioFTPD 7.3.2 - dZSbot - ioninja customized PZS-NG 21.1

Yil · 04-07-2010, 06:30 PM

zero: Nothing changed with how you use site chattr, or site symlink. The double quotes are indeed required if the name contains spaces so it's a good idea to always use them. You can check out "site help chattr" for details. The issue was in the EXEC module entirely and the way it improperly handled the arguments to !vfs:chattr which failed to remove the double quotes because of the extra \r at the end. This means that the link was stored as "/link"\r (the quotes are part of the name!) instead of just /link and therefore wouldn't resolve...

pion: Keep an eye out to see if you see that behavior again. If new connections are not being accepted, try to see if you can get directory listings via LIST (not STAT!) or alternatively transfer any files. If so then it's just something weird going on with users logging in. Try a site rehash to see if that helps, and also check the logfiles. You can also try "site crashnow" if you are still logged in to see if that works and send me the dumps.

pion · 04-08-2010, 12:10 AM

I don't really have any way of detecting the lockup bug until I am no longer able to connect. Is there a way to trigger crashnow other than actually being logged in?

Yil · 04-08-2010, 01:26 AM

pion: No, sorry. However there is something you can try that might help in your situation because I don't think you have the dreaded "lockup bug" but rather something that just stops accepting connections.

First in the .ini file copy the [FTP_Service] section and call the new one [FTP_Service2]. Change the "Port =" line to use a different port number, and then under [Network] change

Active_Services = FTP_Service FTP_Service2

You will now have a server that listens and accepts connections on 2 different ports! If the first gets locked up, try connecting to the second to see if that still works...

o_dog · 04-08-2010, 04:07 AM

it's not only me it seems that have problem with the 550 - transfer bla bla bla thing. Seems others have it too, this is kinda important.. The log says nothing since it doesn't crash, timeout or anything like that, it just seems to cling to a connection it likes very much. Can't really generate a crashlog for ya, atleast not right now.