Bug 1467839
| Summary: | Hitch does not start on reboot of the server | ||
|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Mike Parkin <mparkin> |
| Component: | hitch | Assignee: | Ingvar Hagelund <ingvar> |
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | epel7 | CC: | battery.staple, code, ingvar, mparkin, thuejk |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-01-29 09:43:43 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Mike Parkin
2017-07-05 09:40:32 UTC
I was not able to reproduce this on my freshly installed el7 system. There, hitch starts fine after boot, so I'm a bit at a loss here. Do you have several installations where this is a problem? Have you done any other changes to hitch.service in /lib/systemd/system or /etc/systemd/system? How is hitch running if you start it with systemctl start hitch.service with an unmodified service file? pgrep hitch | COLUMNS=200 xargs ps -o pid,command -p With an unmodified hitch.service, hitch does not start with the --daemon switch, so it should not fork like a daemon, but stay in the foreground - for systemd, that is. Which is what the systemd devs like best. Running in daemon mode with So using Type=forking will work of course, but systemd was designed to handle forgrounded processes well (or even better). Ingvar Ingvar, I’ve got the information you need to proceed.
Hitch won’t start on Fedora 28 after rebooting either.
Hitch doesn’t create missing folders for it’s PID file and just fails to launch. The default path is /run/hitch/hitch.pid
The folder is created in hitch.spec, but as it’s a tempfs it will disappear on reboot.
install -d -m 0755 %{buildroot}%{_localstatedir}/run/hitch
Either change the default pid in the systemd service unit to /run/hitch.pid, patch Hitch upstream to create missing folders like most other programs do, or deploy the below work-around in the default systemd service unit.
$ systemctl edit hitch.service
[Service]
ExecStartPre=-mkdir /run/hitch/
ExecStartPre=-chown hitch:hitch /run/hitch/
Specifying RuntimeDirectory=hitch in the systemd.service unit file should make systemd itself take care of this. That configuration is already present in the hitch package. I just tested again, and hitch starts without problems on my Fedora systems. If this still is a problem, please reopen this bug, and post the result of ls /*/systemd/system/hitch.service , and the contents of those files. I'm closing this for now. Ingvar In case anyone else ends up here, this is the TLDR; version of what Ingvar is saying. hitch.conf should have: daemon = off Not daemon = on I just made this mistake myself by copying and pasting a config file I found on the web. I think this is actually an error in the hitch package. Downloading and "rpm2cpio ../hitch-1.5.0-1.el7.x86_64.rpm | cpio -idmv" the newest package ( https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/h/hitch-1.5.0-1.el7.x86_64.rpm ), in hitch.conf it has > daemon = on But in hitch.service it has > Type=simple This should obviously be "Type=forking" So what I assume happens is that hitch forks and exits (since it is type=daemon), and systemd detects the exit and kills all the children. Except on my machine only during boot, and not when started on the command line for whatever reason. So when Ingvar says in comment 1 that "hitch does not start with the --daemon switch, so it should not fork like a daemon, but stay in the foreground", it is wrong for the configuration installed by default. |