[systemd-devel] systemd.mount creating mount resource (What) for bind mounts
Hello, I see that a mount unit with `Options=bind` set creates the resource to be mounted, specified by `What`, in addition to the mount point, specified by `Where`, when they don't exist. Manual page at https://www.freedesktop.org/software/systemd/man/systemd.mount.html mentions that the mount point will be created if it doesn't exist for `Where`. But doesn't mention that this applies to `What` too in the case of bind mounts. I think this is the change that added this behaviour: https://github.com/systemd/systemd/commit/2b583ce6576d4a074ce6f1570b3e60b65c64ae7d#diff-df9fd757e73e7f659350e8a76994d42f. I found it a little surprising, especially since the behaviour is described for `Where` but not for `What`. So maybe its good to mention that in the systemd.mount man page under `What`? Thanks, Anoop ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Better network naming on Hyper-V/Azure?
On Di, 07.01.20 09:53, Stephen Hemminger (step...@networkplumber.org) wrote: > On Tue, 7 Jan 2020 15:01:25 +0100 > Lennart Poettering wrote: > > > On Mo, 06.01.20 15:36, Stephen Hemminger (step...@networkplumber.org) wrote: > > > > > About a year ago there was some discussion on having persistent network > > > names > > > on Hyper-V/Azure. Haiyang did some patches to add an attribute which > > > could be used by udev to do this. But there are some reluctance because > > > of how the channel id works. > > > > > > The motivation to provide network naming is to allow vmbus to change to > > > parallel probing. > > > Right now probing is serialized so naming is always in same order. > > > > > > My question is what exactly does systemd/udev need to provide persistent > > > naming. The obvious ones are: > > > 1. Must be unique (although PCI slot isn't) > > > > It's not unique per bus? huh? > > If you look in sysfs code, there is already code to handle > the case where two devices (usually sub-function) share the same PCI > slot. It is handled by adding a suffix in the kernel. For multifunction devices we append an "fXYZ" suffix where XYZ is the function index. That should be sufficient, no? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Better network naming on Hyper-V/Azure?
On Tue, 7 Jan 2020 15:01:25 +0100 Lennart Poettering wrote: > On Mo, 06.01.20 15:36, Stephen Hemminger (step...@networkplumber.org) wrote: > > > About a year ago there was some discussion on having persistent network > > names > > on Hyper-V/Azure. Haiyang did some patches to add an attribute which > > could be used by udev to do this. But there are some reluctance because > > of how the channel id works. > > > > The motivation to provide network naming is to allow vmbus to change to > > parallel probing. > > Right now probing is serialized so naming is always in same order. > > > > My question is what exactly does systemd/udev need to provide persistent > > naming. The obvious ones are: > > 1. Must be unique (although PCI slot isn't) > > It's not unique per bus? huh? If you look in sysfs code, there is already code to handle the case where two devices (usually sub-function) share the same PCI slot. It is handled by adding a suffix in the kernel. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Better network naming on Hyper-V/Azure?
On Di, 07.01.20 16:01, Haiyang Zhang (haiya...@microsoft.com) wrote: > > I have no idea what that means, what is Accelerated Networking? > > On Azure, "Accelerated Networking" means SRIOV / VF NICs. There's nowadays already support for SR-IOV naming in place: https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html#ID_NET_NAME_SLOT=prefix%5BPdomain%5Dsslot%5Bffunction%5D%5Bnport_name%7Cddev_port%5D Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Better network naming on Hyper-V/Azure?
(resending after subscribed to systemd-devel) > -Original Message- > From: Lennart Poettering > Sent: Tuesday, January 7, 2020 9:01 AM > To: Stephen Hemminger > Cc: systemd-devel@lists.freedesktop.org; Haiyang Zhang > > Subject: Re: [systemd-devel] Better network naming on Hyper-V/Azure? > > On Mo, 06.01.20 15:36, Stephen Hemminger (step...@networkplumber.org) > wrote: > > > About a year ago there was some discussion on having persistent network > names > > on Hyper-V/Azure. Haiyang did some patches to add an attribute which > > could be used by udev to do this. But there are some reluctance because > > of how the channel id works. > > > > The motivation to provide network naming is to allow vmbus to change to > parallel probing. > > Right now probing is serialized so naming is always in same order. > > > > My question is what exactly does systemd/udev need to provide persistent > > naming. The obvious ones are: > > 1. Must be unique (although PCI slot isn't) > > It's not unique per bus? huh? > > > 2. Must be persistent across reboot. > > 3. Must be stable if device is removed. > > Yes, these three are the idea. > > > There are more questions. > > 1. Is there a particular ordering and non-reuse requirement. > > Obviously, names have to be 15 characters or less but what > > else. > > No ordering or non-reuse requirements are made. I mean, the device > path names are in particular defined so that they stable even if you > replace your PCI network card by a different one, hence in that case > absolutely are reused by a different device, and that's intentional. > > Yeah must fit in IFNAMSIZ. And probably shouldn't include "/", control > chars, whitespace and some other weird chars that apps don't like. But > that's the same for all network interfaces, whether managed by udev > predictable naming or not... > > > 2. How to handle the device associated with Accelerated Networking? > > Do you want to hide or rename the VF that is associated with the > > virtual device? > > I have no idea what that means, what is Accelerated Networking? On Azure, "Accelerated Networking" means SRIOV / VF NICs. > > > There are a couple of other quirks: > > 1. The current cloudinit and other startup applications require eth0 as > > the administrative and always there interface, hard wired into the > > code. How to handle that? > > if you have multiple devices and want a specific one to be named eth0 > then this is inhrently racy since we can't sensibly rename the device > like that in userspace because we'd always race against the kernel's > own naming regime. > > Naming an interface "eth0" only really works if you have only one > interface or if you don't care about the names at all. If you have > multiple then pick different names outside of the ethX namespace the > kernel allocates from. > > In the case where you only have a single interface or don't care about > the name then drop in a .link file that matches the interface > generically and sets NamePolicy=kernel so that the kernel name is used > as it is. > > > 2. Hyper-V has the ability for host administrator to assign a name, but > > it is more of a free form string so it is used as default > > network description. > > Current systemd git has support for assigning "alternative" ifnames to > devices, using that new kernel feature. On kernels that support that > we'll initialize the alternative ifnames to all names we could > possibly come up with (i.e. so that an interface always be be referred > to by its by-path, by-slot, by-mac name equally). Since the > alternative ifnames are not IFNAMSIZ long (but 128 chars long) maybe > they are suitable to use for these hyperv "free form string" if that > makes sense given the charset restrictions. > > > 3. Azure has names as part of the CLI for manipulating VM's but these > > are not currently exposed to guest. If this could happen would it help > > or > > hurt. > > I mean, we are happy to make use of any names that make sense. Not > sure why hyperv needs three different symbolic names for each > interface, but if it is how it is, then we can toally expose them all > ;-). Hyper-V offers netvsc devices (synthetic NICs) in the same sequence across reboots, so eth0 ... ethN names will associate to the same vNIC every time with Sync-probing currently. But if in the future, we enable Async-probing, the naming may not persistent across reboots. In my patch set (not yet upstream), I added a new attribute (dev_num) in sysfs to keep track of the device channel offer sequence. So user mode program can have the option to use this attribute to name NICs, and generates the same results for Async-probing as Sync-probing does. Thanks, - Haiyang ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Verbose output from systemctl?
On Mo, 06.01.20 08:51, Jeffrey Walton (noloa...@gmail.com) wrote: > Hi Everyone, > > I'm trying to install a service. The script is failing with: > > + systemctl enable callboot-monitor.service > Failed to enable unit: File callboot-monitor.service: Invalid argument > + exit 1 > > The man page does not list an option for verbose output, and there is > no -v option. > > How do I get more information about the failure? Current systemd versions have better messages for most of these cases. Which systemd version are you using (always specify that first, please!)? Other than that look in the system logs. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Portable service and bind paths
On Mo, 06.01.20 20:44, Claes H (claesatw...@gmail.com) wrote: > On Mon, Jan 6, 2020 at 1:40 PM Lennart Poettering > wrote: > > > > If possible use DynamicUser=1, i.e. have a short-lived user that only > > exists while your service is running. > > > > For some usecases that doesn#t work though. There's a TODO list item, > > to add AllocateUser= as new switch to create a user persistently on > > first start, as an alternative for such cases. Nobody worked on that > > yet though. And of course, it's much less sexy since for such users > > the portable services would suddenly leave traces on the system, in a > > way that is never cleaned up... > > > > I will see if I can get DynamicUser to work. If I understand that > correctly, it is mainly useful when the service is truly self > contained / having its own sandbox. Yes. If the service is supposed to for example write files visible to other services that DynamicUser=1 doesn't work really. > I want the service and myself to be able to read and write to the > files in its configuration / runtime directory. That is why I have > Bind-mounted it into the service's file system. Need to read up on the > state directory concept for DynamicUser. But it seems complex. > > The AllocateUser concept seems very useful for when the usecase is to > bundle up a fast moving application with all its dependencies. I would > not mind so much about the traces that can be left. If it is > implemented, probably should include something like AllocateGroup > too. Would be delighted to review a patch for that ;-) Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Better network naming on Hyper-V/Azure?
On Mo, 06.01.20 15:36, Stephen Hemminger (step...@networkplumber.org) wrote: > About a year ago there was some discussion on having persistent network names > on Hyper-V/Azure. Haiyang did some patches to add an attribute which > could be used by udev to do this. But there are some reluctance because > of how the channel id works. > > The motivation to provide network naming is to allow vmbus to change to > parallel probing. > Right now probing is serialized so naming is always in same order. > > My question is what exactly does systemd/udev need to provide persistent > naming. The obvious ones are: > 1. Must be unique (although PCI slot isn't) It's not unique per bus? huh? > 2. Must be persistent across reboot. > 3. Must be stable if device is removed. Yes, these three are the idea. > There are more questions. > 1. Is there a particular ordering and non-reuse requirement. > Obviously, names have to be 15 characters or less but what > else. No ordering or non-reuse requirements are made. I mean, the device path names are in particular defined so that they stable even if you replace your PCI network card by a different one, hence in that case absolutely are reused by a different device, and that's intentional. Yeah must fit in IFNAMSIZ. And probably shouldn't include "/", control chars, whitespace and some other weird chars that apps don't like. But that's the same for all network interfaces, whether managed by udev predictable naming or not... > 2. How to handle the device associated with Accelerated Networking? > Do you want to hide or rename the VF that is associated with the > virtual device? I have no idea what that means, what is Accelerated Networking? > There are a couple of other quirks: > 1. The current cloudinit and other startup applications require eth0 as > the administrative and always there interface, hard wired into the > code. How to handle that? if you have multiple devices and want a specific one to be named eth0 then this is inhrently racy since we can't sensibly rename the device like that in userspace because we'd always race against the kernel's own naming regime. Naming an interface "eth0" only really works if you have only one interface or if you don't care about the names at all. If you have multiple then pick different names outside of the ethX namespace the kernel allocates from. In the case where you only have a single interface or don't care about the name then drop in a .link file that matches the interface generically and sets NamePolicy=kernel so that the kernel name is used as it is. > 2. Hyper-V has the ability for host administrator to assign a name, but > it is more of a free form string so it is used as default > network description. Current systemd git has support for assigning "alternative" ifnames to devices, using that new kernel feature. On kernels that support that we'll initialize the alternative ifnames to all names we could possibly come up with (i.e. so that an interface always be be referred to by its by-path, by-slot, by-mac name equally). Since the alternative ifnames are not IFNAMSIZ long (but 128 chars long) maybe they are suitable to use for these hyperv "free form string" if that makes sense given the charset restrictions. > 3. Azure has names as part of the CLI for manipulating VM's but these > are not currently exposed to guest. If this could happen would it help or > hurt. I mean, we are happy to make use of any names that make sense. Not sure why hyperv needs three different symbolic names for each interface, but if it is how it is, then we can toally expose them all ;-). Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service fails to start with no log messages
On Mo, 06.01.20 21:47, Jeffrey Walton (noloa...@gmail.com) wrote: > On Mon, Jan 6, 2020 at 9:35 PM Reindl Harald wrote: > > > > Am 07.01.20 um 02:57 schrieb Jeffrey Walton: > > > To fix my ordering problem I need Systemd to stop lying about when the > > > network is ready. > > > > one last comment: > > > > whatever crap you did ending in the ordering cycle did not solve your > > wrong ordering after network, it just burried it by slow down something > > else and so by luck > > > > systemd does not lie here - you just need to do the ordering proper > > based on how your network is configured at all which you refuse to tell > > > > so your better options would have been report thate network ordering > > problem here before touch anything else > > > > "There are absolutely 0 entires about my monitor service" is because > > it's thrown out of the startup transaction cause dby your other config > > screwup > > And there we have it. Systemd is not logging the problem. And then you > wonder why users like me go down rabbit holes. > > Perhaps Systemd should hire someone who understands usability and > design. Maybe they can explain why throwing important information away > is a bad idea. Not helpful at all. Consider both of you warned. One more post like this and you are moderated. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service fails to start with no log messages
On Mo, 06.01.20 21:06, Jeffrey Walton (noloa...@gmail.com) wrote: > I think that was a very good summary of the problem. > > I want my monitor service to start (it is the most important one), but > there are absolutely no traces of it. > > The joke is Systemd and its inability to provide basic information to > troubleshoot a problem. Cron was replaced with a more complex system > that does not work as expected. Jeff. This attitude is not appropriate either. Guys, stop posting this kind of stuff. Be civil, or I'll put both of you on moderation. Please ask you questions in a friendly tone, and please answer questions in a friendly tone. It's fine to be direct, but don#t deride stuff as "joke" all the time. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service fails to start with no log messages
On Di, 07.01.20 03:03, Reindl Harald (h.rei...@thelounge.net) wrote: > >> Especially the "Wants" is problematic and noramlly not needed for > >> enabled services, normally your only use After/NBefore unless there is a > >> compelling resason for Wants/Requires and with growing useless > >> dependencies you add to your units problems gow > >> > >> perfomance wise because you break parallel starts for no benefit and > >> because of such unsolveable cycles if you obviously don't understand > >> what you define becaus eotherwise you won't have After/Before/wants in > >> combinations which are impossible > >> > >> and to your other post "5 seconds after all systems services have > >> actually started" is something which simply don#t exist and can't exist > >> at all > >> > >> fix your orderings and your problems are gone > > > > To fix my ordering problem I need Systemd to stop lying about when the > > network is ready. > > it don't - you most likely did something wrong by the ordering afetr > networking and you even don't tell how your networking is configured > (network.service, networkmanager, systemd-networkd...) > > in other words: instead fix your network-ordering properly you touch > other random stuff in weird ways and it's annyoing that one needs to ask > for each and every bit given your initial posting was a completly joke > with no single information and the whole topic "Service fails to start > with no log messages" is wrong at all Reindl, tone it down please. That's not helpful. "was completely joke" is not nice. I mean, yes I think jeffreys mail could be more precise, but that's not a reason to call something "a joke"... Thank you for understanding, Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service fails to start with no log messages
On Mo, 06.01.20 20:57, Jeffrey Walton (noloa...@gmail.com) wrote: > > and to your other post "5 seconds after all systems services have > > actually started" is something which simply don#t exist and can't exist > > at all > > > > fix your orderings and your problems are gone > > To fix my ordering problem I need Systemd to stop lying about when the > network is ready. systemd has no clue when your network is "ready", since that might mean many things. i.e. did you acquire a DHCP lease? did you just UP the iface? Did you reach some server? in systemd we can't know this, as in particular on clients and on servers "network ready" means very different things. If you use systemd-network-wait-online.service you can configure what "up" means. It's not enabled by default, but you can do that with "systemctl enable". It's not enabled by default since in the general case we don't want the local boot to be delayed because of some external condition. If you use NetworkMAnager there's a similar service. > I keep pushing it back because I can't get accurate information from Systemd. I am sorry, what? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service fails to start with no log messages
On Mo, 06.01.20 20:28, Jeffrey Walton (noloa...@gmail.com) wrote: > I'm trying to determine my service fails to start. I copied the > service to the systemd unit directory, and then enabled and started > the service. Upon reboot the service is not started automatically. > > Here are the logs: > > $ journalctl -e | grep callboot > Jan 06 20:25:33 raspberrypi systemd[1]: graphical.target: Found > dependency on callboot-ui.service/start > Jan 06 20:25:33 raspberrypi systemd[1]: graphical.target: Job > callboot-ui.service/start deleted to break ordering cycle starting > with graphical.target/start The logs actually show you the full ordering cycle you defined. But your "grep" hides that. Drop the "grep", and look for the lines around the above it tells you where you have an ordering cycle. Ordering cycle means your service is ordererd after some other service (or multiple of them) that are ultimately ordered again after your own service, which is hence a cycle. systemd cannot fulfill that and complains. > > $ cat /etc/systemd/system/callboot-monitor.service > [Unit] > Description=Callboot service > > # This service waits for the UI. It slows down the > # boot so the service starts without failure. > After=graphical.target > Wants=graphical.target > # Service waits for the USB modem > After=usb.target > Wants=usb.target > > [Service] > Type=simple > ExecStart=/opt/callboot/bin/callboot.exe > > [Install] > WantedBy=multi-user.target So this is your cycle: your service is declared to start before multi-user.target (since WantedBy= generally implies Before=, unless DefaultDependencies=no is specified), but after graphical.target, but graphical.target itself is ordered after multi-user.target. Hence you declare the following cycle: graphical.target → callboot-monitor.service → multi-user.target → graphical.target Break that up. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service fails to start with no log messages
On Mo, 06.01.20 20:46, Jeffrey Walton (noloa...@gmail.com) wrote: > On Mon, Jan 6, 2020 at 8:34 PM Reindl Harald wrote: > > > > Am 07.01.20 um 02:28 schrieb Jeffrey Walton: > > > I'm trying to determine my service fails to start. I copied the > > > service to the systemd unit directory, and then enabled and started > > > the service. Upon reboot the service is not started automatically. > > > > > > Here are the logs: > > > > Jan 06 20:25:33 raspberrypi systemd[1]: graphical.target: Job > > callboot-ui.service/start deleted to break ordering cycle starting > > with graphical.target/start > > > > you have some conflicting After/Before ordering which is impossible to > > solve automatically, it's that simple > > Maybe I can try this... How do I tell Systemd to use After= and Wants= > such that "5 seconds after all systems services have actually > started"? Such a concept does not exist. I mean your service is a system service itself, so what is that even supposed to mean that the service shall start 5s after it already started? But even if you mean to say "5s after all other services", then think how that falls apart if you have multiple services declaring that. hence, in systemd there's no concept for that. Instead you are supposed to properly order your units and declare the exact ordering you rely on and not less nor more. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service fails to start with no log messages
On Mon, 6 Jan 2020 21:47:37 -0500 Jeffrey Walton wrote: > On Mon, Jan 6, 2020 at 9:35 PM Reindl Harald > wrote: > > > > Am 07.01.20 um 02:57 schrieb Jeffrey Walton: > > > To fix my ordering problem I need Systemd to stop lying about > > > when the network is ready. > > > > one last comment: > > > > whatever crap you did ending in the ordering cycle did not solve > > your wrong ordering after network, it just burried it by slow down > > something else and so by luck > > > > systemd does not lie here - you just need to do the ordering proper > > based on how your network is configured at all which you refuse to > > tell > > > > so your better options would have been report thate network ordering > > problem here before touch anything else > > > > "There are absolutely 0 entires about my monitor service" is because > > it's thrown out of the startup transaction cause dby your other > > config screwup > > And there we have it. Systemd is not logging the problem. And then you > wonder why users like me go down rabbit holes. > > Perhaps Systemd should hire someone who understands usability and > design. Maybe they can explain why throwing important information away > is a bad idea. > > Jeff I can't tell whether you're deliberately trolling Reindl, which helps nobody and certainly doesn't help solve your problem, or whether you simply have a lot of prejudice about systemd that you're keen to talk about. Either way, it's counterproductive; please stop it. Just write about your technical issues. I'd suggest you start again, and try to post complete information - such as you have - about your services and problems with them. But first please reread all Reindl and Paul's comments and try to apply the useful information that is contained within them. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service fails to start with no log messages
Dear Jeffrey, On 2020-01-07 03:17, Jeffrey Walton wrote: […] > There are absolutely 0 entires about my monitor service: > > $ journalctl -e | grep -i callboot | grep monitor > $ The switch `-e` implies that by default only 1000 lines are shown. -e, --pager-end Immediately jump to the end of the journal inside the implied pager tool. This implies -n1000 to guarantee that the pager will not buffer logs of unbounded size. This may be overridden with an explicit -n with some other numeric value, while -nall will disable this cap. Note that this option is only supported for the less(1) pager. Does `journalctl -b | grep -i callboot` show something? `-b` only shows log messages for the current boot. […] Kind regards, Paul smime.p7s Description: S/MIME Cryptographic Signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
