uwsgi-piku.service not being enabled?

[jfmatth]

Hi, love the project, thank you for building it.

I was wondering why after a reboot my sites didn't work, and found that the uwsgi-piku.service wasn't being enabled, but by all accounts in the playbook it should be. Very odd.

I was using Proxmox containers, thinking that might be the issue, but then tried it on a new 22.04 Ubuntu VM on proxmox, same result.

The Ansible playbook shows it's changed, but the systemctl status shows otherwise after the run

TASK [Enable uwsgi-piku service] ***************************************************************************************************************************
changed: [127.0.0.1]

TASK [Start uwsgi init script] *****************************************************************************************************************************
skipping: [127.0.0.1]

TASK [Get nginx default config] ****************************************************************************************************************************
changed: [127.0.0.1]

TASK [Restart nginx service] *******************************************************************************************************************************
changed: [127.0.0.1]

TASK [Get systemd.path piku-nginx.path] ********************************************************************************************************************
changed: [127.0.0.1]

TASK [Get systemd.path piku-nginx.service] *****************************************************************************************************************
changed: [127.0.0.1]

TASK [Start piku-nginx.path] *******************************************************************************************************************************
changed: [127.0.0.1]

PLAY RECAP *************************************************************************************************************************************************
127.0.0.1                  : ok=33   changed=27   unreachable=0    failed=0    skipped=2    rescued=0    ignored=1

jfmatth@vm-piku-1:~$ systemctl status uwsgi-piku.service
● uwsgi-piku.service - Piku uWSGI Emperor
     Loaded: loaded (/etc/systemd/system/uwsgi-piku.service; disabled; vendor preset: enabled)
     Active: active (exited) since Wed 2023-08-02 15:22:49 UTC; 10s ago
        CPU: 16ms

Any thoughts on how to troubleshoot this?

Not sure if it matters, but I'm running SUDO instead of from the root account.

Just tried this on a DO droplet for 22.04, same result and I'm logged in as root.

After install, if I reboot the service isn't starting. If I then enable it, reboot, it works as expected.

[jfmatth]

seeing odd behavior in the journal on install, mentioning the uwsgi-piku.service is world-inaccessible, maybe that's it?

Aug 02 16:12:06 ct-piku-2 systemd[1]: Configuration file /etc/systemd/system/uwsgi-piku.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
Aug 02 16:12:06 ct-piku-2 systemd[1]: Configuration file /etc/systemd/system/uwsgi-piku.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
Aug 02 16:12:06 ct-piku-2 systemd[1]: Configuration file /etc/systemd/system/uwsgi-piku.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
Aug 02 16:12:06 ct-piku-2 systemd[1]: Starting LSB: starts the uwsgi app server...
Aug 02 16:12:06 ct-piku-2 uwsgi-piku[5401]: Starting uwsgi-piku:
Aug 02 16:12:06 ct-piku-2 sudo[5408]:     root : PWD=/home/piku ; USER=piku ; COMMAND=/bin/sh -c uwsgi-piku --ini \/home\/piku\/\.piku\/uwsgi\/uwsgi\.ini --daemonize \/home\/piku\/\.piku\/uwsgi\/uwsgi\.log --pidfile \/home\/piku\/\.piku\/uwsgi\/uwsgi-piku\.pid
Aug 02 16:12:06 ct-piku-2 sudo[5408]: pam_limits(sudo-i:session): Could not set limit for 'core' to soft=0, hard=-1: Operation not permitted; uid=0,euid=0
Aug 02 16:12:06 ct-piku-2 sudo[5408]: pam_unix(sudo-i:session): session opened for user piku(uid=1000) by (uid=0)
Aug 02 16:12:06 ct-piku-2 systemd[1]: Created slice User Slice of UID 1000.
Aug 02 16:12:06 ct-piku-2 systemd[1]: Starting User Runtime Directory /run/user/1000...
Aug 02 16:12:06 ct-piku-2 systemd[1]: Finished User Runtime Directory /run/user/1000.
Aug 02 16:12:06 ct-piku-2 systemd[1]: Starting User Manager for UID 1000...

root@ct-piku-2:~# ll /etc/systemd/system
total 62
drwxr-xr-x 9 root root  20 Aug  2 16:12 ./
drwxr-xr-x 5 root root  14 Apr 24  2022 ../
...
-rw-r--r-- 1 root root 156 Aug  2 16:12 piku-nginx.path
-rw-r--r-- 1 root root 163 Aug  2 16:12 piku-nginx.service
drwxr-xr-x 2 root root   3 Aug  2 16:05 socket.target.wants/
drwxr-xr-x 2 root root   5 Aug  2 16:06 sockets.target.wants/
lrwxrwxrwx 1 root root  31 Apr 24  2022 sshd.service -> /lib/systemd/system/ssh.service
lrwxrwxrwx 1 root root   9 Apr 24  2022 sudo.service -> /dev/null
lrwxrwxrwx 1 root root   9 Apr 24  2022 sys-kernel-debug.mount -> /dev/null
drwxr-xr-x 2 root root  10 Aug  2 16:06 sysinit.target.wants/
lrwxrwxrwx 1 root root  35 Apr 24  2022 syslog.service -> /lib/systemd/system/rsyslog.service
drwxr-xr-x 2 root root  11 Apr 24  2022 timers.target.wants/
-rw------- 1 root root 319 Aug  2 16:11 uwsgi-piku.service
root@ct-piku-2:~#

[chr15m]

Hi, thanks for reporting this. Seems very weird. I'll try to find some time to investigate and if you discover anything to fix it in the mean time let me know.

[jfmatth]

I'm wondering if the file settings have anything to do with it?

Seems odd. It starts the service but doesn't enable it. Maybe an Ansible bug?

I solve it by manually setting it to enabled

[chr15m]

When you say you set it to enabled, do you recall the command? Or did you do it with Ansible, and if so could you send me the change? Could be file settings - maybe there needs to be a step before where it does chmod or something.

[jfmatth]

Sadly, not Ansible, just systemctl

systemctl enable uwsgi-piku.service --now

[jfmatth]

Also, I'm noticing that UWSGI albeit working is not supported anymore :(.

Any thoughts on moving to say gunicorn? Probably a lot of work unfortunately.

[chr15m]

Yeah that's a big job. I guess @rcarmo would have more to say on this as the creator or Piku. My preference would be to go for something lighter than uwsgi that is not bound to Python, perhaps even just using systemd to keep the web processes alive and connect nginx to them.

[chr15m]

@jfmatth ok I found the problem. In your playbook it says "Start uwsgi init script" but that rule should only be reached if "systemctl" not in systemctl.stdout. So for some reason the systemctl command is not being found correctly. Flagging this as a bug.

[rcarmo]

@jfmatth Why do you say uWSGI is not supported? it is still being maintained (has commits from this week), and the only reason to move off it right now would be if it were dropped from both Debian and Ubuntu (which seems unlikely given that I see it listed for all known future releases of both...). I've been toying with the idea of using caddy (and replace nginx as well), but to be honest the ease with which we can get uWSGI to supervise processes for any language runtime still trumps It, and I'm curious as to why you have that impression.

[jfmatth]

@rcarmo You're right, I misspoke, its still under maintenance. I initially read that to mean it's going away 😮 but am wrong, ignore my comment 😄

I looked at Caddy the other day as well, but both nginx and uwsgi are so popular on so many platforms, it doesn't make sense at this point.

Thanks for everyone's quick response to my issue, hope we find that bug, but luckily not a show stopper.

[jfmatth]

Found this, but not sure it's still a bug in Ansible?

https://github.com/ansible/ansible/issues/72451

[jfmatth]

I wonder if you should specify the full path to the systemd package?

I use the systemd module in some of my playbooks, but I specify the full module name

    - name: Start qemu-guest-agent
      ansible.builtin.systemd:
        name: qemu-guest-agent
        enabled: true
        state: started

I'm pretty sure my code works on the same Ubuntu 22.04 targets

I'll do some checking on my side to see if that fixes it.

[chr15m]

Cool thanks for testing. If you fork this repo and push your changes to your fork then the GitHub action will run and tell you if it failed on any other versions of Ubuntu.

[chr15m]

By the way I noticed on that bug you linked that they use the following workaround. This could be useful if the Ansible bug is in Ubuntu distribution of Ansible itself.

# https://github.com/ansible/ansible/issues/72451
- name: Really enable postgresql
  shell:
    cmd: "systemctl enable postgresql@12-main.service"
  when: postgresql_systemd.status.UnitFileState == 'enabled-runtime'

(We would have to swap out postgres for uwsgi).

[jfmatth]

I wonder if you should specify the full path to the systemd package?

I use the systemd module in some of my playbooks, but I specify the full module name

    - name: Start qemu-guest-agent
      ansible.builtin.systemd:
        name: qemu-guest-agent
        enabled: true
        state: started

I'm pretty sure my code works on the same Ubuntu 22.04 targets

I'll do some checking on my side to see if that fixes it.

Unfortunately, using the module name fully didn't seem to help.

I'm guessing at this point, its the "if" code in the task that is failing. Ill check the playbook with the check removed and just have it enabled and let you know what happens.

Is there a reason we you are still supporting init.d? seems like most systems are SystemD these days.

[jfmatth]

Ok Weird Behavior!

I was testing seeing if removing the "Test" for SystemD would make any difference, it didn't.

However, I thought I would run the install more than once, and that seemed to make it work? The first time I ran it, it showed "Changed" on the "Enable uwsgi-piku service" task, ran it a second time, same thing, ran it a third time and it comes back green and the service is enabled and started.

Very strange! I'm going to try to break the tasks out and separate enabled and started into two tasks like I do in my playbooks. Stay tuned.

[jfmatth]

So strange, I broke out the enable and start into two seperate tasks and still the same behavior, i've never seen this with Ansible before :(

    - name: (new) Enable uwsgi-piku service
      systemd:
        name: uwsgi-piku
        enabled: yes

    - name: (new) Start uwsgi-piku service
      systemd:
        name: uwsgi-piku
        state: started

[jfmatth]

I have tried everything I can think of to fix this.

• Changed the permissions on the file
• break out the enabled to another task
• enable it again on another task

Nothing seems to work, except running install again, so strange. At least we have a workaround 🤦

[chr15m]

Ok, thanks for your further testing!

[jfmatth]

of course. All I can figure at this point is it's something do with how the service files are created? I know that RH or Ubuntu have templates for that, maybe Ansible has a module to help with that?

[chr15m]

I've replicated this now on one of my own Piku machines. Thanks for reporting @jfmatth! I was wrong above when I said it starts the uwsgi init script - it is actually skipping that step (correctly) not running it.

[jfmatth]

Glad you were able to see it first hand @chr15m .

I looked over the Ansible playbook and from what I can tell, it should work, strange.

[chr15m]

Alright I managed to fix this using the workaround from here:

https://github.com/ansible/ansible/issues/72451#issuecomment-771541032

[chr15m]

I guess the version of Ansible in Ubuntu 22 contains the bug they talk about.

[chr15m]

Tested on a DO server that I spun up for this purpose.