Re: [systemd-devel] proper way to shutdown/reboot host with systemd
On 08/26/2014 11:54 AM, Vasiliy Tolstov wrote: 2014-08-26 21:32 GMT+04:00 Lennart Poettering lenn...@poettering.net: From which language? From C, I'd recommend issuing the PowerOff() method on logind's manager object via the bus. From the shell, i'd recommend systemctl poweroff, which does exactly that. Thanks, but does it possible to shutdown system via reboot syscall for example with LINUX_REBOOT_CMD_POWER_OFF ? No. http://linux.die.net/man/2/reboot Note the repeating statement of If not preceded by a sync(2), data will be lost. I would follow Lennart's advice. - Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-resolved cannot survive router reinstall
So the problem is not in networkd, sorry for the noise. The problem is in OpenWRT that uses dnsmasq and stores dhcp lease information on tmpfs. If I reboot the router it looses all the leases and machines should update the information somehow. This is a problem for machines in a separate network segment. I can not believe that OpenWRT developers never tested such configuration. I am going to contact openwrt/dnsmasq maillist and ask what is the right way to solve the issue. I suspect they know about this but are not concerned. Many DHCP servers (I believe OpenWRT does as well) performs an arp check before giving out an ip address. Thus, even if they loose the lease table, IP conflicts should be impossible. PS According to off-list discussion with Tom FORCERENEW dhcp option http://tools.ietf.org/html/rfc3203 is what suppose to fix this issue. But dnsmasq does not support it. This seems like a nice extension, OpenWRT would probably be open to this. I suspect this would get implemented such that if the DHCP server detects an unknown IP in its lease range it sends FORCERENEW to it. - Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
On 08/20/2014 06:46 AM, Dale R. Worley wrote: From: Lennart Poettering lenn...@poettering.net Note that a concept of mount at boot if it is there, otherwise don't cannot work. It worked until a week or two ago. I want it back. I'm sure you're right that in the abstract, it cannot be made to work. But that isn't the problem I'm facing. It seems that a workaround could be to not put the volume in fstab and add a unit to the startup that would mount it if present. If you wanted to mount it later, you could manually start the unit again. Regards, Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Networkd dhcp hostname override
Typically the send-hostname thing is actually used for DNS updates, where you send the hostname to the DHCP server, which then gives you a lease and sends the hostname + IP to the DNS server, so that your machine is accessible via DNS automatically. I've never heard of it being used as a Client ID, and AFAIK the send hostname and client ID can both be used at the same time. Yes. In my network the Host Name dhcp option is used to configure dns. I am attempting to use a single machine to operate several instances of the same server. Therefore I need to bind each server to a unique IP. Currently I use macvlan and dhcpcd to have the dns entries created. this means that allowing to provide a custom hostname that is not set via hostname or hostnamectl makes no sense at all. I will agree that conventionally in the linux world the hostname is for the system itself and not per interface. I suppose it needs to be decided whether it is tolerable for this convention to be bent in networkd. Bridged virtual machines effectively do the same thing, but one could argue it isn't really the same machine. Since you want to send your actual hostname. In this case I don't, I want to specify a custom host name for dhcp on a specific interface. So current boolean for SendHostname is the right way to do this. In addition someone might add a ClientId=foo option. I am not very familiar with the Client ID. It appears to only be useful to change if you wanted multiple dhcp leases with the same hardware address, which I have avoided with macvlans. Regards, Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Networkd dhcp hostname override
It's used as a general identifier of the client in any situation, so that the server can pass back specific options. Yes, this can be done by looking at the client MAC address, but that's not sufficient in the following cases: 1) non-Ethernet hardware addresses 2) dual-stack clients using DHCPv4 and DHCPv6 3) you change the NIC and want the same options 4) the NIC doesn't have a permanent MAC address The client ID (and on the DHCPv6 side, the DUID) is the single-identifier solution that should really be used instead of the MAC address. Touché - Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] networkd Promiscuous mode
There seems to be no way in systemd-networkd to put a link in Promiscuous mode. This is needed to make macvlan work correctly (Otherwise it receives no traffic with its mac address as the destination). If I am not mistaken this could be a boolean in *.link files. - Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
