Webmin failed to start after RHEL7 reboot.
[user@HOSTNAME ~]$ systemctl status webmin
● webmin.service - LSB: web-based administration interface for Unix systems
Loaded: loaded (/etc/rc.d/init.d/webmin; bad; vendor preset: disabled)
Active: failed (Result: exit-code) since 月 2021-03-08 14:31:20 JST; 2 weeks 2 days ago
Docs: man:systemd-sysv-generator(8)
Process: 17438 ExecStart=/etc/rc.d/init.d/webmin start (code=exited, status=25)
3月 08 14:31:20 HOSTNAME systemd[1]: Starting LSB: web-based administration interface for Unix systems...
3月 08 14:31:20 HOSTNAME systemd[1]: webmin.service: control process exited, code=exited status=25
3月 08 14:31:20 HOSTNAME systemd[1]: Failed to start LSB: web-based administration interface for Unix systems.
3月 08 14:31:20 HOSTNAME systemd[1]: Unit webmin.service entered failed state.
3月 08 14:31:20 HOSTNAME systemd[1]: webmin.service failed.
[user@HOSTNAME ~]$ sudo systemctl start webmin
Job for webmin.service failed because the control process exited with error code. See "systemctl status webmin.service" and "journalctl -xe" for details.
When I tried to start it from /etc/webmin/restart, it said that it was running with PID 6554.
[user@HOSTNAME ~]$ /etc/init.d/webmin restart
Stopping Webmin server in /usr/libexec/webmin
Starting Webmin server in /usr/libexec/webmin
Webmin is already running with PID 6554
I found that the id was saved in the pid file and the process was running with the same pid.
[user@HOSTNAME ~]$ cat /webvar/webmin/miniserv.pid
6554
[user@HOSTNAME ~]$ ps -p 6554
PID TTY TIME CMD
6554 ? 00:00:00 stunnel
I think it is failing because the pid of the process before the RHEL reboot is still in the file and now another service with the same pid is running.
Is it a failure in replacing the PID file?
Shouldn't the pid file be deleted during the process of stopping the service?
webmin-1.954-1.noarch.rpm
RHEL 7.3
Thanks.
Hi,
Is this still an issue with the latest Webmin 1.973?
Last edit: Ilia 2021-04-03
Hi llia
Thank you for your comment.
I deployed Webmin 1.973 in another RHEL by rpm.
But latest Webmin failed to start too.
I set pid that is used other process to /webvar/webmin/miniserv.pid, and Webmin failed to start.
/etc/init.d/webmin files of ver 1.953 and ver 1.973 are same.
Webmin ver 1.580 in our old CentOS removes pid file in stop process, /etc/init.d/webmin.
Why the remove process was removed ?
ver 1.973 /etc/init.d/webmin
ver 1.580 /etc/init.d/webmin
Is it necessary to remove the PID file, even when the PID it contains is no longer running?
Hi Jamie
When the PID it contains is no longer running any process, Webmin can start.
But when Webmin is not running and the PID it contains is running another process, e.g. stunnel, Webmin seems to fail to start.
In miniserv.pl Line 121, Webmin check the PID the file contains and kill(0) the PID.
It doesn't check if the PID is webmin or not, Only do if the PID is running.
When the OS reboots, if the file still contains the old PID and now it is the PID of a running process that is not webmin, webmin will fail to start.
To avoid this, it may be necessary to remove the PID file when the service is stopped.
Ok, I see now. We'll add back the code to remove the old PID file.
Thank you Jamie.
And could you advice me?
I already deployed more than 100 RHEL with Webmin.
It would be nice to fix them by replaceing /etc/init.d/webmin, because Upgrade all deployed Webmin is hard.
Would I just add the code to /etc/init.d/webmin to remove the old PID file in STOP, Like in ver 1.580 ?
Or is there something to take care of ?
When you upgrade to the next release, this will be fixed.
Or you can replace /etc/init.d/webmin with this file now : https://raw.githubusercontent.com/webmin/webmin/master/webmin-init
Thank you Jamie !
I know this ticket just closed a couple days ago, but would you consider moving the miniserv.pid file to '/run' ?
It's a tmpfs that's cleared on reboots which should resolve the return of this error message if the machine in question doesn't have a clean shutdown or some other reason that may prevent the /etc/init.d/webmin from being called to stop the process.
(In which case, a reboot will solve the problem without having to hunt down the rogue pid file. )
Not all systems have a /run directory though, and I prefer to keep the Webmin paths consistent across operating systems.