Quote from MaKaKaZo :

Could that be caused because of compiling the sources yourself? I mean, is it possible that the precompiled binaries available for several distributions didn't have this problem?

Never had the issue before, and I refuse to use debs, etc. because of the ridiculous dependancies on X.

Yes the newer versions not run with wineconsole. It is a bug in wine, when it is run without gfx.

use "nohup wine LFS.exe /cfg=server.cfg" in a screen session.
This will work.

Best Regards Alex


##
My testserver is running.

But running newer versions of wine will require an x-server ... at least a dummy, if i am correct.

Indeed. Hence the requirement for a native server >:|

Tried 0.9.39 myself ...also got this error ->
"fixme:curses:WCCURSES_GetEvents Ooch. somebody beat us"

Quote from yankman :

But running newer versions of wine will require an x-server ... at least a dummy, if i am correct.

What do you mean by a dummy? You must have an x-server running with all the CPU and mem usage that it means? Or can you have it somehow "disabled" so you can save all those resources?

Quote from the_angry_angel :

Indeed. Hence the requirement for a native server >:|

use "nohup wine LFS.exe /cfg=server.cfg" in a screen session.
This will work.

Mine complains about the lack of an X server and various dlls unfortunately.

Quite why it does this, as I compiled it without X support, I'll never know.

Suse? Debian?

Debian (not the packaged version).

I've rolled back to 0.9.32 fwiw.

Hmm, sorry i use a Suse rpm.

Quote from MaKaKaZo :

What do you mean by a dummy? You must have an x-server running with all the CPU and mem usage that it means? Or can you have it somehow "disabled" so you can save all those resources?

xvfb for instance ... it is a virtual x-server that need no display.
Also xvnc is possible which runs without a display but can be used with vnc clients.

But as long as I am not sure that the udp problem is fixed with 0.9.39, I will not install X just for testing

Ok looks like I found the console error.

In wine-0.9.39/programs/wineconsole/curses.c

enum init_return WCCURSES_InitBackend(struct inner_data* data)

ncurses is init with nodelay(stdscr, TRUE);

Which causes an instant return of static void WCCURSES_GetEvents(struct inner_data* data) together with the message "Ooch. somebody beat us"
cause there is no input waiting.

I change the nodelay to false, which causes a blocking call while waiting for input.
I compiled it and it seems to work.

If someone is interested in testing:
lfs://|FPR+%7C+Publicserver%23Test|0|S2|/

I guess it is still not perfect.
If I tried to start wineconsole via shell script and it is still producing errors.
However I used screen as a workarround.
The actual command I use in the script is now:

Of course with WINE, CFGFILE, PIDFILE defined somewhere before.

Works forme so far.

I would be nice if the server could some get some load:
FPR | Public#1 0.9.39
FPR | Public#2 0.9.39

My pal who is the one who sets the hosts up told me that running 0.9.39 'the old way' with

"nohup wine LFS.exe /cfg=server.cfg"

needed too much CPU to run (he showed me the graphs and it really does), so he used this instead:

"wine LFS.exe /cfg=setup.cfg >/dev/null & echo $! > lfs.pid &"

I don't know what ">/dev/null & echo $! > lfs.pid &" do, but he says that it works this way and is much cleaner.

We are going to test our servers these days and I'll report back.

PS: My pal doesn't write here himself because he knows no English, so I'm like his 'spokesperson'

That command effectively redirects all the output into a blackhole, which means it doesn't get output, and then echo $! records the process ID into lfs.pid (so you can kill it later), and then the & means that it should continue running in the background.

Yes it'll work, but its still producing all the errors unfortunately

Problem here was that even with no nohup (which just prevents the app from getting standard signals) the wgetch function of ncurses returned with ERR when starting wineconsole out of a script. This runs the mainloop over and over again as fast as ur cpu is. (->hi load)

If I started it directly from bash it worked out. I have not idea why, could be even a ncurses problem.

So I thought give wineconsole a stdin,stdout and stderr and everything is fine. Just what screen does. Only thing in my command is, it gets the process id of the detached screen rather than wineconsole itself. But if screen gets closed it closes the wineconsole process too.


PS: I wonder how ur pal does all these things w/o knowing just a bit english.

Quote from yankman :

PS: I wonder how ur pal does all these things w/o knowing just a bit english.

Because he lied to me, he actually knows technical english (referred to computers of course) and can read pretty well, yet he can't find the words to express himself.

Quote from the_angry_angel :

Yes it'll work, but its still producing all the errors unfortunately

If the debugging output is the problem try:
WINEDEBUG=-all wine LFS.exe

Also, as written here, you could use Xvfb X server, if X needed. Here is a script, that I use:

You can put screen/nohup around when it is started.

What can I say. I'm getting fussy in my old age - I don't want anything even half related to X near my systems any more. If that means that I can't run LFS servers for a while, then so be it.

Quote from the_angry_angel :

Yes it'll work, but its still producing all the errors unfortunately

Did u try to fix this issue in curses.c ?

Not yet, its on my list of things todo sometime this weekend

For convenience change line 986 in wine-0.9.39/programs/wineconsole/curses.c
from

to

My "Demo-mode" testserver at wine 9.39 runs since yesterday with 8-15 people load without guestproblem.

CPU load is 1-4%

Good News.
The wine 0.9.39 or 0.9.40 seems to run stable.