Boot Script issue on UDM SE

[llaforest]

https://github.com/unifi-utilities/unifios-utilities/blob/24eb16adcbb925d9921413bdfdbff26c130cec79/on-boot-script/remote_install.sh#L131

This line should use the persistent folder instead of hardcoding "/mnt/data" which is not good on UDM SE or UDR. The logic of finding persistent folder is a little bit weak too. As soon as it finds the "/mnt/data" it will use that. I would try to use "/mnt/data" when using os V1.x, and use "/data" on 2.x and above... This could be done by using: ubnt-device-info firmware

I opened a pull request with a solution to this problem. This way it will work on all switch with any os version.

One other problem coming soon, it seems "/etc/cron.d" files are not being executed anymore. I ask on the UI community about this I will report back with my findings. https://community.ui.com/releases/UniFi-OS-Dream-Router-3-0-13/297b8f33-7e61-4494-adae-7b48ed631ef6#comment/231ad74c-2ceb-4b4b-a111-938316bd42e2

By the way, totally open to let the real pros run some tests in my UDM SE if needed.

[bennettp123]

One other problem coming soon, it seems "/etc/cron.d" files are not being executed anymore.

I stumbled onto this post looking for others with cron issue—my cron last ran about 4 days ago. Details below.

Worth mentioning: I'm on a UDM, not UDR/SE, which does not yet have 2.x or 3.x—currently running 1.12.33. System uptime is 19 days.

A few other notes:

• ps aux shows cron is running:

  [UDM] root@udm0-office:/mnt/data/on_boot.d# ps aux | grep cron
   3938 root     /usr/sbin/cron -f
  16717 root     s6-supervise cron
  16749 root     /usr/sbin/cron -f
  22765 root     grep cron

• However, /usr/sbin/cron does not exist—only /usr/sbin/crond. I suspect the two processes above are for the unifi-os shell, not the host.
• After /etc/init.d/crond restart, then /usr/sbin/crond is running too—and it's still there after a reboot. I assume this will fix cron.daily (if it doesn't, I'll edit this post).

I suspect crond failed 4 days ago, and wasn't automatically restarted because v1.x doesn't have systemd.

[llaforest]

Ok after more troubleshooting, it seems that cron jobs now need to specify the user: Before and not working anymore: 0 3 * * * sh /data/ubios-cert/ubios-cert.sh renew After and working fine on Unifi-OS 3.x: 0 3 * * * root /data/ubios-cert/ubios-cert.sh renew

Not sure why sh should be used so I removed it. I need to test it on my UDM Pro which is on Unifi-OS 1.x.

[imryno]

A few thoughts

• The persistent folder can also be found using lsblk df or mount. Not sure which is the more robust method.
• A lot of scripts also have hard-coded /mnt/data . It would be good to set an ENV or a conf file or something that scripts could use to easily get the right location.
• I would prefer everything lives in a sub-folder (e.g /data/unifi-utils/ to keep it separated from the stock OS files. Ideally all the etc files would live here too and be linked in place. One location to backup and an easy restore.
• Rather than udm-boot.service , we could use systemd to manage it all. E.g. make two systemd targets
  • unifi-utils-init which does all the setup of podman/cni, linking etc files ...etc
  • and unifi-utils which starts all the containers and long-running scripts. Then we would get proper dependency handling and supervision.

[boostchicken]

A few thoughts

• The persistent folder can also be found using lsblk df or mount. Not sure which is the more robust method.
• A lot of scripts also have hard-coded /mnt/data . It would be good to set an ENV or a conf file or something that scripts could use to easily get the right location.
• I would prefer everything lives in a sub-folder (e.g /data/unifi-utils/ to keep it separated from the stock OS files. Ideally all the etc files would live here too and be linked in place. One location to backup and an easy restore.

• Rather than udm-boot.service , we could use systemd to manage it all. E.g. make two systemd targets

  • unifi-utils-init which does all the setup of podman/cni, linking etc files ...etc
  • and unifi-utils which starts all the containers and long-running scripts. Then we would get proper dependency handling and supervision.

bingo. or if you are mad cheap, use a symlink :)