Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'apt purge openhab2' failes with still active process by frontail #285

Closed
ThomDietrich opened this issue Dec 18, 2017 · 8 comments · Fixed by #969
Closed

'apt purge openhab2' failes with still active process by frontail #285

ThomDietrich opened this issue Dec 18, 2017 · 8 comments · Fixed by #969

Comments

@ThomDietrich
Copy link
Member

ThomDietrich commented Dec 18, 2017

@BClark09

[15:02:55] openhabian@openHABianPi:~$ sudo apt purge openhab2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  openhab2*
0 upgraded, 0 newly installed, 1 to remove and 3 not upgraded.
After this operation, 76.6 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 42645 files and directories currently installed.)
Removing openhab2 (2.2.0-1) ...
Processing triggers for systemd (232-25+deb9u1) ...
(Reading database ... 41504 files and directories currently installed.)
Purging configuration files for openhab2 (2.2.0-1) ...
userdel: user openhab is currently used by process 14291
/usr/sbin/deluser: `/usr/sbin/userdel openhab' returned error code 8. Exiting.
/usr/sbin/delgroup: `openhab' still has `openhab' as their primary group!
[15:07:40] openhabian@openHABianPi:~$ ps -aux | grep openhab
openhab  14291  0.0  4.4  80152 19564 ?        Ssl  Dec17   0:04 node /usr/bin/frontail --ui-highlight --ui-highlight-preset ./preset/openhab.json -t openhab -l 2000 -n 200 /var/log/openhab2/openhab.log /var/log/openhab2/events.log
openhab  14464  0.0  0.2   5116  1148 ?        S    Dec17   0:09 tail -n 200 -F /var/log/openhab2/openhab.log /var/log/openhab2/events.log
root     28381  0.0  1.2  11504  5704 ?        Ss   14:56   0:00 sshd: openhabian [priv]
openhab+ 28387  0.0  1.2   9652  5344 ?        Ss   14:56   0:00 /lib/systemd/systemd --user
openhab+ 28390  0.0  0.5  29772  2612 ?        S    14:56   0:00 (sd-pam)
openhab+ 28397  0.0  0.9  11636  4208 ?        S    14:56   0:00 sshd: openhabian@pts/0
openhab+ 28400  0.1  0.9   7748  4168 pts/0    Ss   14:56   0:00 -bash
openhab+ 30637  0.0  0.6   9352  2908 pts/0    R+   15:08   0:00 ps -aux
openhab+ 30638  0.0  0.4   5988  2088 pts/0    S+   15:08   0:00 grep --color=auto openhab

Related to openhab/openhab-linuxpkg#108

@mstormi
Copy link
Contributor

mstormi commented May 14, 2018

Hi @BClark09
I've just hit this as well when I did apt-get remove openhab2
Please have a look, thanks

@BClark09
Copy link
Member

BClark09 commented May 14, 2018

Hi @mstormi, are you sure this happened with a remove? AFAIK, there's no function to remove the openhab user on remove; only on purge:

https://github.com/openhab/openhab-linuxpkg/blob/master/resources/control-runtime/postrm

When reading up on what should be done I came across this and think that the following may be the best way of making sure these processes aren't active before the user is deleted:

ps -o pid= -u openhab | xargs kill -9

However, I think we discussed this further in openhab/openhab-linuxpkg#108 in which we came to the conclusion that we shouldn't force delete the user, just gracefully handle it (i.e. if the user exists, don't try to create it again on next install). I still need to think about that properly but we can use the first part of the command above to test for active processes, and list them in the uninstall process.

@mstormi
Copy link
Contributor

mstormi commented May 18, 2018

Oh thought I had responded already.
Right, "remove" does not delete the user, still the running frontail process locked some file that "remove" was trying to remove so it was sort of the same root cause.
Problem is frontail is run by systemd and will restart another instance as soon as the active one dies (when we kill it) and the new instance is as-blocking as the old one. A proper solution should do something like systemctl stop frontail.service called from openhab2 package preremove script.
[not sure about packages but vaguely recall there's that sort of script]
Maybe do systemctl disable frontail.service, too ? Does not make sense to run it with no openhab installed, does it?
We should also think about doing the inverse (i.e. start frontail service) on openhab2 postinstall. Maybe check for presence of frontail service first (systemctl status frontail.service).

AND, to do it right, we should think about doing the same to ALL other services that to make sense require openhab to be installed as well.

@BClark09
Copy link
Member

BClark09 commented May 20, 2018

I don't think it's a good idea to refer to other packages if openHAB isn't dependant on them. The openHAB debian package isn't "aware" of openHABian, nor the other packages that it comes with. The packages should be kept completely separate.

What might make sense to to modify the dependant service files when they are installed with openHABian scripts, so that they reference the openHAB service file.

@mstormi
Copy link
Contributor

mstormi commented May 21, 2018 via email

@ThomDietrich
Copy link
Member Author

Frontail and openHAB are not dependent. Frontail just happens to use the log file created by openHAB...

Imho we should 1. change frontail to another user AND/OR fix the issues with the openhab user (as discussed in openhab/openhab-linuxpkg#108)

@mstormi
Copy link
Contributor

mstormi commented Apr 17, 2020

@BClark09 would PartOf=openhab2 in frontail's systemd config be a solution?

@mstormi
Copy link
Contributor

mstormi commented May 23, 2020

pinging @BClark09

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants