I retract patch and recipe mentioned in the initial report. The problem is messier than I initially thought.
One fundamental consideration is that apparently systemctl won't start a service that is marked active, and won't stop a service that is marked inactive. This is inconsistent with longstanding initscript behavior, where you can start (or stop) something as many times as you like. 0) Simple question: Is there a way to teach the system to ignore the nominal state and just run ExecStart or ExecStop as directed? Maybe type=stateless rather than type=oneshot? This would make things a whole lot simpler. 1) Arguably "most" of the problem goes away if we document "restart" (as in "systemctl restart systemd-random-seed") as the proper way to refresh the seed. That leaves init.d/urandom in a bad state, because it knows nothing of "restart". 2) Here's another approach to consider: A paire of separate services: systemctl start systemd-random-seed-load and systemctl start systemd-random-seed-save The latter is /started/ (not stopped!) at shutdown time. Neither service has an ExecStop method. Neither service ever becomes active. Either one can be started as many times as desired, in any order. This is the only way I can think of to capture the semantics of the longstanding init.d/urandom script. The present systemd-random-seed script can trivially be reimplemented in terms of the new pair of services. This approach (2) would still require some changes to init.d/urandom, but not quite as ugly as approach (1) would require. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1652381 Title: systematic way to refresh the random-seed again and again Status in systemd package in Ubuntu: New Bug description: Background and rationale: There ought to be a nice systematic way to refresh the random-seed again and again, while the system is running normally, not just at boot time or at shutdown time. Sometimes a system may crash without carrying out an orderly shutdown. Indeed some systems never carry out an orderly shutdown; they run until they die. Therefore all the reasons why it is important to refresh the random-seed during shutdown are also good reasons for refreshing it from time to time during normal operations ... not just at startup. Desired behavior: The logical, systematic, traditional, and expected way to refresh the seed would be either "systemctl start systemd- random-seed" or equivalently "/etc/init.d/urandom start". The command should happily run as many times as desired, and should refresh the random-seed each time. Observed behavior: "systemctl start systemd-random-seed" doesn't have the desired effect. Apparently systemd considers the previous instance of systemd-random-seed.service to be still active, so additional starts don't do any good. Furthermore, "/etc/init.d/urandom start" has been re-implemented in terms of "systemctl start systemd-random-seed", so that doesn't work either. This is a significant regression relative to the pre-systemd behavior. Constructive suggestion. See attached patch. Recipe: :; systemctl start systemd-random-seed -- Observe that /var/lib/systemd/random-seed does not get refreshed. :; systemctl stop systemd-random-seed -- Apply the patch. :; systemctl daemon-reload :; systemctl start systemd-random-seed :; sleep 60 :; systemctl start systemd-random-seed -- observe that the seed now does get refreshed. There may be other ways of dealing with the issue, but this seems nice and simple. Tangent: In a non-essential way, this might touch on decisions about how best to address https://bugs.launchpad.net/bugs/1651947 Digression: There is a policy question as to how often to refresh the seed during normal operations. That is a question for another day. ------------------- Observed on :; lsb_release -rd Description: Ubuntu 16.04.1 LTS Release: 16.04 :; apt-cache policy systemd systemd: Installed: 229-4ubuntu13 Candidate: 229-4ubuntu13 Version table: *** 229-4ubuntu13 500 500 http://ubuntu.cs.utah.edu/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 229-4ubuntu10 500 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 229-4ubuntu4 500 500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1652381/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
