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
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.
@systemd folks, can you look this over
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.
(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
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.
(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.
(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?
(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.
(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?
(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).
(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.
(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?
(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.
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.
I'm pretty sure it is needed if you want it started before cryptsetup. Otherwise, you have a race.
(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.
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.
