Re: [systemd-devel] How to spin down a disc with systemd?
W dniu 30.04.2014 13:02, Lennart Poettering pisze: On Wed, 30.04.14 01:02, Marcin Kocur (marcin2...@gmail.com) wrote: Hello all, I wrote a service /etc/systemd/system/disable-2nd-hdd.service. I have 2 HDD's where one of them doesn't need to work all the time. So I thought it'd be cool to shut it down after 30 minutes of inactivity (the disc isn't mounted when system starts): /usr/bin/hdparm -S 241 /dev/sdb Then I wrote a service: [Unit] Description=Disable sdb Requires=local-fs.target After=local-fs.target These two lines are implied and hence can be removed. My intention was to be sure that the disc is ready to be spun down. Note that devices are probed asynchronously, and a device not needed at boot is not waited for. THis means that your service might run before the harddisk showed up in the kernel, or possibly that your hdparm command is invoked before the initializating/probing/identifying of the hdd or its filesystems is compelted, thus possibly negating the effect of your command. YOu probably want to invoke your commandn with RUN from a udev rule so that it is run when the hw is found. Thanks, I expected such situation, namely that disc is somehow probed or activated AFTER I issue hdparm command which causes it wake up again. Right. But I really expected that systemd is able to determine when the disc is ready and I can somehow pass this in Requires= or After= keys. My intention was to learn systemd a bit, not udev's hackish syntax ;p -- Pozdrawiam / Greetings Marcin Kocur █ Dane kontaktowe / Contact details: http://koci.net.pl/email ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Delaying (SSH) key generation until the urandom pool is initialized
On Wed, Apr 30, 2014 at 05:06:29PM +0200, Florian Weimer wrote: On 04/30/2014 02:28 PM, Daniel P. Berrange wrote: Interesting suggestion. I just used virt-manager to create the VM. I don't see any trace for rng or random in the domain XML file. If it is supported, I think it should be enabled by default. I'm told that it isn't turned on by default, but you can add it to a VM post-install. Since it feeds VMs from the host's /dev/random or /dev/hwrng, there was a question mark as to whether it was right to enable it by default or not, and if so what kind of rate limiting might be wanted by default. Ah, so it builds down to our distrust of hardware RNGs? How annoying. We should be able to trust Fedora-on-Fedora (or Debian-on-Debian or whatever) scenarios. But I get that in the general case, it's impossible to know what's on the other side of the virtio_rng side, so reservations remain. IIUC, the problem is that the guest or guests can exhaust hosts entropy pool, not that they distrust it. I.e. we are worried about the host, not guests. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Blog on running systemd within a docker container.
On Wed, Apr 30, 2014 at 02:21:44PM -0400, Daniel J Walsh wrote: http://rhatdan.wordpress.com/2014/04/30/running-systemd-within-a-docker-container/ Interesting. The part where you remove all the links in .wants directories seems ugly. Would it be feasible to use a custom target instead of multi-user.target? Things removed this way will come back if e.g. systemd rpm is updated inside of the image. Judicious use of systemctl mask and setting a custom preset of 'disable *' should also help. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Blog on running systemd within a docker container.
On 05/01/2014 09:28 AM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Apr 30, 2014 at 02:21:44PM -0400, Daniel J Walsh wrote: http://rhatdan.wordpress.com/2014/04/30/running-systemd-within-a-docker-container/ Interesting. The part where you remove all the links in .wants directories seems ugly. Would it be feasible to use a custom target instead of multi-user.target? Things removed this way will come back if e.g. systemd rpm is updated inside of the image. Judicious use of systemctl mask and setting a custom preset of 'disable *' should also help. Zbyszek Well I want people to be able to yum install httpd; systemctl enable httpd.service Which I believe requires the multi-user.target to work correctly. If you have better systemctl mask commands, I would love to use them instead. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
