You know what, let me jump in on the "I hate PHP" bandwagon.

A couple months ago I upgraded my mail servers unattended. Roundcube got fucked for a couple of months, and I figured.. fuck it, I can still use Dovecot for authenticating with desktop mail clients like K-9.
Recently I unfucked it, turns out that it was an issue with the sock file in php-fpm. That's also when I noticed that PHP apparently hardcodes in its current version in the bloody socket file. Because why the fuck wouldn't you? It makes upgrades so much fucking easier!!! Said no fucking sysadmin ever!!!

And today I upgraded one of my mail servers to Ubuntu Server 18.04, finally, after a lot of hesitation. Bad decision, because now PHP got fucked YET AGAIN.
Again an issue with socket files? I have no fucking idea. systemctl shows no failed services (because you know PHP, why would you fail your service with an error message instead of throwing a meaningless 502 Bad Gateway, right?!!) and looking at the config files, well the socket file got its new php-fpm 7.2 file (still got the fucking version number hardcoded in) and thus I changed that socket file location in /etc/php/7.0...

devRant may just have been my rubber duck.


Bloody fucking pile of fucking junk!!!!

  • 5
    … And unfucked it again. Should I really make a habit of this for every PHP upgrade?
  • 3
    Dude chill 😐 php ain't that bad
  • 4
    Php,, I actually like... with Laravel only.

    This, though. I hate. It always wastes a good few hours of my time... especially since I'm on WSL
  • 3
    @rant1ng As a fellow WSL user on the one host in my network that's running Windows 10, I feel your pain ._. that shit makes things even worse than it is on stock Ubuntu already, especially with Windows' shitty firewall. Had that once with something as simple as an sshd (that I had to run manually because why support systemd or any other Linux-based init system, right?) where it wouldn't be accessible despite being activated. Eventually I just figured, fuck it.. Windows ain't made to run as a server anyway. ssh -L22:localhost:2022 laptop.lan (which ironically has thermal issues and runs on the Wi-Fi network but accumulates more than 10x the uptime of my W10 desktop despite that) and then it finally ran fine, when I just connected to localhost:2022 on the laptop. Fuck Windows.. in that case it was the shitty firewall, but every fucking thing in this bloody pile of shit.. it's all just fucking atrocious. I'd even go as far as saying that Windows 10 is worse than PHP.
  • 3
    At least now I was able to set the socket file to /var/run/php-fpm.socket (which, granted, I could've done last time as well, but dumb as a post) so hopefully those version issues won't bite me in the ass anymore. PHP, don't you fucking dare to change to change the location of the bloody socket file in the next upgrade... I fucking dare you!!!!!
  • 3
    Btw if anyone lands up here from Google, I've solved the migration issue as such:
    Update Ubuntu 16.04 (apt update; apt upgrade)
    Reboot (reboot)
    Log in again (obviously)
    Upgrade to 18.04 (do-release-upgrade)
    Change these and those config files according to server setup, it'll vary in your own server setup
    Finally, edit /etc/php/7.2/fpm/pool.d/www.conf, and change your "listen" parameter to listen on /var/run/php-fpm.sock. The file location that you'll have to put in can be found at /var/log/nginx/error.log (if you're running nginx).
  • 2

    I use tcp and it works fine, as long as I run a shell script that starts php-fpm.
    Actually, this way, I can run 7.1 and 7.2 on the same nginx config, since they both point to the same tcp, it just depends which service I start running.

    I did this by accident of course, but a happy accident.

    18.04 upgrade took a whole day. But all in all, WSL can be done, just takes a bit of patience.

    Didn't they implement support for sockets, and it runs even if you don't have the console open? thought I read that somewhere
  • 2
    Password has to be between 6 and 20 characters. Oh great, I found myself another fucking shitsite that stores its passwords in plain, and of which the database's glory hole can't handle more than n amount of characters!!! So trustworthy, much wow!! This increases my trust in the fucking government by so fucking much.
  • 2
    @rant1ng Oh yeah I solved that.. it was just a socket relocation in the config, just like last time. On the servers the upgrade only took about 10 minutes though, but I haven't explicitly timed.
  • 2

    A lot of your issues have nothing to do with PHP......

    Really, nothing.

    Most of the configuration is set by the distribution not PHP itself.

    And especially socket file configuration has changed (I guess) because of Ubuntu finishing systemd migration - changing /var/run to /run and other path changes....
  • 2
    I see a rant about Ubuntu, taking PHP in with it, and blaming PHP for it all. This isn't PHP's fault, leave Brittan... uh PHP alone!!!! :')
  • 1
    @IntrusionCM hey man

    Don't be a downer

    We were happily and ignorantly blaming php there
  • 2
    @xewl @IntrusionCM But I thought that Ubuntu Server was "stable" and "server-grade"?! It can't possibly be an Ubuntu issue.
    … At least now the socket file doesn't have a version number anymore, so hopefully that's the end of the issues. By the way, have they really still not fully migrated to systemd yet?! I mean, there are still init.d files in there, but they're still actually being used?! Stable = ancient? In Arch for example, I haven't seen any sysvinit-related stuff for years.
  • 1
    @Condor You upgraded, I've never Not had problems after that... that's why I use floating IP's in the first place :)

    Though, putting this on PHP, while it's not even PHP's config but an external one that's pointing to an older version... (a newer in this case?) ..

    Just don't blame it on the language itself - that's not correct at all xD
  • 2
    @Condor In my experience (nearly 7 years of doing shitty upgrades) especially OS upgrades are toxic. This isn't necessarily fault of upstream (Ubuntu/Debian) nor downstream (PHP) but rather due to the fact that upgrading involves a lot of variables (renamed packages, changed library versions, different config files, changed configuration by user and so on). If you want to have a "more pleasant experience", heres what I do (I'm not an sysadmin, someone might shed some more light on this). Getting full snapshot of machine, installing in VM, initialising GIT in /etc, running dist-ugprade or whatever you Need. Looking out for DPKG configuration files and changed files (https://raphaelhertzog.com/2010/09/...)

    And when I know what's changed, only then I run the fscking upgrade.. Need some time yes, but database configuration and migration (think of mariadb - it's not an in drop replacement for mysql) was too fucked up too many times.
  • 1
    @IntrusionCM Doesn't seem like a bad setup actually! Here I usually go with a full backup and in case of these Ubuntu servers I also commit the upgrade to only one of the pair to see how it goes, and afterwards to the other one after comparing and seeing whether everything still works as intended. But git init on parts of the system like the filesystem root or especially /etc (which is mostly text files so git would work like a charm on that) never fails to intrigue me :)
  • 1
    @Condor There is a tool - called etckeeper - which is preinstalled. It can use basically any VCS and integrates with dpkg - so it can autocommit before install e.g. Useful shit. XD
  • 1
    It doesn't have anything to do with PHP (programming language). It's Unix sockets you're having an issue with.
Add Comment