Re: [systemd-devel] non-existent unit instances
On Sat, 5 Sep 2020, Richard Hector wrote: > Hi all, > > Quoting from another thread: > > On 5/09/20 4:36 am, Lennart Poettering wrote: > > Unit instances can be activated on-the-fly without further prepartion > > or regsitration of the instance string or so. it's sufficient if the > > template unit exists. > > Is that preventable? > > I have some instance names that are easily typoed. When I start one with > the wrong name, it sticks around trying to restart for ever - or at > least till I notice it or reboot - where I'm much rather get an error > message and stop. > > For reference, this is with the openvpn-client@ (and maybe > openvpn-server@) units in Debian buster. Some of the content was > modified/overwritten by me, so it could well be a bug introduced by me. Since the instance name for this unit is used to derive a configuration filename, a simple solution here would be to use: ConditionPathExists=/etc/openvpn/client/%i.conf in the unit. Or, if you want the start job to fail when given a bad instance name: AssertPathExists=/etc/openvpn/client/%i.conf > The typos are because my instances are based on hostname, which can > contain '-' but not '_'. Instance names can apparently not contain '-', > so I have to use '_' instead, but my muscle memory for my hostnames is > strong. Instance names can contain hyphens, however depending on how they're used these hyphens will be translated into slashes. The %I specifier does this kind of translation, for instance. This upstream OpenVPN units use %i when they reference configuration filenames, however, and this does not perform any translation on the instance name. I'm not sure why hyphens would cause problems for you. > I don't know if this is a result of the way the units are written, or an > inherent issue with systemd. > > Cheers, > Richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] non-existent unit instances
On 05/09/2020 13:18, Kevin P. Fleming wrote: > It's a general issue with templated unit files; I've had this happen > as well, and could not figure out why the service had failed to start. > It was because I had mistyped the instance name. As best I can tell > systemd doesn't have any mechanism to restrict the instance names > which can be used for a specific unit file, so it can't know that the > requested instance cannot be started. The point of templated units is to allow arbitrary string as template replacement. If you need to restrict the template expansion, by definition you can enumerate the possible template expansion, and thus you can generate the unit files with a script or with a generator. Cheers, Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] non-existent unit instances
It's a general issue with templated unit files; I've had this happen as well, and could not figure out why the service had failed to start. It was because I had mistyped the instance name. As best I can tell systemd doesn't have any mechanism to restrict the instance names which can be used for a specific unit file, so it can't know that the requested instance cannot be started. On Sat, Sep 5, 2020 at 2:46 AM Richard Hector wrote: > > Hi all, > > Quoting from another thread: > > On 5/09/20 4:36 am, Lennart Poettering wrote: > > Unit instances can be activated on-the-fly without further prepartion > > or regsitration of the instance string or so. it's sufficient if the > > template unit exists. > > Is that preventable? > > I have some instance names that are easily typoed. When I start one with > the wrong name, it sticks around trying to restart for ever - or at > least till I notice it or reboot - where I'm much rather get an error > message and stop. > > For reference, this is with the openvpn-client@ (and maybe > openvpn-server@) units in Debian buster. Some of the content was > modified/overwritten by me, so it could well be a bug introduced by me. > > The typos are because my instances are based on hostname, which can > contain '-' but not '_'. Instance names can apparently not contain '-', > so I have to use '_' instead, but my muscle memory for my hostnames is > strong. > > I don't know if this is a result of the way the units are written, or an > inherent issue with systemd. > > Cheers, > Richard > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journal message timestamps
I've run into similar issues and resorted to adding battery-backed RTCs to my RPis in order to ensure that the kernel's clock would be set to something 'reasonable' very early in the boot process (although it's still not ideal since the RTC drivers are loaded as modules so the kernel's code for doing this can't read them... it has to be done in userspace very early). Given the low cost of RTC chips and supercaps to power them, the fact that RPis still don't include a hardware RTC in their fourth generation is a major failing. In spite of that the boards are quite useful. On Fri, Sep 4, 2020 at 6:00 PM Lennart Poettering wrote: > > On Fr, 04.09.20 22:02, Dave Howorth (syst...@howorth.org.uk) wrote: > > > > (btw, systemd-timesyncd does what fake-hwclock does automatically, and > > > also does SNTP. it should be fine for most usecases, no need to resort > > > to fake-hwclock) > > > > > > Lennart > > > > This is a serious problem for anybody running a raspberry pi (i.e. > > many, many thousands of people.) I suggest buying one for yourself and > > actually experiencing the issues to understand what the problem is and > > why people would like to see a solution. > > I understand the problem, and would be happy to review/merge a patch > that addresses this cleanly. > > I had some raspberry pis, but I gave them away, since I never found a > use for them. > > > I'll send you the dollars if that's really a problem. > > It's not a money problem. Raspberry pis are simply not at the center > of my personal attention. But there are many other engineers in this > world, maybe you can find one that shares your priorities on this and > he will fix it for you. I am not going to be that, but at least I can > offer to review the patches and merge them if they are good. > > Lennart > > -- > Lennart Poettering, Berlin > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using timedatectl on a readonly rootfile system using mender
On Sa, 05.09.20 09:49, Andrei Borzenkov (arvidj...@gmail.com) wrote: > 05.09.2020 01:05, Lennart Poettering пишет: > > > > I explained this already. DNS server data today is much less config > > than state, acquired dynamically via DHCP, hence most distros don#t > > configure it in /etc so much anymore, but manage it in /run (where > > transient state is generally kept), and only keep a compat symlink in > > /etc. If you try to convince people though that the local timezone > > should just be transient state and not persistent config you'll have a > > hard time. I for one am certainly not convinced that the timezones are > > state... > > > > Sorry? glibc has absolutely no problems with /etc/localtime being link > into /run, /var or whatever else (nor has it problems with this file > being normal file and not a link) as long as content of this file is > valid time zone definition. The only piece of software that has problem > with it is systemd. So may be you should stop finger pointing and simply > explain why *systemd* demands that /etc/localtime be specific > symlink. systemd is fine with with it being a bind mount, a regular file or a symlink to whatever as well. But we'll write it out as a symlink to the tz data files in /usr/share/. Also, when we read the data back we can only derive the tz location string from the setting if its a symlink to the tz data files, since the information about the location is only encoded in the path not in the data files themselves. i.e. "Europe/Berlin" is nothing you can derive from the data files, so we derive it from the symlink contents. glibc doesn't ever do that, we do however, since people typicall want to know what the current setting is. For all our tools that write stuff to /etc, i.e. *write* configuration, we can do so only if /etc is writable. That's true for the locale settings, the vconsole settings, for timezones settings and hostname settings. It's also true for seat assignments by logind, for service enablement by systemctl, for portable services hook-ups and so on and so on and so on. We write to /etc because that it is generally where people on Linux accepted that persistent config should be placed. I seriously doubt that that is news to you. If you make that read-only that's entirely fine, but then systemd's tools cannot change config for you, but I think that's totally OK, by making it read-only you explicitly want to disallow changes to the settings, so systemd should accept that and also refuse it to clients. If you want to manage a file in /etc/ in a completely different way, then that's entirely OK. You could use git, or ansible, your private shell script or whatever else floats your boat. There's no need to involve the systemd tools for managing any of them, and systemd will honour what you put there regardless how you write it there. But systemd's own tools assume that /etc read-only means "config read-only" and we honour that, and I think htat's not surprising and most in line with what people would expect. > And yes, in current world this is state and not persistent config. When > I travel into another time zone I change state of my system for this > timezone. Just like DNS server address. Guess what? There is DHCP option > for time zone ... so how is it different from DNS server address? For starters DNS info is per network connection and usually remains valid exactly as long as the network it is associated with is connected to. resolved for example manages DNS info like that: nothing is persisted, and servers are added and dropped as ifaces come and go. Timezone info might receive updates from automatic detection every now and then, as you move around, but it's a lot more sticky: once the timezone is updated it stays that way even for the next boot. And yes, I am pretty sure some people disagree with this, or implement stuff differently, but that doesn't change the fact that in general tz info is persistent and DNS info not so much, though the lines are blurry. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using timedatectl on a readonly rootfile system using mender
05.09.2020 01:05, Lennart Poettering пишет: > > I explained this already. DNS server data today is much less config > than state, acquired dynamically via DHCP, hence most distros don#t > configure it in /etc so much anymore, but manage it in /run (where > transient state is generally kept), and only keep a compat symlink in > /etc. If you try to convince people though that the local timezone > should just be transient state and not persistent config you'll have a > hard time. I for one am certainly not convinced that the timezones are > state... > Sorry? glibc has absolutely no problems with /etc/localtime being link into /run, /var or whatever else (nor has it problems with this file being normal file and not a link) as long as content of this file is valid time zone definition. The only piece of software that has problem with it is systemd. So may be you should stop finger pointing and simply explain why *systemd* demands that /etc/localtime be specific symlink. And yes, in current world this is state and not persistent config. When I travel into another time zone I change state of my system for this timezone. Just like DNS server address. Guess what? There is DHCP option for time zone ... so how is it different from DNS server address? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] non-existent unit instances
Hi all, Quoting from another thread: On 5/09/20 4:36 am, Lennart Poettering wrote: > Unit instances can be activated on-the-fly without further prepartion > or regsitration of the instance string or so. it's sufficient if the > template unit exists. Is that preventable? I have some instance names that are easily typoed. When I start one with the wrong name, it sticks around trying to restart for ever - or at least till I notice it or reboot - where I'm much rather get an error message and stop. For reference, this is with the openvpn-client@ (and maybe openvpn-server@) units in Debian buster. Some of the content was modified/overwritten by me, so it could well be a bug introduced by me. The typos are because my instances are based on hostname, which can contain '-' but not '_'. Instance names can apparently not contain '-', so I have to use '_' instead, but my muscle memory for my hostnames is strong. I don't know if this is a result of the way the units are written, or an inherent issue with systemd. Cheers, Richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
