Errors galore during apt-get dist-upgrade #1851
Comments
|
Hm... So, I have not tried to run PHP 7 under WSL, but I can comment about those particular warnings. The If I had to guess, I would guess that this is the issue that you are hitting: I believe nginx runs as a system service, and FPM also runs as a system service. So I suspect that neither is starting automatically. You'll probably have to do All of the rest of the errors are occurring when apt tries to rebuild your initramfs, a package used for the first stage of Linux's boot that contains the core kernel and hardware drivers. This happens if you get an update to your Linux kernel, such as during a dist-upgrade. On a real Linux system, those errors would be severe; they would probably result in an unbootable system. However, WSL doesn't boot :-) It doesn't use the initramfs at all. The dist-upgrade still tries to build an initramfs, but it's vestigial; you can ignore these failures. Aside: your problem may be that you're trying to use PHP 7 :-) The last time I tried (with either 7.0 or 7.1), I promptly hit a deterministic segfault in the core PHP interpreter which, after a few months, the PHP folks have apparently not yet had a chance to start looking into. Maybe my perspective is skewed. But to my thinking, trying to run a buggy language interpreter on top of a beta runtime environment is something that has some risk of ending badly :-) Though if you do get it working, please post back here; I'd be curious to hear your results! |
|
Also, one other aside: Microsoft has announced that the next Windows release, Windows 10 "Creators", will ship on April 11. (It is already available to people who have opted into Insider builds.) The next release contains a huge number of changes and improvements. If you use WSL a lot, I would strongly advise you to upgrade as soon as you are comfortable doing so. For example, there are a bunch of bugs in WSL's network stack that are fixed in the new version. Those could certainly cause problems for something like PHP. |
I've been doing that, and the error-log was helpful to resolve some of the initial issues with NGINX, the IPv6 stuff - but with FPM, I haven't been able to get it to launch, and there's nothing in the error-log. I wonder if it's affected by the same IPv6 issues maybe? Though I think I had it configured to use a Anyway, I rage nuked the whole thing from orbit thinking it was beyond fixing, so I'll have to find the time to set everything up again from scratch first...
Well, I am happy to report PHP 7.1 works very well at least under CLI - I can't speak to the FPM module because I don't have it working yet, but everything works under CLI, including opcache and xdebug, and I've been successfully running my integration test-suites with PostgreSQL queries and whatnot. So far so good :-)
I don't think PHP 7.1 is buggy? It has been stable for a while now. Me and my coworkers have been running PHP 7 for about six months now without problems, some have been running PHP 7.1 for a little while now without problems too. I realize trying to run this under a beta environment is risky, but PHP on Windows in general is already a shoddy affair - and this is for development of course, I don't plan on actually hosting anything on my Windows workstation ;-) Anyways, thanks for the input. Will definitely post updates here if I figure it out. |
|
@aseering if I get these services to run, is there any way to "daemonize" them and keep them running in the background? Or does everything live and die with the bash window at the moment? |
Pretty much.Latest dupe on that topic: #1849 |
|
@mindplay-dk -- it's slightly better than that: Everything dies when the last bash window closes. So if you can cause there to be a "hidden" bash window somewhere (using a few lines of vbscript, the third-party "run.exe", etc), you can help apps to stay alive for longer. Still a hack, though :-) |
|
@aseering in your opinion, should I continue struggling with this, or would it be easier to just use Docker? Performance should be on par with UOW in the latest versions, which use the same virtualization technology, right? Maybe Docker is more stable, having been around longer? (this is for development only.) |
|
By the way, upstart was dropped in 16.04, and hints have been dropped about container support, which means systemd support a fortiori. If they're supporting the kernel features for containers, then it's really just a matter of them changing the way that init works (which was at least discussed by Ben Hillis in the interop video (he said maybe MS's init daemon, which manages interop, marshalling, and unmarshalling, could be run without being PID=1)). |
|
@mindplay-dk -- WSL actually does not use virtualization technology at all. It is running Linux binaries on bare metal by modifying the Windows kernel to understand and handle Linux system calls natively. Docker actually has a virtual machine and a heavily stripped-down Linux kernel under the hood. That said, Docker has already been pretty well performance-tuned, and WSL has not yet... So I think it's a toss-up. If you just want to get your code running, and you know it runs in Docker, then yeah, I would go ahead and use Docker. WSL's real utility comes if you want to edit your Linux code files using Windows apps (though I hear that works acceptably in Windows Docker these days too?), call Windows apps from your Linux scripts, etc. |
|
Incidentally, @mindplay-dk -- how are you going about installing php-fpm? I just did the following and it seems to work fine for me on Ubuntu 16.04, as used on the prerelease Creators update: With that, I see the service started and listening on |
|
@aseering In my case, php-fpm starts up fine (socket file shows up in /run/php), but crashes(?) when used through nginx's fastcgi_pass. More specifically, when browsing to a PHP file, it loads partially and then stops loading, eventually timing out. Nothing in |
|
@aseering I don't have the Creators update yet, and I'm installing PHP 7.1 not 7.0, otherwise same, yeah. |
|
I took another stab at this, starting from scratch, this time with just setting my hostname and language, then installing PHP 7.1 and NGINX, nothing more - so: Without adding the I've created a sample config file Pretty standard? I can confirm that both services are running: I can confirm that the fpm script creates the I can confirm that it's serving files from that folder - I created a I've created a In There is nothing showing in It seems others have had a similar issue but it sounds like they did basically what I did, and it fixed their problem then - but doesn't appear to fix my problem now. The only notable difference seems to be, they were running PHP 7.0, I'm trying to run PHP 7.1 - not sure if that could make a difference, but I need 7.1. Any idea what to try next? |
|
Hm... Is there any way you could run php-fpm in the foreground and under Also -- is your version of php-fpm configured to log directly to a file by itself, or is it configured to log using syslog/systemd? The latter isn't yet supported under WSL; programs need to use a simple log file. |
|
Will try to answer those questions, but I just wiped my UOW again and installed the Creators update - going to try a reinstall with the latest and greatest. I'll let you know how this pans out. |
|
Okay, much simpler, and almost no errors during install/upgrade after Creators update! I removed several steps from my installation notes:
I don't see any of the upstart error notices anymore, and all of those driver/device-related error messages didn't appear this time. This time I did only precisely this: Then put in an NGINX config file, and then: (Those were my exact steps - this should now be completely reproducible, e.g. on a system with Creators updated and a clean UOW install, or e.g. after I'm much closer to something working now, but there is still a problem: after approximately 16K of output, the response stream appears to freeze - the browser stalls for like 5 minutes, and I then see In the NGINX log, I now see a slightly different entry like this one: I did try the Any idea what to try next? I feel like we're very nearly there :-) |
|
It's working! :-D I don't know what's up with the socket-based default FPM setting, but it doesn't work on this setup, so I've reconfigured FPM with Honestly, I don't know what I'm doing - I'm not a Linux or server (or network) guy, and I have no idea what difference it makes or why it matters if NGINX and FPM are talking via sockets or TCP. Either way, this should be good enough for a development setup? Whatever works, right? ;-) I suppose UOW ought to add some triggers or something to make sure this is the default setting at install? Unless they think whatever is causing the socket blockage will be fixed at a later time, probably better to override these settings with something that works? |
|
Great! Glad it works :-D The WSL team generally doesn't seem to like overriding settings. Especially not for third-party packages -- PHP 7.1 is not yet supported by Canonical/Ubuntu, it's only available from third-party repositories, and since different people could package PHP with configuration files in different locations, there's no clear standard way to patch it. Fortunately, the WSL team's intent is to make everything work in WSL that works on regular Linux. So hopefully this will get fixed. In order to fix this, though, I think we would need an strace of php-fpm and nginx when this bug is happening. Most likely one of the two is using some feature of UNIX sockets that hasn't been fully implemented yet, but that works for TCP sockets. (Windows supports TCP natively and does not support UNIX sockets natively, so WSL's implementation of the former has a bit of a head start.) Ping @sunilmut -- no trace yet, but this sounds like a WSL UNIX-sockets limitation. (Issue repro'able per above; nginx -> PHP 7.1 works over TCP but not UNIX sockets in Creators.) |
I don't know how to do a "strace", nor am I completely sure what that is. Did I mention I'm Linux illiterate? But you have exact steps to reproduce the issue now, I'm betting someone on the Microsoft side knows much better than I what to do with that... :-) |
|
Oh and I guess I can close this now :-) |
|
@aseering erm, is there a more general issue with sockets perhaps? I just tried to run php-pm, and it just exits with an error-message like: I don't see anybody else reporting that issue, and this appears to be socket-related again, so it's making me rather suspicious. I didn't think anything would work on Linux without sockets? Aren't they used for pretty much anything and everything server-related? Or is it maybe not even really fully supported on UOW yet? A quick search for sockets seems to indicate lots of socket-related issues with Node, so maybe this area is still work in progress? |
|
Whoops, haha, here we go. Well, I guess sit tight until they fix this one ;-) |
|
@mindplay-dk it's not true though. Sockets are implemented but not all socket options and modes are implemented. |
|
@mindplay-dk - I would actually reopen this issue or post a new one for your |
|
@sunilmut I don't know precisely how it works - it supposedly can run stand-alone without any external service (e.g. NGINX) and I think that's the default. As far as my understanding, php-pm is the server. I would think you should prioritize FPM/NGINX though - it might even be the same socket option that's missing for both, who knows? I don't really know what I'm talking about ;-) |
|
@mindplay-dk @sunilmut iirc nginx uses a socket activation mechanism from systemd. https://freedesktop.org/wiki/Software/systemd/DaemonSocketActivation/ |
|
My solution nginx + php-fpm: Windows version: 1703 (15063.138) folders (user: www-data, group: www-data): sudo apt remove nginx /etc/nginx/nginx.conf /etc/nginx/site-enabled/site.loc /etc/php/7.0/fpm/pool.d/site.loc sudo service nginx restart socket working. |
I'm trying to get a working PHP 7.1 / NGINX stack set up on Ubuntu on Windows.
Is that possible, or am I out too soon with the status of the current beta?
I've gotten as far as a working PHP 7.1 CLI installation, and working SSH daemon, and have been able to run unit-tests etc. and debug with xdebug from my Windows-installation of PHP Storm, and I was pretty excited about that!
I did also manage to get a working NGINX set up, by using the
master_process offdirective, which I don't understand what is for, but something to do with IPv6 being not yet fully implemented or something, and this is a work-around of sorts?I have been unable to run PHP scripts under NGINX, so that's the key piece missing for me at this time. I've gotten as far as to no error-messages showing up in NGINX's error.log, but all I've managed to get it to serve is the default index.html file that comes with NGINX, it won't serve PHP scripts.
I have all my installation notes here, hoping to eventually succeed and being able to share with others how to get this working.
Following my own instructions, I begin by doing the usual
apt-get update,dist-upgrade,upgrade- but during thedist-upgrade, I'm getting a long list of errors - here's the tail of the output:Specifically, I'm concerned about the following messages:
mknod: ‘ram0-’: Function not implementedmakedev ram0 b 1 0 root disk 0660: failedetc.runlevel:/var/run/utmp: No such file or directory/sbin/MAKEDEV: warning: can't read /proc/devicesinvoke-rc.d: policy-rc.d denied execution of start/com/ubuntu/upstart: Connection refusedIs any of this "serious"? Could any of it explain why I can't seem to get NGINX to play nice with FPM?
I'm not a Linux dude, I'm a Windows user, so this is pretty adventurous for me - don't expect me to understand very technical descriptions of any details, but please let me know if you have any ideas or clues on how to get past this last speedbump to a working installation?
The text was updated successfully, but these errors were encountered: