Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 570494 - sys-apps/haveged starts to late with systemd
Summary: sys-apps/haveged starts to late with systemd
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Anthony Basile
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-01 13:35 UTC by Thomas
Modified: 2016-02-19 10:17 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Dependency patch (haveged.service.patch,412 bytes, patch)
2016-02-18 16:42 UTC, Thomas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas 2016-01-01 13:35:27 UTC
If using systemd haveged starts to late to give entropy for cryptsetup, for example. This bug has been fixed in other distributions such as debian already (see for example https://packages.qa.debian.org/h/haveged/news/20150904T180410Z.html ).

The following is a mixup of gentoos and debians haveged.service + a small fix from me (not sure if necessary) which works for me:

[Unit]
Description=Entropy daemon using the HAVEGE algorithm
Documentation=man:haveged(8) http://www.issihosts.com/haveged/
DefaultDependencies=no
ConditionVirtualization=!container
After=systemd-random-seed.service
Before=sysinit.target shutdown.target cryptsetup-pre.target systemd-journald.service

[Service]
EnvironmentFile=/etc/haveged.conf
ExecStart=/usr/sbin/haveged --Foreground --verbose=1 -w ${WATERMARK}
SuccessExitStatus=143
SecureBits=noroot-locked
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_SYS_ADMIN
PrivateTmp=yes
PrivateDevices=yes
PrivateNetwork=yes
ProtectSystem=full
ProtectHome=yes

[Install]
WantedBy=default.target
Comment 1 Anthony Basile gentoo-dev 2016-01-02 00:08:29 UTC
hi Thomas, I'm glad to add this for you but I am not a systemd user and I'm not conformatable just piecing these things in there without being able to test.  can you give me individual patches against the tree so i can't go wrong.

@systemd folks, please look this over.
Comment 2 Anthony Basile gentoo-dev 2016-01-02 00:08:56 UTC
@systemd folks, can you look this over
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-01-02 08:11:55 UTC
I mostly like it, though I have two questions that'd require looking at the code.

1. Type=forking vs type=simple. Does the daemon do anything before forking? If it checks config for errors, set up some sockets or do some other potentially erring out actions before fork()ing, then type=forking would be preferred. It would cause systemd to wait until the daemon forked, effectively delaying dependent services such as cryptsetup until it's ready to serve it.

On the other hand, if it forks immediately, then type=simple is fine.

2. What's exit status 143? Is that a signal? If yes, then I think you can actually use signals by name in the unit files.
Comment 4 Thomas 2016-01-02 14:53:47 UTC
(In reply to Michał Górny from comment #3)
> I mostly like it, though I have two questions that'd require looking at the
> code.

I can't answer your questions. All I did was taking the unit file from debian ( http://anonscm.debian.org/cgit/collab-maint/haveged.git/tree/debian/haveged.service ), adapting it to gentoos config file and adding cryptsetup-pre.target to the Before statement.

In the meantime I also tried to contact Gary Wuertz, the maintainer of havaged, and this is what he replied:

> I am mostly retired and haven't really kept up with systemd . I don't have any real advice, but know that SUSE and other distros have wrestled with early haveged initialization. I've attached the SUSE setup and hope it provides a useful clue. Sorry I can't be of much more help.

Here's the attachment he talked about:

[Unit]
Description=Entropy Daemon based on the HAVEGE algorithm
Documentation=man:haveged(8) http://www.issihosts.com/haveged/
DefaultDependencies=no
ConditionVirtualization=!container
#Conflicts=shutdown.target
After=systemd-random-seed.service
Before=sysinit.target shutdown.target systemd-journald.service

[Service]
ExecStart=/usr/sbin/haveged -w 1024 -v 0 -F
CapabilityBoundingSet=CAP_SYS_ADMIN
PrivateNetwork=yes
Restart=always
SuccessExitStatus=137 143

[Install]
WantedBy=sysinit.target
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-01-02 15:04:42 UTC
Ok, I've checked both things myself, and the answers are:

1. haveged only checks for invalid options before forking. So type=simple is fine. However, it prevents it from writing PID file.

2. haveged erraneously returns 128+sig rather than proper signalled exit code. So I guess hardcoding the numbers is safer.
Comment 6 Thomas 2016-01-02 15:08:21 UTC
(In reply to Michał Górny from comment #5)
> However, it prevents it from writing PID file.

Just a thought, might be wrong on this: As we try to start havaged in early boot no PID file might be a good thing as the directory for the file might not be available.
Comment 7 Anthony Basile gentoo-dev 2016-02-12 01:03:22 UTC
(In reply to Thomas from comment #6)
> (In reply to Michał Górny from comment #5)
> > However, it prevents it from writing PID file.
> 
> Just a thought, might be wrong on this: As we try to start havaged in early
> boot no PID file might be a good thing as the directory for the file might
> not be available.

any more word on this?
Comment 8 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-02-12 07:51:17 UTC
(In reply to Anthony Basile from comment #7)
> (In reply to Thomas from comment #6)
> > (In reply to Michał Górny from comment #5)
> > > However, it prevents it from writing PID file.
> > 
> > Just a thought, might be wrong on this: As we try to start havaged in early
> > boot no PID file might be a good thing as the directory for the file might
> > not be available.
> 
> any more word on this?

I don't mind either way. PID files are unnecessary for systemd but if it's written to /run, systemd should mount that very early.
Comment 9 Anthony Basile gentoo-dev 2016-02-13 15:52:34 UTC
(In reply to Michał Górny from comment #8)
> (In reply to Anthony Basile from comment #7)
> > (In reply to Thomas from comment #6)
> > > (In reply to Michał Górny from comment #5)
> > > > However, it prevents it from writing PID file.
> > > 
> > > Just a thought, might be wrong on this: As we try to start havaged in early
> > > boot no PID file might be a good thing as the directory for the file might
> > > not be available.
> > 
> > any more word on this?
> 
> I don't mind either way. PID files are unnecessary for systemd but if it's
> written to /run, systemd should mount that very early.

This doesn't help me.  Is the unit file as spelled out in comment #4 okay?
Comment 10 Thomas 2016-02-13 17:22:06 UTC
(In reply to Anthony Basile from comment #7)
> any more word on this?

No, it was just a wild thought. :)

(In reply to Michał Górny from comment #8)
> I don't mind either way. PID files are unnecessary for systemd but if it's
> written to /run, systemd should mount that very early.

I just checked my boot log and am not so sure. It seems to race with mounts and swap:

Feb 13 13:16:35 horst systemd[1]: Mounted Temporary Directory.
Feb 13 13:16:35 horst systemd[1]: Mounting /home...
Feb 13 13:16:35 horst systemd[1]: Starting Load/Save Random Seed...
Feb 13 13:16:35 horst systemd[1]: Mounted /home.
Feb 13 13:16:35 horst systemd[1]: Started Load/Save Random Seed.
Feb 13 13:16:35 horst systemd[1]: Started Entropy daemon using the HAVEGE algorithm.
Feb 13 13:16:35 horst systemd[1]: Starting Journal Service...
Feb 13 13:16:35 horst systemd[1]: Starting Cryptography Setup for swap...
Feb 13 13:16:35 horst systemd[1]: Reached target Local File Systems.
Feb 13 13:16:35 horst systemd[1]: Started Cryptography Setup for swap.
Feb 13 13:16:35 horst systemd[1]: Reached target Encrypted Volumes.

Anyway, I'm sure you know better than meand if there's anything I could do to help (like testing changes to the unit file) just tell me.

(In reply to Anthony Basile from comment #9)
> Is the unit file as spelled out in comment #4 okay?

No. That's there as a rough base from the haveged developer, the file adapted by debian, then adapted to gentoos layout is at the description (comment 0 or however you call it).
Comment 11 Anthony Basile gentoo-dev 2016-02-13 17:26:52 UTC
(In reply to Thomas from comment #10)
> 
> (In reply to Anthony Basile from comment #9)
> > Is the unit file as spelled out in comment #4 okay?
> 
> No. That's there as a rough base from the haveged developer, the file
> adapted by debian, then adapted to gentoos layout is at the description
> (comment 0 or however you call it).

Okay, I'll wait for your ack before adding this to the tree.  There is another bug out about the initd script and I was going to address both at the same time.
Comment 12 Thomas 2016-02-13 17:34:23 UTC
(In reply to Anthony Basile from comment #11)
> (In reply to Thomas from comment #10)
> > 
> > (In reply to Anthony Basile from comment #9)
> > > Is the unit file as spelled out in comment #4 okay?
> > 
> > No. That's there as a rough base from the haveged developer, the file
> > adapted by debian, then adapted to gentoos layout is at the description
> > (comment 0 or however you call it).
> 
> Okay, I'll wait for your ack before adding this to the tree.  There is
> another bug out about the initd script and I was going to address both at
> the same time.

Sorry, I'm a bit overtired, didn't realize that you are you.

So new answer: I did not test the script at comment #4 at all. It's just what SUSE uses (it doesn't even use gentoos config file). The one in comment #0 on the other side is what I'm using since around 2 months without any problems, I'm just not sure if Before=cryptsetup-pre.target is really needed (neither debian nor suse have it).

I'll try to find some time next days to adapt the version from comment #4 to gentoos layout and test it as well as testing the one from comment #0 without the cryptsetup-pre.target dependency. Is that okay? Any other things I should check?
Comment 13 Anthony Basile gentoo-dev 2016-02-13 17:53:44 UTC
(In reply to Thomas from comment #12)

> Sorry, I'm a bit overtired, didn't realize that you are you.

who else would i be but me :)

> 
> So new answer: I did not test the script at comment #4 at all. It's just
> what SUSE uses (it doesn't even use gentoos config file). The one in comment
> #0 on the other side is what I'm using since around 2 months without any
> problems, I'm just not sure if Before=cryptsetup-pre.target is really needed
> (neither debian nor suse have it).
> 
> I'll try to find some time next days to adapt the version from comment #4 to
> gentoos layout and test it as well as testing the one from comment #0
> without the cryptsetup-pre.target dependency. Is that okay? Any other things
> I should check?

I'll pretty much put anything in the tree you say is good and is okay with the systemd folks because I've got no good system for testing system.  I have systemd boxes but not good for testing, maybe I should set a vm up.
Comment 14 Thomas 2016-02-18 16:42:46 UTC
Created attachment 425844 [details, diff]
Dependency patch

So today I did some testing. First off, having cryptsetup-pre.target in the Before statement isn't needed. Second: I don't know what most of the changes do, so I reverted them. The result is a 3 line patch which works for me.
Comment 15 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-02-18 17:03:26 UTC
I'm pretty sure it is needed if you want it started before cryptsetup. Otherwise, you have a race.
Comment 16 Thomas 2016-02-19 08:15:19 UTC
(In reply to Michał Górny from comment #15)
> I'm pretty sure it is needed if you want it started before cryptsetup.
> Otherwise, you have a race.

I thought so, too. That's why I added it in the first place. Anyway, I always wondered about it cause neither suse nor debian nor any other distro I'm aware of added this while fixing the exact same bug. That's why I tested it and my testing shows it's really not needed.
Please note I'm no systemd expert, so the following might be wrong but it's what I think what happens: Yes, there is a race but cryptsetup freezes until there's enough entropy available no matter what, so it waits for haveged and as a result solves the race by design.
Comment 17 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-02-19 10:17:16 UTC
Well, it all depends on what result do you expect. Indeed if you only care that it does not wait for cryptsetup, this is fine. And I guess it is fine to proceed like this.