On Tuesday 09 March 2010 10:11:24 Christian Funder Sommerlund wrote: > Hi all > > It seems like there is a bit of confusion about the Windows Installer's > "Did not respond to signal" errors, so I'd like to explain what it > means, and hopefully clear up any misunderstandings. > > --- What happens? --- > > The error is thrown in a messagebox to the user when the Freenet Starter > (the platform glue that handles UAC elevation and sends the start signal > to the service) detects that the wrapper fails during startup > (technically: the service status goes from STARTING -> STOPPED instead > of STARTING -> RUNNING). > > This doesn't really have anything to do with the installer, as all of > these failures happen in the wrapper. The installer is, however, nice > enough to tell the user that the wrapper startup failed. In the next > version, I will clarify the error messsage and ask the user to look at > wrapper.log for more information instead. > > --- So why does the wrapper fail? --- > > If wrapper.log contains only the line: > > STATUS | wrapper | 2009/10/30 17:16:22 | Freenet background service > installed. > > ... it means that the wrapper (when it had admin permissions) succeeded > in installing the service. The lack of any more lines suggests that the > wrapper (and thereby the LocalService account) is missing read/write > permissions to the installation folder. We explicitly give this out > during installation, so this shouldn't happen. However, various sources > suggest that this sometimes fails, but nobody has been able to reproduce > or help me debug it. I'm constantly trying to work with reporters, but > they have a tendency to disappear just as quickly as they arrive.
More than once we have seen this error happen when LocalService *did* have permissions, e.g. on the Win7 system I tried it on the first time (the second time it worked). I don't think it is (always) a permissions problem. > > Besides the case mentioned above, every other report seems to be random > stuff. I've seen: > > - One error about the user missing read access to the Java files (which > you obviously should have if you want to run Java software) > > - One about the node being too slow to start (and thereby being killed > by the Windows service system) > > - One about a user manually moving the datastore but not giving the > service permissions to write to the new location > > - One case where reinstallation fixed the issue > > - One where the user's system was so messed up that he couldn't even > access the Windows event viewer > > - One where the LocalService account has lost parts of its registry > access to normal Windows keys > > We could technically check for some of the above issues and warn the > user before installation, but I'm afraid that they will just keep coming > around in new flavors. If the user's system is messed up, anything can > happen really... > > Note that I cannot reproduce any of these myself. I've tried numerous > times on XP, Vista and Win7 machines (32 + 64 bit) without any luck. These failure reports are so common that I suspect a *significant* fraction of Windows users who try Freenet run into them. We need a fix. Any fix. The obvious fix is to give up on installing Freenet as a service and to (at least by default) install it as something that executes on login, as the same user that installed it. This will cost us a little time, and won't work well on windows servers, but it should avoid most permissions and similar issues. > > --- Reporting the bug --- > > I appreciate that people are submitting failures to > https://bugs.freenetproject.org/view.php?id=3624 - but I cannot do much > about them without the proper information. Please see > http://new-wiki.freenetproject.org/Installing_on_Windows#Service_did_not_respond_to_signal. > > --- The old installer --- > > I have no idea why some (toad!?!) are recommending people to use the old > Java installer, but I'd like to seriously recommend you *not* to do so. > > It will *not* work on Vista and Win7 because it does not handle UAC > elevation in any way. It might work on XP, but has several big privacy > flaws (it will leave lots of traces that the uninstaller won't remove) > and uses the clumsy custom freenet user, besides not having been > maintained for years. The bug we are talking about here does exist on XP, there have been several such reports. And if Freenet consistently fails to install with the new installer, I don't see the harm in telling the user to use the old installer. > > Please understand that this is nothing personal against the previous > maintainer(s). I'm only concerned about not messing up our users' systems.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/devl
