Closed emendelson closed 1 year ago
I don't know, I haven't seen anything like that on Linux and can't reproduce it on Windows 10.
Here are things to try:
sudo /opt/wp80/shbin10/wpexc -k
, then try running wp does it happen again?If it does, that would suggest it's something to do with the print server.
wsl -t Ubuntu
(Note: this will kill any wsl programs you have open), then try again does it also happen?If No, then it must be something Windows related - Windows Defender or something? 🤷♂️
If Yes... then an strace of what it's doing during the delay might help if you can get one!
I'll be away from my Windows machine until the middle of next week, so I can't test this until then. Just before I left, I tried the first suggestion (run wpexc -k
) and it didn't help, but I didn't have time to do more.
Question: do I get an strace by running strace wp -o filename
or is it more complicated than that? I had never heard of strace until I saw your message, so I'm a complete beginner at this.
Back to my Windows machine so was able to test again. I restarted Windows, launched Ubuntu and ran strace -o ~/trace.out wp
- and WP took a very long time to show its menu. Does this trace file give any clue to what might be happening?
EDIT: In a further test, wp seemed to need five minutes to start after the first reboot. I didn't time this exactly, but five minutes is close to the exact number.
Hmm, not really any clues in there. I think I need to be able to reproduce it so I can examine what it's doing with a debugger. It doesn't seem to happen on Windows 10 - which is what I usually use for development!
I'll try it on Windows 11 today.
I have Windows 10 on my home machine, but I won't be back there until December. Both systems that I have where I am now use Windows 11. One possibly relevant point: this may be a WSL-wide problem, not WP-specific. It takes xterm thirty seconds to start up the first time I try to run it after rebooting.
I had some time to sit down today and figure this out. This bug does affect real Linux too, if you try to start wp in the first 300 seconds or so after boot.
The problem is the printing components are trying to wait a few seconds for all the components to initialize, and they do this by continuously checking how many clock ticks have passed.
They do this with the times()
system call, which returns the number of clock ticks that have elapsed since "an arbitrary point in the past" (you're not supposed to depend on when that point is, because it can change between systems or UNIX types or versions). That's fine, but Linux chooses the point "(2^32/HZ) - 300 seconds before system boot time.", which means for the first ~300 seconds after boot it's a very large number.
This shouldn't matter, but wp incorrectly thinks this number is always less than INT_MIN
, which it isn't, so the timer doesn't elapse until it gets to 0, about 300 seconds after boot.
I think the solution is just add 300 seconds worth of ticks to the result? It's an ugly solution, but I think that should solve it. Let's try that and see if anything breaks.
Alright, let's try this. I'll use it for a few days and see if anything breaks.
If it looks good, I'll make a new release next week.
This is terrific. I'm traveling with an Apple Silicon Mac, and lima (sorta like WSL) doesn't really work well with WP (basically every keystroke produces an escape sequence instead of what you want) so I'll have to wait until I get back to my Windows machine, possibly Sunday but more likely Monday. Thank you for working this out!
Back at my Windows machine - and yes, with the previous release, by waiting 300 seconds after starting WSL and then running wp, there was no startup delay. The new release fixes this. Thank you!
Does anyone have any insight into this problem (or am I the only one who has it)?
When I first run wp after starting up WSL Ubuntu (after restarting Windows), it takes as long as ten full minutes for the splash screen (with "Please wait") to go away and the editing screen to appear. The second time wp starts up, it starts instantaneously, but not the first time.
I haven't seen this in real Linux (in VMware), only in WSL, but it's consistent in WSL.