Last night’s patch included updates to nginx. Issuing a “/lib/systems-sysv-install enable nginx” leaves the script starting an nginx session. In other words hangs up the update. An option would to flip the bit and require a reboot. The script does not end, nginx is preventing the script to continue. This leaves AstroBerry disabled. This is the evidence.
Setting up astroberry-server-wui (2.0.7) ...
Synchronizing state of nginx.service with SysV service scri
systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable nginx
insserv: script klogd: service klogd already provided!
insserv: script klogd: service klogd already provided!
^Cdpkg: error processing package astroberry-server-wui (--c
installed astroberry-server-wui package post-installation
interrupted
Processing triggers for man-db (2.8.5-2) ...
Errors were encountered while processing:
astroberry-server-wui
root@astroberry:/home/astroberry#
Yes. This is the problem. I used SUDO SU and SUDO to show that the credentials are not the problem. Having dealt with NGINX before, this is one service which thinks it must run in a terminal foreground and not in the background.
After much research and time, a solution has been found. The Raspbian build needs some tools to view system logs. Geany doesn’t satisfy the need when things go bad.
The failure was deduced by recognizing the installation script, finding its location, and using Geany to read the files with search. At the end of AstroBerry-server-wui.postinst a series of enable and restart commands are the last actions. Nginx is one of those services being restarted. They are the most benign commands to test.
I ran each command to see which command hung up. When I found it, then I could ascertain why it hung. The singular problem child identified was indiwebmanager. Enable was not the problem. Restart was the problem. The problem was hanging the script.
Indiwebmanager has the option to establish an OTA profile. If the profile is set to auto start, then a restart command would be persistent in memory. Being persistent in memory doesn’t allow scripts to end. I edited the postinst file by adding a STOP service command after the RESTART service command of indiwebmanager. I saved the file. Then I ran DPKG —configure -a. The script completed without incident. Update && upgrade work as normal. Indiwebmanager operates as normal. Case is closed.
Recommendations
Use a stop service command when a service can potentially be set persistent when using restart services command.
Here is the best recommendation. The stop service does not do anything when indiwebmanager is set to load any profile. What I did is change the service files for indiwebmanager and indiwebmanagerapp. I set the following.
Before
[Unit]
Description=INDI Web Manager
After=multi-user.target
After
[Unit]
Description=INDI Web Manager
After=gpspanel.service
and
Before
[Unit]
Description=INDI Web Manager App
After=multi-user.target
After
[Unit]
Description=INDI Web Manager
After=indiwebmanager.service
Provide a indiwebmanager log viewer other than KSTARS. I use gnome-logs and gnome-system-logs to view log files GUI.
Last edit: 3 years 10 months ago by John Robison. Reason: New findings