How exactly Omada is started in Linux during/after boot
Most linux distributons now support systemd instead of the old init.d startup procedure.
When looking into omada startup process, i find that the tpeap commands points to shell script like /opt/tplink/EAPController/bin/control.sh which is used to start the omada application. Not clear how tpeap is invoked at startup, as their does not seem to be a proper systemd unit file for tpeap. So how is Omada actually getting started ?
The reason why I am asking this is because I want to try and cap the CPU usage of the omada application both at statrtup and runtime to about 60-70% CPU use, and one way was to put the directive CPUQuota=x% in the unit file.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi @APRC-P3-Tel
Thanks for posting here.
Omada is likely started via a legacy init.d script that's been converted to a systemd service through systemd's backward compatibility. To check:
1. Look for a symlink in `/etc/systemd/system/` or `/lib/systemd/system/` pointing to `/etc/init.d/tpeap`
2. Run: `systemctl status tpeap` to confirm
To limit CPU usage:
1. Create a proper systemd override:
```
sudo systemctl edit tpeap
```
2. Add:
```
[Service]
CPUQuota=70%
```
3. Reload systemd: `sudo systemctl daemon-reload`
This will apply the CPU limit while maintaining the original startup method.
- Copy Link
- Report Inappropriate Content
Hi @APRC-P3-Tel
Thanks for posting here.
Omada is likely started via a legacy init.d script that's been converted to a systemd service through systemd's backward compatibility. To check:
1. Look for a symlink in `/etc/systemd/system/` or `/lib/systemd/system/` pointing to `/etc/init.d/tpeap`
2. Run: `systemctl status tpeap` to confirm
To limit CPU usage:
1. Create a proper systemd override:
```
sudo systemctl edit tpeap
```
2. Add:
```
[Service]
CPUQuota=70%
```
3. Reload systemd: `sudo systemctl daemon-reload`
This will apply the CPU limit while maintaining the original startup method.
- Copy Link
- Report Inappropriate Content
@Vincent-TP. Things did not go well as I expected to with this approach for the time being. Here is what happened:
(1) System V Init cannot be disabled i think in Linux AFAIK as its a primary Init system, but individual services can be disabled. So the first step i took was to disable Omada startup in System V Init with:
chkconfig tpeap off // I use Rocky Linux 8.10 derived from Redhat 8. For Debian command might be "sudo update-rc.d tpeap disable"
Verified after rebooting system that Omada does not restart by itself as a service in background.
(2) Now created the below tpeap.service systemd Unit file in /etc/systemd/system/
[Unit]
Description=Tp-Link Omada service startup
After=network.target
[Service]
ExecStart=/opt/tplink/EAPController/bin/control.sh
CPUQuota=140%
TimeoutStartSec=3600
[Install]
WantedBy=multi-user.target
and enabled the service with:
sudo systemctl enable tpeap
I didn't pass any parameter to the control.sh script like "start". This could be a problem and I am not sure as I did not read the whole control.sh script
Restarted the machine and this time, the Omada service starts by itself as a service, the process ran for a while, but it did not complete and omada service come up. I checked the service status. It was dead (inactive) and no useful information to debug. However during startup I noticed that CPU usage never crossed 70% approx on each core.
Maybe the systemd does not like something in the control.sh startup script of omada or vice-versa.
So i had to roll back by:
sudo systemctl disable tpeap
chkconfig tpeap on
and rebooted. This time Omada came back up nicely. Thankfully as I have a production system and even though i do not have any requirements for availability, The time for which I can tinker and disable service is limited.
So for now this init.d to systemd stuff did not work for me. Maybe weekend I will again try, now that I can atleast safely go back to square 1, when things don't go well
- Copy Link
- Report Inappropriate Content
Finally got ir working with this Unit file script:
[Unit]
Description=Tp-Link Omada service startup
After=network.target
[Service]
Type=forking
WorkingDirectory=/opt/tplink/EAPController/bin/
ExecStart=/opt/tplink/EAPController/bin/control.sh start
ExecStop=/opt/tplink/EAPController/bin/control.sh stop
CPUQuota=140%
TimeoutStartSec=1800
[Install]
WantedBy=multi-user.target
I added the start parameter. However it was not the only issue. Needed the "Type=forking" command also (default is simple or foreground process).
I verified that CPU usage of Omada does not execeed 70% overall (on both cores of Dual Core hardware I am running this on). And afer statup, if i use web interface or mobile app, the CPU usage does not cross 70% overall again in heavy operations also. Lets see if this help be use the hardware longer.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 213
Replies: 3
Voters 0
No one has voted for it yet.