Bug 808890 - dhcpd service disabled by upgrade from F16 to F17
Summary: dhcpd service disabled by upgrade from F16 to F17
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 17
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-01 14:42 UTC by Jonathan Kamens
Modified: 2012-04-02 16:21 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-02 16:21:01 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jonathan Kamens 2012-04-01 14:42:55 UTC
The dhcpd service, which was enabled prior to the upgrade, was disabled after
upgrading from F16 to F17 as per
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum.

I suspect this is because it was converted from initscripts to systemd.

The instructions at the URL referenced above say to check which services are
enabled before upgrading to F16 and re-enable them afterward, but it doesn't
say the same thing about upgrading to F17.

If there are services being converted from initscripts to systemd in F17, then
either (a) they need to automatically save and restore their status during the
upgrade, or (b) the instructions at the URL mentioned above need to explain how
to preserve the status of those services when upgrading.

Comment 1 Jiri Popelka 2012-04-02 10:39:23 UTC
(In reply to comment #0)
> The dhcpd service, which was enabled prior to the upgrade, was disabled after
> upgrading from F16 to F17 as per
> https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum.
> 
> I suspect this is because it was converted from initscripts to systemd.

No, this is not the case, the conversion happened in F15.

I have no idea what went wrong but changing component to systemd as there could be some bug I'm not aware of.

Comment 2 Michal Schmidt 2012-04-02 10:59:36 UTC
What were the exact versions of the dhcp package before/after the upgrade? You can look into yum history to find out.

Did you have the symlink /etc/systemd/system/multi-user.target.wants/dhcpd.service before the upgrade? Did it disappear during the upgrade?

Comment 3 Jonathan Kamens 2012-04-02 15:56:26 UTC
(In reply to comment #2)
> What were the exact versions of the dhcp package before/after the upgrade? You
> can look into yum history to find out.

ID     | Action(s)      | Package
-------------------------------------------------------------------------------
   750 | Updated        | dhcp-12:4.2.3-18.P2.fc17.x86_64                    EE
   750 | Update         |      12:4.2.3-24.P2.fc17.x86_64                    EE
   749 | Updated        | dhcp-12:4.2.3-6.P2.fc16.x86_64                     EE
   749 | Update         |      12:4.2.3-18.P2.fc17.x86_64                    EE

> Did you have the symlink
> /etc/systemd/system/multi-user.target.wants/dhcpd.service before the upgrade?

Yes.

> Did it disappear during the upgrade?

I don't know if that particular link disappeared, but I do know that when I ran "systemctl enable dhcpd.service" it said that it had created a link. I didn't notice which link it said it had created.

Comment 4 Michal Schmidt 2012-04-02 16:10:40 UTC
In F16 the symlink pointed to /lib/systemd/system/dhcpd.service.
In F17 systemctl the target is /usr/lib/systemd/system/dhcpd.service.

The service would be started even with the symlink pointing to the old location though. It is possible that "systemctl enable dhcpd.service" said it created the symlink merely because it updated it with the new location. But that should be of no practical significance.

Are you sure the service did not start after the upgrade to F17? What exactly made you try running "systemctl enable dhcpd.service"?

Comment 5 Jonathan Kamens 2012-04-02 16:21:01 UTC
It appears you're right. It looks like it started up after the upgrade but failed for a different reason, and when systemctl said it was creating the link, it's just because it was changing it to point at /usr/lib instead. Sorry for the false alarm.


Note You need to log in before you can comment on or make changes to this bug.