Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1, 14.0.1.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 15.0.0, 15.0.1, 15.0.1.1, 15.0.1.2, 15.0.1.3, 15.0.1.4, 15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 16.0.0, 16.0.0.1, 16.0.1
Fixed In:
16.1.0, 16.0.1.1, 15.1.0.5, 14.1.2.8, 13.1.3.5
Opened: Jun 25, 2019 Severity: 3-Major
The BIG-IP system may fail to deploy new or reconfigure existing iApps. When this happens, a long error message is displayed in the GUI that begins with: script did not successfully complete: ('source-addr' unexpected argument while executing The message is also logged to /var/log/audit by scriptd with a severity of 'notice'. The unexpected argument mentioned in the error varies depending on the iApp being deployed and on the settings you configure. You may also see 'snatpool', 'ldap', etc.
New iApps cannot be deployed. Existing iApps cannot be re-configured.
This issue occurs when: -- The BIG-IP system is configured with multiple users of varying roles. -- The scriptd daemon has already spawned the maximum number (5) of allowed child processes to serve its queue, and all the processes were assigned a low 'security context'. This can happen, for instance, if a low-privileged user (such as an Auditor) has been looking at the configuration of iApps using the GUI a lot. -- Subsequently, a high-privileged user (such as an Administrator) attempts to deploy a new iApp or reconfigure an existing one. Note: You can inspect the number of child processes already created by scriptd by running the following command: pstree -a -p -l | grep scriptd | grep -v grep However, it is not possible to determine their current 'security context'.
Restart scriptd. To restart scriptd, run: bigstart restart scriptd Running this command has no negative impact on the system. The workaround is not permanent; the issue may occasionally recur depending on your system usage.
The system now stops all scriptd child processes and creates new ones with the new user security-context when the user changes.