Re: [systemd-devel] is-enabled and generated units
2015-06-14 11:17 GMT+02:00 Igor Bukanov i...@mir2.org: Hello, I noticed that running `systemctl is-enabled foo.service` against a service written by a generator fails with a puzzling error message: Failed to get unit file state for foo.service: No such file or directory when I expected that the command succeeds and prints enabled-runtime as the unit was enabled through a target file /run/systemd/generator/multi-user.target.d/foo.conf containing: [Unit] Wants=foo.service Just curious: why don't you use /run/systemd/generator/multi-user.target.wants/foo.service → symlink to the generated file foo.service? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is-enabled and generated units
В Sun, 14 Jun 2015 12:36:39 +0200 Igor Bukanov i...@mir2.org пишет: On 14 June 2015 at 12:22, Andrei Borzenkov arvidj...@gmail.com wrote: So it can be discussed what should be returned in this case, but in any case systemctl is-enabled is not expected to return enabled-runtime here. Indeed, I see that it should not be `enabled-runtime` as the unit does not contain [Install]. Still why systemctl does not return `static` in this case but fails with an error message? I also see that systemctl fails with the same error message for generated units that are linked via .wants under /run/systemd/generator when my expectation is that the command should succeed and print `linked-runtime`. Currently generator paths are explicitly excluded from systemctl operations. I think systemd should distinguish between runtime and generators. One reason is, generated units are meant to be enabled by definition - they are usually created to be included in transaction. So if something should be returned it should be generated; not sure which qualifications make sense here. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd: option for IPv6 privacy extension?
Hi,
I'm wondering if systemd-networkd could provide an option to control the
IPv6 privacy extension? It is controlled via a sysctl setting:
net.ipv6.conf.${interface}.use_tempaddr
with three values:
= 0 : disable Privacy Extensions
== 1 : enable Privacy Extensions, but prefer public
addresses over temporary addresses.
1 : enable Privacy Extensions and prefer temporary
addresses over public addresses.
-- Documentation/networking/ip-sysctl.txt
It would be nice if systemd-networkd would allow to control these
options, for example by a IP6Privacy setting in the Address section of
.network units (NetworkManager already uses ip6-privacy).
Ansgar
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is-enabled and generated units
On 14 June 2015 at 12:10, Andrei Borzenkov arvidj...@gmail.com wrote: Not really. systemctl enable|disable|is-enabled explicitly work on links defined by [Install] section only. This is not true. According to systemctl is-enabled man page for services without [Install] the command should succeed and print static, not fail with an error message. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why we need to read/save random seed?
On Sun, Jun 14, 2015 at 4:21 PM, cee1 fykc...@gmail.com wrote: Hi all, Why we need to read/save random seed? Can it be read from /dev/random each time? Well, that would sorta defeat the point. The random seed isn't for systemd's use. On boot, it is *written to* /dev/random, not read from it. Early during boot, the system has very little entropy available from other sources, so it is common to save some random data from last boot and provide it to the PRNG later. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Improve boot-time of systemd-based device, revisited
Hi all, I've recently got another chance to improve the boot-time of a systemd-based device. I'd like to share the experience here, and some thoughts and questions. The first time I tried to improve the boot-time of systemd: http://lists.freedesktop.org/archives/systemd-devel/2011-March/001707.html, after that, we have systemd-bootchart and systemd-analyze, which help a lot. It seems the biggest challenge of reducing boot-time of the ARM board at hand is taking are of the poor I/O performance: * A single fgets() call may randomly cause 200-300ms * A (big)service may spend 2-3s to complete its so loading - only ~100ms spent on CPU. I tried to first delay services which are less important, to save the I/O bandwidth in the early stage, and raise the priority of important services to SCHED_RR/IOPRIO_CLASS_RT: 1. I need to find the top I/O hunger processes (and then delay them if not important), but it's not straightforward to figure it out in bootchart, so adding *** iotop feature *** in bootchart seems very useful. 2. I think raising CPU scheduling priority works because it reduces chances of issuing I/O requests from other processes. Some thoughts: * The priority feature of I/O scheduler(CFQ) seems not work very well - IDLE I/O can still slow down Normal/RT I/O [1] * I don't know the detail of CFQ, but I wonder whether a rate limit helps - may reduce the latency between issuing I/O command and full filling the command? Last, I tried some readahead(ureadahead), but not do the magic, I guess it's because I/O is busy in the early stage, there's simply no ahead chance. What readahead helps, IMHO, is a snapshot of accessed disk blocks during boot up, in the order of they're requested. Thus a linear readahead against the snapshot will always read ahead of actual requesting blocks. BTW, systemd-bootchart has a option to chart entropy, how is the entropy involved in boot up procedure? --- 1. http://linux-kernel.vger.kernel.narkive.com/0FC8rduf/ioprio-set-idle-class-doesn-t-work-as-its-name-suggests Regards, - cee1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Q systemd.path
On Sat, Jun 13, 2015 at 10:39:24PM -0700, Eric Lu wrote: Hi, I tested the functionality of system.path in a Fedora 21 workstation. The script was executed even though the file specified in PathExists=, /var/tmp/tst0, did not exist. Is there something I misunderstand or : Basically, you have enabled tst.service to be started during boot. So it is started no matter if file exists or not. You have also enabled tst.path, so tst.service should be started again when the file appear. You should only enable .path unit. Additionaly, you can guard execution of .service by ConditionPathExists= (or similar, check man systemd.unit). [root@f21 ylu]# systemctl status tst â tst.service - Tst Controller Service Loaded: loaded (/etc/systemd/system/tst.service; enabled) ^^^ it's enabled Active: inactive (dead) since Sat 2015-06-13 21:08:37 PDT; 1min 18s ago Process: 853 ExecStart=/usr/sbin/tst.sh (code=exited, status=0/SUCCESS) Main PID: 853 (code=exited, status=0/SUCCESS) [root@f21 ylu]# cat /etc/systemd/system/tst.path [Unit] Description=Activate test Service # DefaultDependencies=no [Path] PathExists=/var/tmp/tst0 Unit=tst.service # [Install] # WantedBy=multi-user.target No install instructions for tst.path. [root@f21 ylu]# cat /etc/systemd/system/tst.service [Unit] Description=Tst Controller Service [Service] Type=oneshot Environment=TERM=linux # NotifyAccess=all ExecStart=/usr/sbin/tst.sh [Install] Also=tst.path WantedBy=multi-user.target tst.service install instruction. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is-enabled and generated units
В Sun, 14 Jun 2015 11:17:03 +0200 Igor Bukanov i...@mir2.org пишет: Hello, I noticed that running `systemctl is-enabled foo.service` against a service written by a generator fails with a puzzling error message: Failed to get unit file state for foo.service: No such file or directory when I expected that the command succeeds and prints enabled-runtime as the unit was enabled through a target file /run/systemd/generator/multi-user.target.d/foo.conf containing: [Unit] Wants=foo.service Is it a bug? Not really. systemctl enable|disable|is-enabled explicitly work on links defined by [Install] section only. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is-enabled and generated units
The reason for .d + .conf, not .wants, is that in my case .conf file contains several Wants directives including one for a service that is installed but not not enabled by default. As I do not know the location of that service unit file (depending on OS or installation it can be under /usr/lib, /usr/lib64, /etc/ /run/), I use the .conf fragment as there the Wants does not require to specify an absolute path. On 14 June 2015 at 11:52, Michael Biebl mbi...@gmail.com wrote: 2015-06-14 11:17 GMT+02:00 Igor Bukanov i...@mir2.org: Hello, I noticed that running `systemctl is-enabled foo.service` against a service written by a generator fails with a puzzling error message: Failed to get unit file state for foo.service: No such file or directory when I expected that the command succeeds and prints enabled-runtime as the unit was enabled through a target file /run/systemd/generator/multi-user.target.d/foo.conf containing: [Unit] Wants=foo.service Just curious: why don't you use /run/systemd/generator/multi-user.target.wants/foo.service → symlink to the generated file foo.service? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is-enabled and generated units
В Sun, 14 Jun 2015 12:16:09 +0200 Igor Bukanov i...@mir2.org пишет: On 14 June 2015 at 12:10, Andrei Borzenkov arvidj...@gmail.com wrote: Not really. systemctl enable|disable|is-enabled explicitly work on links defined by [Install] section only. This is not true. According to systemctl is-enabled man page for services without [Install] the command should succeed and print static, not fail with an error message. It's not what you said originally :) when I expected that the command succeeds and prints enabled-runtime as the unit was enabled through a target file So it can be discussed what should be returned in this case, but in any case systemctl is-enabled is not expected to return enabled-runtime here. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] is-enabled and generated units
Hello, I noticed that running `systemctl is-enabled foo.service` against a service written by a generator fails with a puzzling error message: Failed to get unit file state for foo.service: No such file or directory when I expected that the command succeeds and prints enabled-runtime as the unit was enabled through a target file /run/systemd/generator/multi-user.target.d/foo.conf containing: [Unit] Wants=foo.service Is it a bug? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is-enabled and generated units
On 14 June 2015 at 12:22, Andrei Borzenkov arvidj...@gmail.com wrote: So it can be discussed what should be returned in this case, but in any case systemctl is-enabled is not expected to return enabled-runtime here. Indeed, I see that it should not be `enabled-runtime` as the unit does not contain [Install]. Still why systemctl does not return `static` in this case but fails with an error message? I also see that systemctl fails with the same error message for generated units that are linked via .wants under /run/systemd/generator when my expectation is that the command should succeed and print `linked-runtime`. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Why we need to read/save random seed?
Hi all, Why we need to read/save random seed? Can it be read from /dev/random each time? -- Regards, - cee1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why we need to read/save random seed?
On Sun, 14.06.15 14:11, Cristian Rodríguez (cristian.rodrig...@opensuse.org) wrote: On Sun, Jun 14, 2015 at 1:43 PM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Jun 14, 2015 at 12:49:55PM -0300, Cristian Rodríguez wrote: El jun. 14, 2015 10:21, cee1 fykc...@gmail.com escribió: Hi all, Why we need to read/save random seed? Can it be read from /dev/random each time? Because the kernel is borked and still is needs to be fed of entropy at system startup by user space. Please read the random man page. I agree we shouldn't have to do this at all.. Really? And how do you suggest we fix the kernel when the hardware itself doesn't provide us with a proper random number seed in the first place? What do you suggest we do instead? Las time I checked , it required this userspace help even when the machine has rdrand/rdseed or when a virtual machine is fed from the host using the virtio-rng driver.. (may take up to 60 seconds to report I am pretty sure that even if you have rdrand/rdseed you want to seed the system with randomness from a previous boot, simply because you might not want to trust the CPU's RNG. Sure, it's great that Intel CPUs have that now, but given the circumstances, are you sure the stuff is not backdoored by your three-letter agency of choice? I mean, this is a bit like with modern SSDs with hardware encryption: it's great that they have this, but can you really trust it? Haveing the hdd crypto stuff in kernel, and a random seed that is not just the CPU's own hwrng has the benefit that the sources are open and you review what's going on. That much harder with silicon you buy in a shop. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [survey] BTRFS_IOC_DEVICES_READY return status
On 2015-06-14 06:05, Duncan wrote: Goffredo Baroncelli posted on Sat, 13 Jun 2015 17:09:19 +0200 as excerpted: My attempt followed a different idea: the mount helper waits the devices if needed, or if it is the case it mounts the filesystem in degraded mode. All devices are passed as mount arguments (--device=/dev/sdX), there is no a device registration: this avoids all these problems. [*] http://permalink.gmane.org/gmane.comp.file-systems.btrfs/40767 But /dev/sdX doesn't always work, because, for instance, my usual /dev/sdb was slow to respond on my last boot, and currently appears as /dev/sdf, with sdb/c/d/e being my (multi-type) sdcard, etc, adapter, medialess. Please give a look to my patch. You may mount the filesystem in different way: - by device (/dev/sdxxx) - by UUID (UUID=) - by LABEL (LABEL=) The helper finds the right devices and (eventually) waits for the other devices. When it has collected all the devices, these are passed to the kernel via the device=/dev/sdx mount option. So the registration would not be needed anymore. Tho if /dev/disk/by-*/* works, I could use that. Tho AFAIK it's udev that fills that in, so udev would be necessary. I never wrote that udev is not necessary. I think only that relying to udev to handling a multi-volume filesystem is too complicated. The responsibility is spread in too much layer. -- gpg @keyserver.linux.it: Goffredo Baroncelli kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd: option for IPv6 privacy extension?
On Sun, 14.06.15 15:32, Ansgar Burchardt (ans...@43-1.org) wrote:
Hi,
I'm wondering if systemd-networkd could provide an option to control the
IPv6 privacy extension? It is controlled via a sysctl setting:
net.ipv6.conf.${interface}.use_tempaddr
with three values:
= 0 : disable Privacy Extensions
== 1 : enable Privacy Extensions, but prefer public
addresses over temporary addresses.
1 : enable Privacy Extensions and prefer temporary
addresses over public addresses.
-- Documentation/networking/ip-sysctl.txt
It would be nice if systemd-networkd would allow to control these
options, for example by a IP6Privacy setting in the Address section of
.network units (NetworkManager already uses ip6-privacy).
Sure. Sounds useful to support. Added to TODO list.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why we need to read/save random seed?
El jun. 14, 2015 10:21, cee1 fykc...@gmail.com escribió: Hi all, Why we need to read/save random seed? Can it be read from /dev/random each time? Because the kernel is borked and still is needs to be fed of entropy at system startup by user space. Please read the random man page. I agree we shouldn't have to do this at all.. -- Regards, - cee1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why we need to read/save random seed?
On Sun, Jun 14, 2015 at 12:49:55PM -0300, Cristian Rodríguez wrote: El jun. 14, 2015 10:21, cee1 fykc...@gmail.com escribió: Hi all, Why we need to read/save random seed? Can it be read from /dev/random each time? Because the kernel is borked and still is needs to be fed of entropy at system startup by user space. Please read the random man page. I agree we shouldn't have to do this at all.. Really? And how do you suggest we fix the kernel when the hardware itself doesn't provide us with a proper random number seed in the first place? What do you suggest we do instead? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why we need to read/save random seed?
On Sun, Jun 14, 2015 at 1:43 PM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Jun 14, 2015 at 12:49:55PM -0300, Cristian Rodríguez wrote: El jun. 14, 2015 10:21, cee1 fykc...@gmail.com escribió: Hi all, Why we need to read/save random seed? Can it be read from /dev/random each time? Because the kernel is borked and still is needs to be fed of entropy at system startup by user space. Please read the random man page. I agree we shouldn't have to do this at all.. Really? And how do you suggest we fix the kernel when the hardware itself doesn't provide us with a proper random number seed in the first place? What do you suggest we do instead? Las time I checked , it required this userspace help even when the machine has rdrand/rdseed or when a virtual machine is fed from the host using the virtio-rng driver.. (may take up to 60 seconds to report random: nonblocking pool is initialized) Any other possible solution that I imagined involves either blocking and/or changes in the behaviour visible to userspace and that is probably unacceptable . The random-seed tool also does not increment the entropy count (It writes to /dev/random instead of using the ioctls) so the ultimate result is still a system with very little entropy to go on, only starting rngd or haveged *very* early in the boot sequence seem to help. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why we need to read/save random seed?
On Sun, Jun 14, 2015 at 02:11:53PM -0300, Cristian Rodríguez wrote: On Sun, Jun 14, 2015 at 1:43 PM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Jun 14, 2015 at 12:49:55PM -0300, Cristian Rodríguez wrote: El jun. 14, 2015 10:21, cee1 fykc...@gmail.com escribió: Hi all, Why we need to read/save random seed? Can it be read from /dev/random each time? Because the kernel is borked and still is needs to be fed of entropy at system startup by user space. Please read the random man page. I agree we shouldn't have to do this at all.. Really? And how do you suggest we fix the kernel when the hardware itself doesn't provide us with a proper random number seed in the first place? What do you suggest we do instead? Las time I checked , it required this userspace help even when the machine has rdrand/rdseed or when a virtual machine is fed from the host using the virtio-rng driver.. (may take up to 60 seconds to report random: nonblocking pool is initialized) Any other possible solution that I imagined involves either blocking and/or changes in the behaviour visible to userspace and that is probably unacceptable . Really? A lot of changes went into seeding the initial random generator in the kernel in the past year, you might want to try it out again. The random-seed tool also does not increment the entropy count (It writes to /dev/random instead of using the ioctls) so the ultimate result is still a system with very little entropy to go on, only starting rngd or haveged *very* early in the boot sequence seem to help. Then why not fix the random-seed tool to use the correct interface? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is-enabled and generated units
On Sun, 14.06.15 11:17, Igor Bukanov (i...@mir2.org) wrote: Hello, I noticed that running `systemctl is-enabled foo.service` against a service written by a generator fails with a puzzling error message: Failed to get unit file state for foo.service: No such file or directory when I expected that the command succeeds and prints enabled-runtime as the unit was enabled through a target file /run/systemd/generator/multi-user.target.d/foo.conf containing: [Unit] Wants=foo.service Is it a bug? Well, yes. We should include the generator unit dirs in the unit search paths for the enable/disable/is-enabled code, and we currently don't, hence don't even see the unit if you call that code. We should add it. Added to the TODO list. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why we need to read/save random seed?
On Sun, Jun 14, 2015 at 6:45 PM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Jun 14, 2015 at 02:11:53PM -0300, Cristian Rodríguez wrote: On Sun, Jun 14, 2015 at 1:43 PM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Jun 14, 2015 at 12:49:55PM -0300, Cristian Rodríguez wrote: El jun. 14, 2015 10:21, cee1 fykc...@gmail.com escribió: Hi all, Why we need to read/save random seed? Can it be read from /dev/random each time? Because the kernel is borked and still is needs to be fed of entropy at system startup by user space. Please read the random man page. I agree we shouldn't have to do this at all.. Really? And how do you suggest we fix the kernel when the hardware itself doesn't provide us with a proper random number seed in the first place? What do you suggest we do instead? Las time I checked , it required this userspace help even when the machine has rdrand/rdseed or when a virtual machine is fed from the host using the virtio-rng driver.. (may take up to 60 seconds to report random: nonblocking pool is initialized) Any other possible solution that I imagined involves either blocking and/or changes in the behaviour visible to userspace and that is probably unacceptable . Really? Yes, this is why for example you will find an haveged dracut module that SUSE added during the SLE 12 development. to start entropy feed from user-space as early as possible this is not because folks are crazy but because it took way too long to initialize at that time.. A lot of changes went into seeding the initial random generator in the kernel in the past year, you might want to try it out again. Sure, I will check it again.. The random-seed tool also does not increment the entropy count (It writes to /dev/random instead of using the ioctls) so the ultimate result is still a system with very little entropy to go on, only starting rngd or haveged *very* early in the boot sequence seem to help. Then why not fix the random-seed tool to use the correct interface? yeah, I think we should take a look on this too. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why we need to read/save random seed?
On Jun 14, 2015 10:11 AM, Cristian Rodríguez cristian.rodrig...@opensuse.org wrote: On Sun, Jun 14, 2015 at 1:43 PM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Jun 14, 2015 at 12:49:55PM -0300, Cristian Rodríguez wrote: Las time I checked , it required this userspace help even when the machine has rdrand/rdseed or when a virtual machine is fed from the host using the virtio-rng driver.. (may take up to 60 seconds to report random: nonblocking pool is initialized) Any other possible solution that I imagined involves either blocking and/or changes in the behaviour visible to userspace and that is probably unacceptable . I added the following text to Wikipedia's /dev/random page. With Linux kernel 3.16 and newer, the kernel itself mixes data from hardware random number generators https://en.wikipedia.org/wiki/Hardware_random_number_generator into/dev/random on a sliding scale based on the definable entropy estimation quality of the HWRNG. This means that no userspace daemon, such as rngd from rng-toolsis needed to do that job. With Linux kernel 3.17+, the VirtIO RNG was modified to have a default quality defined above 0, and as such, is currently the only HWRNG mixed into /dev/random by default. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Understanding DHCP, DNS and IPMasquerade
On Fri, 12.06.15 17:32, Johannes Ernst (johannes.er...@gmail.com) wrote: I was expecting: * container gets an IP address from host in some new subnet: WORKS, e.g 10.0.0.2 * container can route to upstream via IPMasquerade: WORKS, after manual 'modprobe iptable_nat' * container gets the DNS server from the host: FAILS: /etc/resolv.conf points to Google name servers instead (8.8.8.8 etc) This is a missing feature of the DHCP server in networkd: it should be able to propagate the DNS servers it learned on the external networks automatically in a smart way. It's on the TODO list to add this. * host and container can ping test (if test is the name of the * container machine per machinectl): FAILS, neither can Do you have nss-mymachines enabled in /etc/nsswitch.conf? Does pinging via the IP addresses work? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Understanding DHCP, DNS and IPMasquerade
On Sat, 13.06.15 13:55, Johannes Ernst (johannes.er...@gmail.com) wrote: [Match] Type=ethernet [Network] DHCP=ipv4 I did. No change. I do receive the IP address (so DHCP IP assignment is working) but I do not receive the DNS server. No need to have an explicit file for this BTW, we ship one anyway out of the box, that only matches in container environments with veth links: /usr/lib/systemd/network/80-container-host0.network Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Pass environment variables down to systemd-service in container
On Fri, 12.06.15 17:50, Peter Paule (systemd-de...@fedux.org) wrote: Hi there, is there a chance to pass (the given) environment variables down to `unicorn` and `delayed_job-worker`? systemd (host) | - docker-app.service Environment=RAILS_ENV=production Environment=DATABASE_URL=postgresql://localhost/app_development | - docker | - systemd (container) | - unicorn (ruby) | - delayed_job-worker (ruby) Background: I need to wrap a rails application within CentOS-image. To make the image re-usable I decided to use the DATABASE_URL-environment variable to configure the database. I also need to switch the RAILS_ENV. I'm using this image here https://registry.hub.docker.com/u/feduxorg/centos/dockerfile/. It's based on the official docker image which uses the `systemd-container`-package from CentOS. Nope, we deliberately clean up the env block we pass to services. You can reimport the env vars though by reading them from /proc/1/environ. Needs some manual hackery though... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Q systemd.path
Thomasz, Really appreciate your helps. It works perfectly now after taking your instructions. --Regards,Eric Lu On Sunday, June 14, 2015 2:39 AM, Tomasz Torcz to...@pipebreaker.pl wrote: On Sat, Jun 13, 2015 at 10:39:24PM -0700, Eric Lu wrote: Hi, I tested the functionality of system.path in a Fedora 21 workstation. The script was executed even though the file specified in PathExists=, /var/tmp/tst0, did not exist. Is there something I misunderstand or …: Basically, you have enabled tst.service to be started during boot. So it is started no matter if file exists or not. You have also enabled tst.path, so tst.service should be started again when the file appear. You should only enable .path unit. Additionaly, you can guard execution of .service by ConditionPathExists= (or similar, check man systemd.unit). [root@f21 ylu]# systemctl status tst â tst.service - Tst Controller Service Loaded: loaded (/etc/systemd/system/tst.service; enabled) ^^^ it's enabled Active: inactive (dead) since Sat 2015-06-13 21:08:37 PDT; 1min 18s ago Process: 853 ExecStart=/usr/sbin/tst.sh (code=exited, status=0/SUCCESS) Main PID: 853 (code=exited, status=0/SUCCESS) [root@f21 ylu]# cat /etc/systemd/system/tst.path [Unit] Description=Activate test Service # DefaultDependencies=no [Path] PathExists=/var/tmp/tst0 Unit=tst.service # [Install] # WantedBy=multi-user.target No install instructions for tst.path. [root@f21 ylu]# cat /etc/systemd/system/tst.service [Unit] Description=Tst Controller Service [Service] Type=oneshot Environment=TERM=linux # NotifyAccess=all ExecStart=/usr/sbin/tst.sh [Install] Also=tst.path WantedBy=multi-user.target tst.service install instruction. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
