Re: [systemd-devel] persistent network device names
В Mon, 27 Jul 2015 19:05:37 + "Keller, Jacob E" пишет: > On Mon, 2015-07-27 at 21:53 +0300, Andrei Borzenkov wrote: > > В Mon, 27 Jul 2015 18:29:57 + > > "Keller, Jacob E" пишет: > > > > > On Mon, 2015-07-27 at 21:12 +0300, Andrei Borzenkov wrote: > > > > В Mon, 27 Jul 2015 17:52:59 + > > > > "Keller, Jacob E" пишет: > > > > > > > > > Hello, > > > > > > > > > > I am working with a network device that can create virtual > > > > > function > > > > > devices. When I create a large (>8) vfs for this device I get > > > > > some > > > > > weird device names, > > > > > > > > > > If I create 64 vfs, I see something like: > > > > > > > > > > ens8 > > > > > ens8f[1-7] > > > > > ens8s[1-7] > > > > Are you sure? I do not see where such names would be generated. > > > > Yes. These are generated via the hotplug section of udev-builtin > -net_id.c rules > > on line: 230 or so. > I do not see where it generates double 's'. > > > It looks like my issue comes from the "hotplug_slot" stuff, which > > > overwrites the "enp8s0f0" into "ens8"... that is what causes this > > > dual > > > -name scheme confusion. > > > > > > > You can disable hotplug slot-based naming by setting suitable > > NamePolicy for network links (drop "slot"). > > How can I define my own version of the net_id which does what I would > like and run that in my udev rule? man systemd.link specifically description of NamePolicy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-tmpfiles for the user instance of systemd
On Sat, 04.07.15 13:23, Tomasz Torcz (to...@pipebreaker.pl) wrote: > On Fri, Jul 03, 2015 at 08:31:42PM +0200, Lennart Poettering wrote: > > On Wed, 01.07.15 12:35, Daniel Tihelka (dtihe...@gmail.com) wrote: > > > > > Hello, > > > does anyone have an experience with the use of systemd-tmpfiles for the > > > user > > > instance of systemd. > > > > This is currently not nicely supported. And I am not sure it > > should. Note that much of what tmpfiles supports is only necessary > > for: > > > > - aging (automatic time-based clean-up of files). Doesn't really apply > > to user sessions, since /tmp and /var/tmp are already cleaned up by > > the system instance of tmpfiles > > /var and /tmp are not only aged files. I'm using tmpfiles for removing > – files in ~/Downloads/* older than 1 year > – emails in ~/Mail/.spam/cur/* older than 1 month > > Out of neccessity I have cleanup configured in system instance for my > specific user only. My recommendation would be to clean ~/Downloads up from the root tmpfiles instances. The simple issue is that aging for dirs cannot work, since iterating through them will bump the atime, which defeats the aging. You hence break the aging by aging... THis can only work if you have root privs, since then we can turn off the atime bumping... 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] ip_forward
On Tue, 23.06.15 13:30, Johannes Ernst (johannes.er...@gmail.com) wrote: > (Morale: in doubt, lean hard on your booleans) > > 1. Reboot host. (Arch running in VirtualBox on Mac) > > 2. host> sysctl net.ipv4.ip_forward > net.ipv4.ip_forward = 1 This is the global option, it is related in non-obvious ways to the per-interface one, which you can control with IPForward= option in the .network interface. Also note that the per-interface IPForward= option was buggy in older versions, make sure to use only the most recent systemd versions for this to work correctly. 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] oneshot service
On Tue, 07.07.15 13:04, Ernast Sevo (ers...@gmail.com) wrote: > Apologies that was mistakenly sent. The example service is below. > > [Unit] > Before=local-fs.target > After= > DefaultDependencies=false > > [Service] > Type=oneshot > ExecStart=/usr/bin/xxx > RemainAfterExit=yes > > [Install] > WantedBy=local-fs.target > > The problem is I can see boot-up continue prior to this service doing > its job. I am not sure if I am missing > something but I haven't come across anything in the documentation that > can help. The service finishes its job > later but something's that depend on it have already failed and have > not waited for it to finish doing what it is doing. > > Any thoughts as to what could be causing this? Maybe your /usr/bin/xxx binary forks something into the background and returns in the parent? systemd only cares about the process it starts when Type=oneshot it used. Make sure your process doesn't daemonize when you use Type=oneshot. Or maybe you are missing the dependencies towards the services that shall be started afterwards, and hence systemd proceeds immediately with their execution, right away. 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] Reason for setting runqueue to IDLE priority and side effects if this is changed?
On Wed, 15.07.15 17:30, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote: > Systemd v211 added the running queue as deferred event source to the > event handling with priority IDLE. So dbus requests are preferred > over job execution. The reverse order effect is simply because the > run queue is more a stack than a queue. All of the observed behavior > could be explained I guess. > > So long story in advance. I've now two questions: > - Am I causing any critical side effects when I'm increasing the run > queue priority so that it is higher than the one of the dbus > handling (which is NORMAL)? First tests showed that I can get back > exactly the behavior we had before with that. The idea was that if the user wants us to undo some operation, we better operate on that first, before we execute the job he might want to undo. Hence dbus requests get priority. But other than that I don't see how this would be a problem. > - Might it still happen that situations are happening where the jobs > are reordered even though I'm increasing the priority? Well, we currently say that the order in which jobs are dispatched if multiple are runnable (where "runnable" means "all deps satisfied") is undefined. I'd be willing to add a new unit setting to unit files that would allow altering the order in which jobs are dispatched if multiple are runnable. For example, we could add a new value Priority= which could allow altering the order in which runnable jobs are dispatched. This run queue (which is actually a stack right now...) would then become a priority queue. Such a ptahc would probably not be too difficult, given that we already have a prioq abstract data structure in systemd. > - Is there any other good solution ensuring the order of job execution? No yet, sorry. Would be happy to take a patch implementing what I suggested above! 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] Cannot mount anything after recovering and redoing boot mbr
On Mon, 27.07.15 16:35, c...@endlessnow.com (c...@endlessnow.com) wrote: > > On Mon, 27.07.15 01:18, Christopher Cox (c...@endlessnow.com) wrote: > > > >> I suspect that somebody here knows why, but all mounts now fail... well > >> all but /. > >> > >> Has anyone run across this before? What did I miss? > >> > >> I accidentally messed up my boot mbr. and I did a rescue cd and chroot > >> in > >> order to rerun grub2-mkconfig and do a grub2-install. > >> > >> Now the system boots to a grub menu and tries to boot, root fileystem > >> mounts > >> but all other mounts fail so goes into "emergency" mode. From that > >> shell I > >> cannot seem to mount anything, they all fail saying that whatever I'm > >> trying > >> to mount is already mounted or it's "in use". I can't fsck umounted > >> filesystems either. They all say "in use". > > > > Maybe your changed the order of your partitions or changed their > > partition UUID? If so, then /etc/fstab will reference incorrect > > partitions now. Make sure bring /etc/fstab into sync with your actual > > partitions. > > A "root" is getting mounted and I figure it's the same but will double > check (away from system right now). Would some kind of root getting > mounted at startup and being different from root in /etc/fstab make some > sort of difference? Nope, mounted is mounted. systemd doesn't really care where something is mounted from, it only cares whether it is mounted at all. And the mount source it will only use if it needs to mount something because nobody else has mounted it yet. > Would that cause manual mounts of old style nonportable dev > shortnames (e.g. mount /dev/sda7 /mnt) to fail with the error of > "busy" when done at the command line? (from emergency shell). Well if you use references such as /dev/sda7 then you are of course very vulnerable to partition renumbering if you redoo your partition table. Use /dev/disks/by-uuid/ and you should be safe regarding that. 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] fstab generator and nfs-client.target
On 27 July 2015 at 15:58, Lennart Poettering wrote: > On Mon, 27.07.15 15:37, Felipe Sateler (fsate...@debian.org) wrote: > >> On 27 July 2015 at 12:36, Lennart Poettering wrote: >> > On Mon, 27.07.15 15:19, Felipe Sateler (fsate...@debian.org) wrote: >> > >> >> On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote: >> >> >> >> > Coming back to your original question, there are two options: >> >> > >> >> > 1) nfs-common becomes a normal multi-user.target service, but adds >> >> >Before=remote-fs-pre.target. This way, the service is started at >> >> >boot, and not only on first use. >> >> >> >> This would have the side effect of nfs-common not being started in single >> >> user mode, which is not likely to be the wanted outcome. >> > >> > Well, then set DEfaultDEpendencies=no and pull it in by >> > sysinit.target. But that's only OK if the service is capable of >> > running in early-boot mode (i.e does not try to access /var and stuff). >> >> Or basic.target? The description of basic.target says: >> >> >> Usually this should pull-in all mount points, swap devices, sockets, >> >> timers, >> >> and path units and other basic initialization necessary for general >> >> purpose >> >> daemons. >> >> Something that provides services for mountpoints could be hooked up here, no? >> >> The description of sysinit.target doesn't really tell me what this >> target is all about, or how to choose between it and basic.target. > > Yeah, it's not obvious. Basically, sysinit.target is where all the > small early-boot mini-services are pulled in. basic.target otoh pulls > in the various other targets then, without pulling in any .mount, > .service, .socket, ... units on its own. Except for RequiresMountsFor=/var /tmp /var/tmp specified in basic.target. > > Or in other words: we group all early-boot services in sysinit.target, > we group all mounts in local-fs.target, all swaps in swaps.target, all > sockets in sockets.target, and so on, and then group all the > aforementioned targets as basic.target. Makes sense? Yes, makes sense. I will try to come up with a patch to the documentation to clarify this. -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot mount anything after recovering and redoing boot mbr
c...@endlessnow.com composed on 2015-07-27 16:35 (UTC-0500): > A "root" is getting mounted and I figure it's the same but will double > check (away from system right now). Would some kind of root getting > mounted at startup and being different from root in /etc/fstab make some > sort of difference? Would that cause manual mounts of old style > nonportable dev shortnames (e.g. mount /dev/sda7 /mnt) to fail with the > error of "busy" when done at the command line? (from emergency shell). > I may just back the data off and do a reinstall. So if anyone can chime > in with other things to try, please do it now before I have to blow it all > away. As for things to try I would reduce fstab to one line for /, then try booting normally. I've seen dracut at various times hard code swap or other partition UUIDs that become out of sync with what's on the HD following updates or restoring from backup, e.g.: http://bugzilla.opensuse.org/show_bug.cgi?id=936964 & cf. http://lists.opensuse.org/opensuse/2015-07/msg00080.html https://bugzilla.redhat.com/show_bug.cgi?id=1187007 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot mount anything after recovering and redoing boot mbr
> On Mon, 27.07.15 01:18, Christopher Cox (c...@endlessnow.com) wrote: > >> I suspect that somebody here knows why, but all mounts now fail... well >> all but /. >> >> Has anyone run across this before? What did I miss? >> >> I accidentally messed up my boot mbr. and I did a rescue cd and chroot >> in >> order to rerun grub2-mkconfig and do a grub2-install. >> >> Now the system boots to a grub menu and tries to boot, root fileystem >> mounts >> but all other mounts fail so goes into "emergency" mode. From that >> shell I >> cannot seem to mount anything, they all fail saying that whatever I'm >> trying >> to mount is already mounted or it's "in use". I can't fsck umounted >> filesystems either. They all say "in use". > > Maybe your changed the order of your partitions or changed their > partition UUID? If so, then /etc/fstab will reference incorrect > partitions now. Make sure bring /etc/fstab into sync with your actual > partitions. A "root" is getting mounted and I figure it's the same but will double check (away from system right now). Would some kind of root getting mounted at startup and being different from root in /etc/fstab make some sort of difference? Would that cause manual mounts of old style nonportable dev shortnames (e.g. mount /dev/sda7 /mnt) to fail with the error of "busy" when done at the command line? (from emergency shell). I may just back the data off and do a reinstall. So if anyone can chime in with other things to try, please do it now before I have to blow it all away. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user instance of systemd while inside a container
On Mon, 2015-07-27 at 21:51 +0200, Lennart Poettering wrote: > On Tue, 14.07.15 18:34, Keller, Jacob E (jacob.e.kel...@intel.com) > wrote: > > > Hello, > > > > I created an nspawn container which is also running systemd. I > > can't > > figure out why the systemd --user instances aren't started. > > > > I'd like to manage some processes run as a specific user inside the > > container. Previously I was using a VM to do it this way, and I > > would > > like to be able to port the same code over to the container image. > > > > Is there some setup I need to do to get the instance started? I > > tried > > searching on the web, but came up with very little documentation. > > user > > instances appear to be started by pam.. Maybe pam is not being used > > as > > the login for the container? > > This should just work, and it works for me too, with a Fedora 22 host > and guest (with current systemd added on top). > > Anything interesting in the logs? > > What does "systemctl status user@$UID.service" say for you after you > logged in? > > Lennart > Hi, thanks. I found out it was because I am using Centos, which disables this feature by default. I had to copy a user@.service into the container, and then things worked fine. Wish downstream projects wouldn't disable random features like this Regards, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] difference in restart behavior between 219 and 220?
On Thu, 09.07.15 23:14, Vadim Berezniker (va...@berezniker.com) wrote: > If a service fails to start because a dependency fails but that dependency > successfully starts after an automatic restart, I would expect the failed > dependent to attempt to start as well now that its dependency is > happy. Hmm, if the automatic restart is configured for the service rather than the dep (or in addition to), you should get the behaviour you are looking for, no? 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] machinectl clone -- access denied
On Mon, 22.06.15 16:20, Johannes Ernst (johannes.er...@gmail.com) wrote: > I can import-tar, list-images, image-status, start, rename, and remove, but > > > sudo machinectl clone depot depot2 > Could not clone image: Access denied For completeness of the archives' sake: discussion about this has moved to: https://github.com/systemd/systemd/issues/465 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] user instance of systemd while inside a container
On Tue, 14.07.15 18:34, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: > Hello, > > I created an nspawn container which is also running systemd. I can't > figure out why the systemd --user instances aren't started. > > I'd like to manage some processes run as a specific user inside the > container. Previously I was using a VM to do it this way, and I would > like to be able to port the same code over to the container image. > > Is there some setup I need to do to get the instance started? I tried > searching on the web, but came up with very little documentation. user > instances appear to be started by pam.. Maybe pam is not being used as > the login for the container? This should just work, and it works for me too, with a Fedora 22 host and guest (with current systemd added on top). Anything interesting in the logs? What does "systemctl status user@$UID.service" say for you after you logged in? 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] offline updates
On Mon, 27.07.15 19:37, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > OK, I think we're pretty much in agreement. I'd like to take the opportunity > to convert the wiki page to a man page. It would be easier to discuss > and track changes then. ? I'd document systemd behaviour, apis and semantics in man pages. But leave specs and longer usage suggestions in the wiki... But I have no strong feelings about this. 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] Failed at step RUNTIME_DIRECTORY spawning /usr/bin/true: File exists
On Wed, 15.07.15 16:24, Reindl Harald (h.rei...@thelounge.net) wrote: > why does systemd *randomly* try to create "RuntimeDirectory" > for "ExecStartPost" and so terminates a perfectly up and running service > because the "file exists" error? > > Fedora 21 as well as Fedora 22 > https://bugzilla.redhat.com/show_bug.cgi?id=1226509#c3 > > Jul 15 16:19:43 rawhide systemd: Stopping Test Unit... > Jul 15 16:19:43 rawhide systemd: Stopped Test Unit. > Jul 15 16:19:43 rawhide systemd: Starting Test Unit... > Jul 15 16:19:43 rawhide systemd: Failed at step RUNTIME_DIRECTORY spawning > /usr/bin/true: File exists > Jul 15 16:19:43 rawhide systemd: test2.service: control process exited, > code=exited status=233 > Jul 15 16:19:43 rawhide systemd: Failed to start Test Unit. > Jul 15 16:19:43 rawhide systemd: Unit test2.service entered failed state. > Jul 15 16:19:43 rawhide systemd: test2.service failed. Can you file an issue about this on github with a reproducer for v221 or v222? Thanks! 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] Odd /proc/$pid/fd symlinks in nspawn container
Lennart Poettering writes: > On Mon, 27.07.15 21:08, Ben Gamari (b...@smart-cactus.org) wrote: > >> Lennart Poettering writes: >> >> > On Mon, 27.07.15 20:29, Ben Gamari (b...@smart-cactus.org) wrote: >> > >> >> >> >> Ahh, of course. This is a Debian sid machine, so systemd 221. >> > >> > That's pretty recent. Any chance you can strace this, checking where >> > this "/7" file comes from? >> > >> Sure. >> >> This Gist [1] is the output from > > I think you forgot to add a footnote there... > Indeed I did. Thanks. Cheers, - Ben [1] https://gist.github.com/bgamari/e39ae645a84df670e5c4 signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container
On Mon, 27.07.15 21:32, Ben Gamari (b...@smart-cactus.org) wrote: > Lennart Poettering writes: > > > On Mon, 27.07.15 21:08, Ben Gamari (b...@smart-cactus.org) wrote: > > > >> Lennart Poettering writes: > >> > >> > On Mon, 27.07.15 20:29, Ben Gamari (b...@smart-cactus.org) wrote: > >> > > >> >> > >> >> Ahh, of course. This is a Debian sid machine, so systemd 221. > >> > > >> > That's pretty recent. Any chance you can strace this, checking where > >> > this "/7" file comes from? > >> > > >> Sure. > >> > >> This Gist [1] is the output from > > > > I think you forgot to add a footnote there... > > > Indeed I did. Thanks. Hmm, this might just be confusion because the /dev/pts/8 device is outside of the namespace of the container. The kernel cannot show the path hence it shows "/8" instead, the path relative to the specific fs of that file, which is the devpts instance of the host. If you do "echo foo > /proc/self/fd/1", does that ger properly echoed to your pty? If so, you can safely ignore this issue... 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] offline updates
On Mon, Jul 27, 2015 at 08:48:08PM +0200, Lennart Poettering wrote: > On Tue, 21.07.15 03:27, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > [resending with the right systemd-devel address, sorry for that] > > > > Here are some thoughts on offline updates resulting from testing > > the new dnf fedup plugin developed by Will Woods > > [https://github.com/wgwoods/dnf-plugin-fedup]. > > > > I ran an update using dnf fedup and it works (or would have worked, if > > stuff didn't happen), which is already great for something so simple, > > but it exposes some shortcomings in the Offline Update spec itself > > [http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/]. > > > > The main issues are: > > - what happens when multiple offline mechanisms are present > > - how is failure handled > > > > On my test system, I had packagekit-offline-update.service already > > present when I installed the plugin and fedup-system-upgrade.service. > > After running 'dnf fedup download ...' and 'dnf fedup reboot' > > I saw something like this: > > I appears to be quite wrong to have a distro that is update in two > ways. Pick one. Or if you really want to two alternative > implementations of such a thing (which I find crazy), then make them > handle the fall-out, and ensure that one kicks out the other. > > In general I would say: it would be a good idea if the upgrade tools > would: > > a) when enabling /system-update check if it exists first. If so, print >a warning of "uprgade is already scheduled, refusing", or so... > > b) after the reboot, when initializing, make a quick check where >/system-update points. Become only active it it points where you >placed it. If it points anywhere else, assume somebody else changed >it, and log about this, and exit cleanly, so that no error is >triggered. > > Both these rules appear to be generally recommended for robustness > reasons. We should probably add this to the wiki. OK, this matches fairly exactly what I wrote in "version 2" later in the thread: http://lists.freedesktop.org/archives/systemd-devel/2015-July/033623.html > > Also, which is a minor thing, but related: OnFailure=reboot.target > > seems inferior to FailureAction=reboot. IIRC, the second one uses > > irreversible transaction and should be more robust. It also is a > > higher level setting in some sense. OnFailure=reboot.target is taken > > directly from the spec, so should be changed there first. > > I think I agree. > > > Also, another related issue: packagekit-offline-update.service has > > Type=simple. (In the log above it is "started" almost immediately, so > > system-update.target could be reached while it is still running.) This > > should be Type=oneshot. > > Probably, yes. > > > It seems that failure handling is already shaky, but I think there more > > failure modes. Let's say that 'dnf fedup upgrade' didn't work for some > > reason (missing ConditionPathExists file, dnf installation problem, > > whatever). > > Then nothing would remove the /system-update link, and we would reboot, > > and run system-update.target again, and reboot, and run > > system-update.target. > > It figure that's a general problem: we need some scheme how we can > count unsuccessful boots, with some form of roll-back if some limit is > reached. But I think this is material for another discussion and needs > support in the boot loader (there has been work to add this to > sd-boot/gummiboot). Ack. > > In general, creating /system-update without a working update service > > is enough to enter an infinite reboot loop. > > Well, it's how UNIX works... > > That said, if fedup wants to avoid the risk of this it might choose to > remvoe the symlink before starting its actual work... It removes the symlink right now when it is launched. Yeah, that should be good enough. > > > To summarize, following changes to the spec are proposed: > > - use Condition* or similar to conditionalize whether a specific > > upgrade mechanism should run > > I'd really recommend actually comparing the symlink target and doing > that in the C code of the upgrade tool. > > > - use Action=reboot > > - use Type=oneshot > > Both sound right. > > > - check that logind.Reboot() is not called on failure by the service > > i figure, too. > > > - services should not look for /systemd-update symlink, > > and the symlink should be removed by tmpfiles before we even get to > > the upgrade. > > I disagree, see above. OK, I think we're pretty much in agreement. I'd like to take the opportunity to convert the wiki page to a man page. It would be easier to discuss and track changes then. ? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /var/lib/machines be a mounted subvolume rather than an actual subvolume?
On Thu, 16.07.15 12:40, Chris Murphy (li...@colorremedies.com) wrote: > Resurrection of related thread "systemd and nested Btrfs subvolumes" from > March: > http://lists.freedesktop.org/archives/systemd-devel/2015-March/029666.html > > The question: > I understand the argument for subvolumes for containers below > /var/lib/machines. I don't understand what feature(s) of Btrfs > subvolumes will be leveraged for /var/lib/machines itself, and why it > isn't just a regular directory that then contains whatever subvolumes > are needed? so that you can apply quota not only on the individual containers, but on them all together, as well as query disk usage of the all summed up. > The problem: > On openSUSE, it uses subvolumes at the top level of the file system > (in subvolid 5) to make certain things exempt from snapshotting and > rollback: like logs, mail, bootloader, and system settings. See the > fstab in the above URL to see the listing. > > The fstab containing that long list of subvolumes to mount ensures > that those identical subvolumes are always used no matter what > subvol/snapshot the user rollsback to. > > But there isn't an fstab entry for /var/lib/machines. So a.) it won't > get snapshot by snapper and b.) if a rollback is done, the backing > subvolume containing all the nspawn container subvolumes won't be > mounted, it will be empty. > > The solution: > The implied fix for this is to create the subvolume > /var/lib/machines at installation time, and add it to fstab > to always mount at /var/lib/machines (a directory found in all > snapshots of /). > https://features.opensuse.org/319287 > > As a consequence, it means if there's a rollback, it's not possible to > delete /var/lib/machines - its contents can be deleted but a mounted > subvolume can't be. > > Hence the question, rephrased, does systemd expect /var/lib/machines > to be an actual subvolume rather than a mountpoint backed by a mounted > subvolume? No. it can be anything. systemd will create it as subvol if it is missing, and you will get more features if it is a subvolume (like the quota/disk usage stuff menionted above) but it degrades gracefully if it is just a normal dir. 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] Odd /proc/$pid/fd symlinks in nspawn container
On Mon, 27.07.15 21:08, Ben Gamari (b...@smart-cactus.org) wrote: > Lennart Poettering writes: > > > On Mon, 27.07.15 20:29, Ben Gamari (b...@smart-cactus.org) wrote: > > > >> Lennart Poettering writes: > >> > >> > On Fri, 17.07.15 12:23, Ben Gamari (b...@smart-cactus.org) wrote: > >> > > >> snip > >> > >> >> Why might this be the case? Does nspawn prevent the process from getting > >> >> a controlling tty? > >> > > >> > The pty setup code changed in nspawn evrsions, hence it is important > >> > to say which version you are running? > >> > > >> Ahh, of course. This is a Debian sid machine, so systemd 221. > > > > That's pretty recent. Any chance you can strace this, checking where > > this "/7" file comes from? > > > Sure. > > This Gist [1] is the output from I think you forgot to add a footnote there... 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] systemd as Docker process manager (was: Docker, Supervisor and systemd)
On Sun, 19.07.15 22:38, Paul Menzel (paulepan...@users.sourceforge.net) wrote: > 1. The capability `SYS_ADMIN` has to be given(?) to the Docker > container. > > --cap-add SYS_ADMIN systemd should work OK now even if you don't pass the cap. That said, this takes away the effect of things like PrivateNetwork=, PrivateDevices=, PrivateTmp= and other namespace-related things from the containers, as well as a few other things. Hence I'd not recommend doing that, the kernel isn't really ready for this... > So a container with that capability won’t be that contained anymore. Currently, containers on Linux are not a security technology. Don't mistake them for that. Without --private-users there are more holes in them than in swiss cheese. And even if you do use that, it's still no security technology, yet. > 2. systemd-docker [4][7] > > Quoting the systemd-docker README.md [4]: > > > Why I wrote this? > > > > The full context is in Docker Issue #6791 [5] and this mailing list > > thread [6]. The short of it is that systemd does not actually > > supervise the Docker container but instead the Docker client. This > > makes systemd incapable of reliably managing Docker containers > > without hitting a bunch of really odd situations. > > Is it planned to solve this in systemd somehow or is it a Docker issue > from systemd’s standpoint? THis is something to fix in Docker. rkt handles this much nicer btw. > 3. There must also have been some “container improvements” between > systemd 215 and 221. At least I think, that running systemd 215 in the > container with Debian Jessie/stable it starts unnecessary(?) processes > like systemd-udev, while that doesn’t happen when Debian > Stretch/testing with systemd 221 [8] is used. `systemctl status` and > `ps aux` just show the journal and the configured programs like Cron > and Rsyslog. > > Is that just equivalent of deleting the “wants targets”, Dan talked > about in his blog post [1][2], or some big code changes? Would that be > easily “backportable” to systemd 215? We have adjusted systemd all the time. Especially to make it work in CAP_SYS_ADMIN-less and userns containers. But please don't ask me which fix we made when, that'd be a lot of work to figure out. I can only direct you towards the git history for that. > 4. Current developments > > Is there an overview of the latest developments in this regard, like > logging and other things? So many things are created and developed, > that I might have missed something. > > Like some parser of Docker Compose configuration files creating systemd > unit files from it? I am not invovled with Docker, I cannot really answer these questions. > Or should Docker be avoided anyway, because systemd-nspawn or something > similar does something similar in a much easier fashion? Well Docker solves a different problem set, such as orchestration over multiple machines in a cluster, it has build tools and whatnot. nspawn is just a container executor, with a focus on reusing existing standards, and good intgeration of the rest of the OS. 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] Odd /proc/$pid/fd symlinks in nspawn container
Lennart Poettering writes: > On Mon, 27.07.15 20:29, Ben Gamari (b...@smart-cactus.org) wrote: > >> Lennart Poettering writes: >> >> > On Fri, 17.07.15 12:23, Ben Gamari (b...@smart-cactus.org) wrote: >> > >> snip >> >> >> Why might this be the case? Does nspawn prevent the process from getting >> >> a controlling tty? >> > >> > The pty setup code changed in nspawn evrsions, hence it is important >> > to say which version you are running? >> > >> Ahh, of course. This is a Debian sid machine, so systemd 221. > > That's pretty recent. Any chance you can strace this, checking where > this "/7" file comes from? > Sure. This Gist [1] is the output from $ strace -f -ohi systemd-nspawn --personality=x86-64 -D$MY_CHROOT and running `ls /proc/self/fd -lh` in the resulting shell. This produced, $ ls /proc/self/fd -lh total 0 lrwx-- 1 root root 64 Jul 27 15:02 0 -> /8 lrwx-- 1 root root 64 Jul 27 15:02 1 -> /8 lrwx-- 1 root root 64 Jul 27 15:02 2 -> /8 lr-x-- 1 root root 64 Jul 27 15:02 3 -> /proc/13/fd Where the links to /8 were broken. Cheers, - Ben signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persistent network device names
On Mon, 2015-07-27 at 21:53 +0300, Andrei Borzenkov wrote:
> В Mon, 27 Jul 2015 18:29:57 +
> "Keller, Jacob E" пишет:
>
> > On Mon, 2015-07-27 at 21:12 +0300, Andrei Borzenkov wrote:
> > > В Mon, 27 Jul 2015 17:52:59 +
> > > "Keller, Jacob E" пишет:
> > >
> > > > Hello,
> > > >
> > > > I am working with a network device that can create virtual
> > > > function
> > > > devices. When I create a large (>8) vfs for this device I get
> > > > some
> > > > weird device names,
> > > >
> > > > If I create 64 vfs, I see something like:
> > > >
> > > > ens8
> > > > ens8f[1-7]
> > > > ens8s[1-7]
>
> Are you sure? I do not see where such names would be generated.
>
Yes. These are generated via the hotplug section of udev-builtin
-net_id.c rules
on line: 230 or so.
The problem is that some of the devices are considered part of the
"hotplug" slot while others are not, so I get two conflicting schemes
depending on how it lands in the slot.
> > > > enp8s[1-7]f[1-7]
> > > >
> > >
> > > All those names come directly from kernel. udev does not invent
> > > them
> > > -
> > > this is exactly what lspci shows. If it does not match lspci, you
> > > should provide more information.
> > >
> > > > ens8f1-64 or something?
> > > >
> > >
> > > Then kernel should enumerate them so; you really need to discuss
> > > it
> > > there.
> >
> > It looks like my issue comes from the "hotplug_slot" stuff, which
> > overwrites the "enp8s0f0" into "ens8"... that is what causes this
> > dual
> > -name scheme confusion.
> >
>
> You can disable hotplug slot-based naming by setting suitable
> NamePolicy for network links (drop "slot").
How can I define my own version of the net_id which does what I would
like and run that in my udev rule? I assume IMPORT{program} of some
sort?
I'd like to write a single udev rule which does the right thing that I
can drop in, without having to modify the link files for every single
link.
One possible fix/change to the hotplug code is drop the ":00" at the
end of the slot.. this seems to be pretty consistent on my machine the
slots are all the :08:00.0 and we're comparing all of "08:00"
instead of "08" only. This plus making the func number be composed of
both the "slot" and "func".
But I am not sure this would work for everyone or not.
Regards,
Jake
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
On Mon, 27.07.15 15:37, Felipe Sateler (fsate...@debian.org) wrote: > On 27 July 2015 at 12:36, Lennart Poettering wrote: > > On Mon, 27.07.15 15:19, Felipe Sateler (fsate...@debian.org) wrote: > > > >> On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote: > >> > >> > Coming back to your original question, there are two options: > >> > > >> > 1) nfs-common becomes a normal multi-user.target service, but adds > >> >Before=remote-fs-pre.target. This way, the service is started at > >> >boot, and not only on first use. > >> > >> This would have the side effect of nfs-common not being started in single > >> user mode, which is not likely to be the wanted outcome. > > > > Well, then set DEfaultDEpendencies=no and pull it in by > > sysinit.target. But that's only OK if the service is capable of > > running in early-boot mode (i.e does not try to access /var and stuff). > > Or basic.target? The description of basic.target says: > > >> Usually this should pull-in all mount points, swap devices, sockets, > >> timers, > >> and path units and other basic initialization necessary for general purpose > >> daemons. > > Something that provides services for mountpoints could be hooked up here, no? > > The description of sysinit.target doesn't really tell me what this > target is all about, or how to choose between it and basic.target. Yeah, it's not obvious. Basically, sysinit.target is where all the small early-boot mini-services are pulled in. basic.target otoh pulls in the various other targets then, without pulling in any .mount, .service, .socket, ... units on its own. Or in other words: we group all early-boot services in sysinit.target, we group all mounts in local-fs.target, all swaps in swaps.target, all sockets in sockets.target, and so on, and then group all the aforementioned targets as basic.target. Makes sense? 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] persistent network device names
В Mon, 27 Jul 2015 18:29:57 + "Keller, Jacob E" пишет: > On Mon, 2015-07-27 at 21:12 +0300, Andrei Borzenkov wrote: > > В Mon, 27 Jul 2015 17:52:59 + > > "Keller, Jacob E" пишет: > > > > > Hello, > > > > > > I am working with a network device that can create virtual function > > > devices. When I create a large (>8) vfs for this device I get some > > > weird device names, > > > > > > If I create 64 vfs, I see something like: > > > > > > ens8 > > > ens8f[1-7] > > > ens8s[1-7] Are you sure? I do not see where such names would be generated. > > > enp8s[1-7]f[1-7] > > > > > > > All those names come directly from kernel. udev does not invent them > > - > > this is exactly what lspci shows. If it does not match lspci, you > > should provide more information. > > > > > ens8f1-64 or something? > > > > > > > Then kernel should enumerate them so; you really need to discuss it > > there. > > It looks like my issue comes from the "hotplug_slot" stuff, which > overwrites the "enp8s0f0" into "ens8"... that is what causes this dual > -name scheme confusion. > You can disable hotplug slot-based naming by setting suitable NamePolicy for network links (drop "slot"). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container
On Mon, 27.07.15 20:29, Ben Gamari (b...@smart-cactus.org) wrote: > Lennart Poettering writes: > > > On Fri, 17.07.15 12:23, Ben Gamari (b...@smart-cactus.org) wrote: > > > snip > > >> Why might this be the case? Does nspawn prevent the process from getting > >> a controlling tty? > > > > The pty setup code changed in nspawn evrsions, hence it is important > > to say which version you are running? > > > Ahh, of course. This is a Debian sid machine, so systemd 221. That's pretty recent. Any chance you can strace this, checking where this "/7" file comes from? 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] offline updates
On Tue, 21.07.15 03:27, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > [resending with the right systemd-devel address, sorry for that] > > Here are some thoughts on offline updates resulting from testing > the new dnf fedup plugin developed by Will Woods > [https://github.com/wgwoods/dnf-plugin-fedup]. > > I ran an update using dnf fedup and it works (or would have worked, if > stuff didn't happen), which is already great for something so simple, > but it exposes some shortcomings in the Offline Update spec itself > [http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/]. > > The main issues are: > - what happens when multiple offline mechanisms are present > - how is failure handled > > On my test system, I had packagekit-offline-update.service already > present when I installed the plugin and fedup-system-upgrade.service. > After running 'dnf fedup download ...' and 'dnf fedup reboot' > I saw something like this: I appears to be quite wrong to have a distro that is update in two ways. Pick one. Or if you really want to two alternative implementations of such a thing (which I find crazy), then make them handle the fall-out, and ensure that one kicks out the other. In general I would say: it would be a good idea if the upgrade tools would: a) when enabling /system-update check if it exists first. If so, print a warning of "uprgade is already scheduled, refusing", or so... b) after the reboot, when initializing, make a quick check where /system-update points. Become only active it it points where you placed it. If it points anywhere else, assume somebody else changed it, and log about this, and exit cleanly, so that no error is triggered. Both these rules appear to be generally recommended for robustness reasons. We should probably add this to the wiki. > Also, which is a minor thing, but related: OnFailure=reboot.target > seems inferior to FailureAction=reboot. IIRC, the second one uses > irreversible transaction and should be more robust. It also is a > higher level setting in some sense. OnFailure=reboot.target is taken > directly from the spec, so should be changed there first. I think I agree. > Also, another related issue: packagekit-offline-update.service has > Type=simple. (In the log above it is "started" almost immediately, so > system-update.target could be reached while it is still running.) This > should be Type=oneshot. Probably, yes. > It seems that failure handling is already shaky, but I think there more > failure modes. Let's say that 'dnf fedup upgrade' didn't work for some > reason (missing ConditionPathExists file, dnf installation problem, whatever). > Then nothing would remove the /system-update link, and we would reboot, > and run system-update.target again, and reboot, and run > system-update.target. It figure that's a general problem: we need some scheme how we can count unsuccessful boots, with some form of roll-back if some limit is reached. But I think this is material for another discussion and needs support in the boot loader (there has been work to add this to sd-boot/gummiboot). > In general, creating /system-update without a working update service > is enough to enter an infinite reboot loop. Well, it's how UNIX works... That said, if fedup wants to avoid the risk of this it might choose to remvoe the symlink before starting its actual work... > To summarize, following changes to the spec are proposed: > - use Condition* or similar to conditionalize whether a specific > upgrade mechanism should run I'd really recommend actually comparing the symlink target and doing that in the C code of the upgrade tool. > - use Action=reboot > - use Type=oneshot Both sound right. > - check that logind.Reboot() is not called on failure by the service i figure, too. > - services should not look for /systemd-update symlink, > and the symlink should be removed by tmpfiles before we even get to > the upgrade. I disagree, see above. 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] fstab generator and nfs-client.target
On 27 July 2015 at 12:36, Lennart Poettering wrote: > On Mon, 27.07.15 15:19, Felipe Sateler (fsate...@debian.org) wrote: > >> On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote: >> >> > Coming back to your original question, there are two options: >> > >> > 1) nfs-common becomes a normal multi-user.target service, but adds >> >Before=remote-fs-pre.target. This way, the service is started at >> >boot, and not only on first use. >> >> This would have the side effect of nfs-common not being started in single >> user mode, which is not likely to be the wanted outcome. > > Well, then set DEfaultDEpendencies=no and pull it in by > sysinit.target. But that's only OK if the service is capable of > running in early-boot mode (i.e does not try to access /var and stuff). Or basic.target? The description of basic.target says: >> Usually this should pull-in all mount points, swap devices, sockets, timers, >> and path units and other basic initialization necessary for general purpose >> daemons. Something that provides services for mountpoints could be hooked up here, no? The description of sysinit.target doesn't really tell me what this target is all about, or how to choose between it and basic.target. > >> > 2) nfs-common makes itself pulled in by network-online.target, and >> >orders itself before that. This way, the service is started when the >> >network is upped. >> >> Why isn't WantedBy=remote-fs.target an option? This would make any auto >> remote mount pull nfs-common, but if none is then it won't be started >> (unless that part of local-fs doesn't apply to remote-fs). > > Remote mount units do not pull that in. you can use it to mount all > remote mounts, but the remote mounts will not pull it in, the > dependency is only one way. Oh I misread the manpage. Thanks for clarifying. -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persistent network device names
On Mon, 2015-07-27 at 21:12 +0300, Andrei Borzenkov wrote: > В Mon, 27 Jul 2015 17:52:59 + > "Keller, Jacob E" пишет: > > > Hello, > > > > I am working with a network device that can create virtual function > > devices. When I create a large (>8) vfs for this device I get some > > weird device names, > > > > If I create 64 vfs, I see something like: > > > > ens8 > > ens8f[1-7] > > ens8s[1-7] > > enp8s[1-7]f[1-7] > > > > All those names come directly from kernel. udev does not invent them > - > this is exactly what lspci shows. If it does not match lspci, you > should provide more information. > > > ens8f1-64 or something? > > > > Then kernel should enumerate them so; you really need to discuss it > there. It looks like my issue comes from the "hotplug_slot" stuff, which overwrites the "enp8s0f0" into "ens8"... that is what causes this dual -name scheme confusion. Regards, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container
Lennart Poettering writes: > On Fri, 17.07.15 12:23, Ben Gamari (b...@smart-cactus.org) wrote: > snip >> Why might this be the case? Does nspawn prevent the process from getting >> a controlling tty? > > The pty setup code changed in nspawn evrsions, hence it is important > to say which version you are running? > Ahh, of course. This is a Debian sid machine, so systemd 221. Thanks for your help! Cheers, - Ben signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persistent network device names
On Mon, 2015-07-27 at 21:12 +0300, Andrei Borzenkov wrote: > В Mon, 27 Jul 2015 17:52:59 + > "Keller, Jacob E" пишет: > > > Hello, > > > > I am working with a network device that can create virtual function > > devices. When I create a large (>8) vfs for this device I get some > > weird device names, > > > > If I create 64 vfs, I see something like: > > > > ens8 > > ens8f[1-7] > > ens8s[1-7] > > enp8s[1-7]f[1-7] > > > > All those names come directly from kernel. udev does not invent them > - > this is exactly what lspci shows. If it does not match lspci, you > should provide more information. > > > ens8f1-64 or something? > > > > Then kernel should enumerate them so; you really need to discuss it > there. Hi, So what I see from lspci is 08:00.0 Ethernet controller 08:00.1 Ethernet controller 08:00.2 Ethernet controller 08:00.3 Ethernet controller 08:00.4 Ethernet controller 08:00.5 Ethernet controller 08:00.6 Ethernet controller 08:00.7 Ethernet controller 08:01.0 Ethernet controller 08:01.1 Ethernet controller 08:01.2 Ethernet controller 08:01.3 Ethernet controller 08:01.4 Ethernet controller 08:01.5 Ethernet controller 08:01.6 Ethernet controller 08:01.7 Ethernet controller 08:02.0 Ethernet controller 08:02.1 Ethernet controller 08:02.2 Ethernet controller 08:02.3 Ethernet controller 08:02.4 Ethernet controller 08:02.5 Ethernet controller 08:02.6 Ethernet controller 08:02.7 Ethernet controller 08:03.0 Ethernet controller 08:03.1 Ethernet controller 08:03.2 Ethernet controller 08:03.3 Ethernet controller 08:03.4 Ethernet controller 08:03.5 Ethernet controller 08:03.6 Ethernet controller 08:03.7 Ethernet controller 08:04.0 Ethernet controller 08:04.1 Ethernet controller 08:04.2 Ethernet controller 08:04.3 Ethernet controller 08:04.4 Ethernet controller 08:04.5 Ethernet controller 08:04.6 Ethernet controller 08:04.7 Ethernet controller 08:05.0 Ethernet controller 08:05.1 Ethernet controller 08:05.2 Ethernet controller 08:05.3 Ethernet controller 08:05.4 Ethernet controller 08:05.5 Ethernet controller 08:05.6 Ethernet controller 08:05.7 Ethernet controller 08:06.0 Ethernet controller 08:06.1 Ethernet controller 08:06.2 Ethernet controller 08:06.3 Ethernet controller 08:06.4 Ethernet controller 08:06.5 Ethernet controller 08:06.6 Ethernet controller 08:06.7 Ethernet controller 08:07.0 Ethernet controller but for some reason fedora22 shrinks "08:00:0" into ens8 instead of "enp8s0f0". That is the most annoying part of this. I can live with it if it were all consistent ie: enp8s0f0, enp8s0f1 and so forth. I don't think the kernel exports enough information to get "ens8f1-64", but the fact that I get weird orders like ens8 and then enp8s0 and then finally enp8s0f1-7 is what bothers me, and *that* is definitely not directly ported out of the kernel. Regards, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] UML: Fix block device setup
On Thu, 16.07.15 20:22, Thomas Meyer (tho...@m3y3r.de) wrote: > diff --git a/rules/60-persistent-storage.rules > b/rules/60-persistent-storage.rules > index 5ab03fc..0b14bb4 100644 > --- a/rules/60-persistent-storage.rules > +++ b/rules/60-persistent-storage.rules > @@ -6,7 +6,7 @@ > ACTION=="remove", GOTO="persistent_storage_end" > > SUBSYSTEM!="block", GOTO="persistent_storage_end" > -KERNEL!="loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|sr*|vd*|xvd*|bcache*|cciss*|dasd*", > GOTO="persistent_storage_end" > +KERNEL!="loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|sr*|vd*|xvd*|bcache*|cciss*|dasd*|ubd*", > GOTO="persistent_storage_end" Hmm, any chance you can post this as PR on github? 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] persistent network device names
On Mon, 2015-07-27 at 20:05 +0200, Lennart Poettering wrote: > On Mon, 27.07.15 17:52, Keller, Jacob E (jacob.e.kel...@intel.com) > wrote: > > > Hello, > > > > I am working with a network device that can create virtual function > > devices. When I create a large (>8) vfs for this device I get some > > weird device names, > > Not sure I fully grok, but is this about SR-IOV? > Yes, SR-IOV. > > "ens8" for physical device, but then ens8f for vf devices.. but > > I > > would like this to be generic for all devices that behave this > > way... > > and I was not sure how to do this. > > Can you even detect these kinds of devices? > > Lennart > I'm not sure if we can detect it or not. That may be an issue. The simplest fix would be to stop reducing "enp8s0" to "ens8" which appears to be what is going on today. either fedora changes this with a patch or upstream systemd comments are wrong, as: "multi-function cards with 2 ports" block says it should be enp8s0f0 but it seems to get shortened to ens8 instead? I'm still trying to grok the udev-builtin-net_id code to see if I can find a way to do this. Regards, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persistent network device names
В Mon, 27 Jul 2015 17:52:59 + "Keller, Jacob E" пишет: > Hello, > > I am working with a network device that can create virtual function > devices. When I create a large (>8) vfs for this device I get some > weird device names, > > If I create 64 vfs, I see something like: > > ens8 > ens8f[1-7] > ens8s[1-7] > enp8s[1-7]f[1-7] > All those names come directly from kernel. udev does not invent them - this is exactly what lspci shows. If it does not match lspci, you should provide more information. > ens8f1-64 or something? > Then kernel should enumerate them so; you really need to discuss it there. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persistent network device names
On Mon, 27.07.15 17:52, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: > Hello, > > I am working with a network device that can create virtual function > devices. When I create a large (>8) vfs for this device I get some > weird device names, Not sure I fully grok, but is this about SR-IOV? > "ens8" for physical device, but then ens8f for vf devices.. but I > would like this to be generic for all devices that behave this way... > and I was not sure how to do this. Can you even detect these kinds of devices? 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] Odd /proc/$pid/fd symlinks in nspawn container
On Fri, 17.07.15 12:23, Ben Gamari (b...@smart-cactus.org) wrote:
> Mantas Mikulėnas writes:
>
> > Note that devpts also supports multiple instances – the host /dev/pts is
> > not the same as the guest /dev/pts'en. So my guess is that your stdio is
> > attached to a pty from the *host*.
> >
> > Not really sure how that breaks job control though.
> >
> > Also, the fd symlinks are slightly magical; they can be followed and opened
> > even if readlink returns garbage. (For example, a socket fd or a pipe fd
> > wouldn't even *have* a path to return, yet the /proc symlink can be
> > opened.) So that again shouldn't cause problems.
> >
> Fair enough. In that case perhaps the lack of job control is due to,
>
> bash: cannot set terminal process group (-1): Inappropriate ioctl for
> device
>
> Indeed looking at jobs.c, it seems that bash tries to move the fd for
> its tty to a high number (255 in this case) and will then try using it
> to set the terminal process group. I see this pretty clearly in the
> strace output,
>
> $ sudo systemd-nspawn -D$(realpath centos6.5-amd64) /usr/bin/strace -f --
> bash -i
> ...
> 19617 dup2(3, 255) = 255
> 19617 close(3) = 0
> 19617 ioctl(255, TIOCGPGRP, [32695])= -1 ENOTTY (Inappropriate ioctl
> for device)
> 19617 ioctl(255, TIOCGPGRP, [32695])= -1 ENOTTY (Inappropriate ioctl
> for device)
> 19617 fstat(2, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 7), ...}) = 0
> 19617 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0x7fb741b8c000
> 19617 write(2, "bash: cannot set terminal proces"..., 77) = 77
>
> Note how both of the ioctls failed with ENOTTY, which according to the
> tcgetpgrp manpage means,
>
> The calling process does not have a controlling terminal, or it has one
> but it is not described by fd, or, for tcsetpgrp(), this controlling
> terminal is no longer associated with the session of the calling
> process.
>
> Why might this be the case? Does nspawn prevent the process from getting
> a controlling tty?
The pty setup code changed in nspawn evrsions, hence it is important
to say which version you are running?
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] Odd /proc/$pid/fd symlinks in nspawn container
On Fri, 17.07.15 10:22, Ben Gamari (b...@smart-cactus.org) wrote:
> I have been having quite some trouble getting nspawn give me a shell
> with proper job control in a CentOS 6.6 guest. The problem appears to be
> that the nodes representing the std{out,err,in} fds in /proc are
> malformed,
Hmm, such an old container payload is always problematic. Old distros
are not prepared to run in a container context, the differences are
too big.
In fact, I'd recommend running no OSes in contaienrs which do not
support this spec:
https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/
>
> $ sudo strace -f -obad systemd-nspawn -D$(realpath centos6.5-amd64)
> Spawning container centos6.5-amd64 on /home/ben/vm/centos6.5-amd64.
> Press ^] three times within 1s to kill container.
> Failed to create directory /home/ben/vm/centos6.5-amd64/sys/fs/selinux:
> Read-only file system
> Failed to create directory /home/ben/vm/centos6.5-amd64/sys/fs/selinux:
> Read-only file system
> /etc/localtime is not a symlink, not updating container timezone.
> -bash: cannot set terminal process group (-1): Inappropriate ioctl for
> device
> -bash: no job control in this shell
> -bash-4.1# ls -lh /proc/self/fd
> total 0
> lrwx-- 1 root root 64 Jul 17 04:14 0 -> /7
> lrwx-- 1 root root 64 Jul 17 04:14 1 -> /7
> lrwx-- 1 root root 64 Jul 17 04:14 2 -> /7
> lr-x-- 1 root root 64 Jul 17 04:14 3 -> /proc/13/fd
>
> Note that fds 0, 1, and 2 all point to a non-existent /7 file. I believe
> this should instead point to /dev/pts/7, although strangely this does
> not exist either despite /dev/pts being mounted. I am running a very
> recent (4.1) kernel.
Humm, this sounds like serious bug. Which nspawn version are you
running on the host? Note that upstream we focus on more recent
upstream versions of systemd only, please report issues with older
systemd versions downstream only.
Can you strace nspawn to see where the /7 comes from?
> Am I correct in assuming that this is not expected behavior? What am I
> missing here?
Nope, certainly not. It should point to /dev/pts/1.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] persistent network device names
Hello, I am working with a network device that can create virtual function devices. When I create a large (>8) vfs for this device I get some weird device names, If I create 64 vfs, I see something like: ens8 ens8f[1-7] ens8s[1-7] enp8s[1-7]f[1-7] If I create 64 vfs, I see something like: where [1-7] means repeated for 1-7. This is somewhat confusing and makes it difficult to textually process all vfs in scripts. I would imagine that we would want instead: ens8f1-64 or something? Would this be possible to add as an extention to the udev rule? I really am not sure how this is done today. Alternatively, at least always follow pattern so that we get enp8s0 enp8s0f1-7 enp8s1 and so on, this way we can rely on the octal notation without having to special case the first set of 8 vfs... Even figuring out how to customize udev for my case without it being default would be appreciated, as I do not mind having a rule that generates "ens8" for physical device, but then ens8f for vf devices.. but I would like this to be generic for all devices that behave this way... and I was not sure how to do this. Regards, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
On Mon, 27.07.15 13:25, Rich Freeman (r-syst...@thefreemanclan.net) wrote: > On Mon, Jul 27, 2015 at 10:51 AM, Lennart Poettering > wrote: > > > > If you are looking for a way to start this service only when an NFS > > mount is attempted, then I must disappoint you: there's currently no > > way to do this nicely, as you can neither express "applies only to > > NFS", nor is there a way to actively pull in things from remote > > mounts. > > Presumably if the .mount unit had Wants=nfs-common.target or something > similar it would pull it in when it mounts, right? That would > probably require a change to the generator to detect nfs shares and > add this. > > Whether you want to do it that way is a different matter. Yeah, we want to avoid such fs-specific hacks. Note that there's generic support via mount options for this via the x-systemd.requires= fstab option. See systemd.mount(5) for details. But that requires patching fstab of course. > > (There's a reason for both limitations: we try to avoid pull-deps on > > mounts, since we want to keep the effect of manually ordered > > /bin/mount invocations, and systemd-ordered .mount activations as > > close as possible.) > > Would it actually affect ordering? > > If the mount wants nfs-common and is after remote-fs-pre.target, and > nfs-common is before remote-fs-pre.target is after nfs-common, then > won't nfs-common be started before any remote fs are mounted? The > only change would be that the mount wants nfs-common, so that it is > started when it otherwise might not have been. > > Or am I missing something? What I tried to say is that we don't want to add too many implicit requirement deps to mounts, but only ordering deps, so that carefully paced manual /bin/mount invocations have pretty much the same effect as those done by systemd itself: the number of units pulled in should be the same. It's basically the same reason we never added ExecStartPre= or so to .mount units: the effect of "/bin/mount /foo" invocations should be similar to what systemd would do due to "systemctl start /foo", modulo the ordering. The executed commands should be the same. (Of course, if you use x-systemd.requires= as suggested above, or if you write manual .mount files, then the effect will be quite different, but then you did this explicitly, and hopefully knowingly, and that's OK. However we should be careful with too many automatisms there...) I hope that makes some sense, 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] fstab generator and nfs-client.target
On Mon, Jul 27, 2015 at 10:51 AM, Lennart Poettering wrote: > > If you are looking for a way to start this service only when an NFS > mount is attempted, then I must disappoint you: there's currently no > way to do this nicely, as you can neither express "applies only to > NFS", nor is there a way to actively pull in things from remote > mounts. Presumably if the .mount unit had Wants=nfs-common.target or something similar it would pull it in when it mounts, right? That would probably require a change to the generator to detect nfs shares and add this. Whether you want to do it that way is a different matter. > > (There's a reason for both limitations: we try to avoid pull-deps on > mounts, since we want to keep the effect of manually ordered > /bin/mount invocations, and systemd-ordered .mount activations as > close as possible.) > Would it actually affect ordering? If the mount wants nfs-common and is after remote-fs-pre.target, and nfs-common is before remote-fs-pre.target is after nfs-common, then won't nfs-common be started before any remote fs are mounted? The only change would be that the mount wants nfs-common, so that it is started when it otherwise might not have been. Or am I missing something? -- Rich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
On Mon, 27.07.15 15:19, Felipe Sateler (fsate...@debian.org) wrote: > On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote: > > > Coming back to your original question, there are two options: > > > > 1) nfs-common becomes a normal multi-user.target service, but adds > >Before=remote-fs-pre.target. This way, the service is started at > >boot, and not only on first use. > > This would have the side effect of nfs-common not being started in single > user mode, which is not likely to be the wanted outcome. Well, then set DEfaultDEpendencies=no and pull it in by sysinit.target. But that's only OK if the service is capable of running in early-boot mode (i.e does not try to access /var and stuff). > > 2) nfs-common makes itself pulled in by network-online.target, and > >orders itself before that. This way, the service is started when the > >network is upped. > > Why isn't WantedBy=remote-fs.target an option? This would make any auto > remote mount pull nfs-common, but if none is then it won't be started > (unless that part of local-fs doesn't apply to remote-fs). Remote mount units do not pull that in. you can use it to mount all remote mounts, but the remote mounts will not pull it in, the dependency is only one way. 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] fstab generator and nfs-client.target
On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote: > Coming back to your original question, there are two options: > > 1) nfs-common becomes a normal multi-user.target service, but adds >Before=remote-fs-pre.target. This way, the service is started at >boot, and not only on first use. This would have the side effect of nfs-common not being started in single user mode, which is not likely to be the wanted outcome. > > 2) nfs-common makes itself pulled in by network-online.target, and >orders itself before that. This way, the service is started when the >network is upped. Why isn't WantedBy=remote-fs.target an option? This would make any auto remote mount pull nfs-common, but if none is then it won't be started (unless that part of local-fs doesn't apply to remote-fs). -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker
On Sat, 25.07.15 18:11, SF Markus Elfring (elfr...@users.sourceforge.net) wrote: > Hello, > > I would like to clarify the setting of device file permissions > for my needs. > > So I extended the debug output at some source code places to see > also better which lines are executed during my tests. > I built these extensions for calls of the function "log_debug" > on the current source files (last commit: > 3460810e8c61986a4605ad80c9e4805eb95cb5a1) > with the software "GCC 5.2.0" on my openSUSE Tumbleweed system. > > I am experimenting a bit with this fresh server program. > > Sonne:~ # systemctl stop systemd-udevd.service systemd-udevd-kernel.socket > systemd-udevd-control.socket && > /home/elfring/Projekte/Bau/systemd/systemd-udevd --debug > > > Now I wonder about an error message like the following. > > … > adding watch on '/dev/dm-0' > … > seq 2633 forked new worker [19879] > seq 2633 running > IMPORT builtin 'usb_id' /usr/lib/udev/rules.d/40-libgphoto2.rules:9 > unable to access usb_interface device of > '/sys/devices/pci:00/:00:02.0/usb3/3-2/3-2:1.0' > IMPORT builtin 'usb_id' returned non-zero > IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:11 > worker [19879] terminated by signal 11 (Segmentation fault) > worker [19879] failed while handling > '/devices/pci:00/:00:02.0/usb3/3-2/3-2:1.0' > … > > I would appreciate your advices. > > I hope that I do not need to extend all log messages with additional > information details. > It would be nice if I could find the failure place easier within > a session with the help of a graphical debugger, wouldn't it? This should usually generate a coredump. Depending on the distro and its setup that coredump went to different places. Please ask your distro for help how to acquire it. If you have it, please use "gdb" to generate a stacktrace from it and provide it here. Thanks, 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] udev and dm inotify problems
On Sun, 26.07.15 11:39, Oleksii Shevchuk (alx...@gmail.com) wrote: > Andrei Borzenkov writes: > > > > > Could you verify with e.g. inotifywatch whether inotify event was > > generated by kernel? > > > > It turns out, that for some reason I have several dm devices: > > # ls -l /dev/mapper/ > crw-rw 1 root dialout 10, 236 ??? 25 09:52 control > brw--- 1 root root254, 12 ??? 25 09:52 _dev_dm_5 > lrwxrwxrwx 1 root root 7 ??? 25 09:52 Media-Doc -> ../dm-3 > lrwxrwxrwx 1 root root 7 ??? 25 09:52 Media-Music -> ../dm-1 > lrwxrwxrwx 1 root root 7 ??? 25 09:52 Media-Tmp -> ../dm-2 > lrwxrwxrwx 1 root root 7 ??? 25 09:52 OS-home -> ../dm-5 > lrwxrwxrwx 1 root root 7 ??? 25 09:52 OS-kernel -> ../dm-7 > lrwxrwxrwx 1 root root 7 ??? 25 09:52 OS-portage -> ../dm-4 > lrwxrwxrwx 1 root root 7 ??? 25 09:52 OS-prefix -> ../dm-8 > brw--- 1 root root254, 0 ??? 25 09:52 OS-root > lrwxrwxrwx 1 root root 8 ??? 25 09:52 OS-Software -> ../dm-10 > lrwxrwxrwx 1 root root 7 ??? 25 09:52 OS-var -> ../dm-9 > lrwxrwxrwx 1 root root 7 ??? 25 09:52 OS-VM -> ../dm-6 > brw--- 1 root root254, 11 ??? 26 11:36 swap << SWAP is here > > Also I have separate device - /dev/dm-11, with same major/minor. Most likely you built your LVM/dm userspace without proper udev support, or left support in there that creates device nodes on its own. Nowadays with devtmpfs device nodes are created exclusively by the kernel and userspace should never create a single device node. If your LVM/DM tools still do, then they have been built with incorrect build-time settings. Note that LVM/DM issues are probably better discussed at the LVM/DM mls than here... 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] Completion of error handling
On Sat, 25.07.15 08:11, SF Markus Elfring (elfr...@users.sourceforge.net) wrote: I am sorry Markus, but at this point you are just wasting our time. Be specific (i.e. by sending git patches, providing backtraces of crashes, or actual bug reports), otherwise this is of no help. I will now stop responding to your mails, unless you get more specific. 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] fstab generator and nfs-client.target
On Sun, 26.07.15 00:08, Andrei Borzenkov (arvidj...@gmail.com) wrote: > В Sat, 25 Jul 2015 12:50:39 +0200 > Michael Biebl пишет: > > > 2015-07-25 3:18 GMT+02:00 Rich Freeman : > > > I noticed that mount units for nfs shares created by the generator do > > > not Want=nfs-client.target or similar. > > > > > > That means that if you don't explicitly want nfs-client in your > > > configuration then nfs shares will get mounted, but services like > > > rpc-statd-notify.service won't run. > > > > > > Would it make sense to have the generator add the nfs-client target as > > > a want to nfs mount services it creates? > > > > remote mount units do have a "After remote-fs-pre.target" ordering and > > tools like nfs-common/rpcbind are supposed to hook up into > > remote-fs-pre.target. > > > > They are supposed to be /ordered before/ remote-fs-pre.target; but I do > not remember that remote-fs-pre.target itself was intended to pull > anything. This was designed as pure synchronization point. > > > http://www.freedesktop.org/software/systemd/man/systemd.special.html#remote-fs-pre.target > > > > --><-- > Note that this unit is generally not part of the initial transaction, > unless the unit that wants to be ordered before all remote mounts pulls > it in via a Wants= type dependency. > --><-- > > So if I read it, nfs-common should pull in remote-fs-pre, but that > leaves question what should pull in nfs-common itself. Remote mounts are ordered after network.target, after remote-fs-pre.target and after network-online.target. remote-fs-pre.target and network.target are indeed "passive", they should be pulled in by the service that wants to be the hook, not by the mount that uses it. r-f-p.t is specifically for network mounts in this case, while n.t is more generic. r-f-p.t is much stricter defined, while n.t is very loosely defined and mostly about shutdown order, not so much abotu startup order. n-o.t otoh is an "active" target, it's actively pulled in by all remote mounts, and hence can be used to add a service to the transaction as soon as a remote mount is attempted. Coming back to your original question, there are two options: 1) nfs-common becomes a normal multi-user.target service, but adds Before=remote-fs-pre.target. This way, the service is started at boot, and not only on first use. 2) nfs-common makes itself pulled in by network-online.target, and orders itself before that. This way, the service is started when the network is upped. If you are looking for a way to start this service only when an NFS mount is attempted, then I must disappoint you: there's currently no way to do this nicely, as you can neither express "applies only to NFS", nor is there a way to actively pull in things from remote mounts. (There's a reason for both limitations: we try to avoid pull-deps on mounts, since we want to keep the effect of manually ordered /bin/mount invocations, and systemd-ordered .mount activations as close as possible.) Hope this is useful, 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] Cannot mount anything after recovering and redoing boot mbr
On Mon, 27.07.15 01:18, Christopher Cox (c...@endlessnow.com) wrote: > I suspect that somebody here knows why, but all mounts now fail... well all > but /. > > Has anyone run across this before? What did I miss? > > I accidentally messed up my boot mbr. and I did a rescue cd and chroot in > order to rerun grub2-mkconfig and do a grub2-install. > > Now the system boots to a grub menu and tries to boot, root fileystem mounts > but all other mounts fail so goes into "emergency" mode. From that shell I > cannot seem to mount anything, they all fail saying that whatever I'm trying > to mount is already mounted or it's "in use". I can't fsck umounted > filesystems either. They all say "in use". Maybe your changed the order of your partitions or changed their partition UUID? If so, then /etc/fstab will reference incorrect partitions now. Make sure bring /etc/fstab into sync with your actual partitions. 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] systemd and $PATH
On Mon, Jul 27, 2015 at 02:15:31PM +0200, Miroslav Suchý wrote: > Hi, > is there anything in systemd what somehow manipulate $PATH. Systemd sets $PATH to a fixed value for services[1], with /sbin before /bin. But this shouldn't normally be visible in a user shell, unless it is run directly as a systemd service. [1] http://www.freedesktop.org/software/systemd/man/systemd.exec.html#%24PATH > I am asking because of: > https://bugzilla.redhat.com/show_bug.cgi?id=1246810 > which claims that when run as > systemd --user > it gets /usr/sbin at the begging of $PATH. > And I have no idea how can I run "systemd --user" command so I can not > reproduce it. You most likely have it running already. Try 'systemctl --user'. If that prints a list, then you are communicating with the systemd --user instance for your login id. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd and $PATH
Hi, is there anything in systemd what somehow manipulate $PATH. I am asking because of: https://bugzilla.redhat.com/show_bug.cgi?id=1246810 which claims that when run as systemd --user it gets /usr/sbin at the begging of $PATH. And I have no idea how can I run "systemd --user" command so I can not reproduce it. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Getting EOF on FD#1 stdout (a service using socat)
Am 2015-07-27 12:31, schrieb John Lane: I have a problem with what I thought would be a simple service unit: # /etc/systemd/system/socat.service [Service] ExecStart=/usr/bin/socat UDP-RECV:4321 STDOUT The expected outcome is that "/usr/bin/socat UDP-RECV:4321 STDOUT" is started with its standard output connected to the journal. However, the service terminates immediately without error. I've looked into it and notice that socat is getting an EOF on FD#1, its standard output, and it then terminates: N starting data transfer loop with FDs [5,5] and [1,1] N socket 2 (fd 1) is at EOF I close(5) N exiting with status 0 The command-line given in "ExecStart" works as expected if given on a command-line. systemd opens sockets that connect the stdout/stderr of a service to journald, but those sockets are unidirectional. This means that one cannot read from those file descriptors. But socat by default uses a bidirectional mode, and because it gets EOF when trying to read STDOUT, it will immediately terminate. Use the -u option to make socat work unidirectionally, then it should work: ExecStart=/usr/bin/socat -u UDP-RECV:4321 STDOUT (See the man page of socat for further details.) If you try it on the command line, the terminal you are using can in fact be opened for writing, so it will not get an EOF there (but you can use Ctrl+D when calling it manually to simulate that condition). Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Getting EOF on FD#1 stdout (a service using socat)
On Mon, 27.07.15 11:31, John Lane (syst...@jelmail.com) wrote: > I have a problem with what I thought would be a simple service unit: > > # /etc/systemd/system/socat.service > [Service] > ExecStart=/usr/bin/socat UDP-RECV:4321 STDOUT > > The expected outcome is that "/usr/bin/socat UDP-RECV:4321 STDOUT" is > started with its standard output connected to the journal. > > However, the service terminates immediately without error. I've looked > into it and notice that socat is getting an EOF on FD#1, its standard > output, and it then terminates: EOF on an output fd is bogus. EOF is when an input stream ends, it's indicated by read() returning 0 instead of > 0. It's not defined for output fds, as then EOF isn't an event you receive but an event you send. This hence seems like confusion on socat's side. Most likely they are treating a POLLHUP on the stdout fd as an EOF on stdin or so. They shouldn't do that, it's a bug only they can fix. 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] Getting EOF on FD#1 stdout (a service using socat)
> > Try using `socat -u` for unidirectional mode. > > Yes that was it. Thank you. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Getting EOF on FD#1 stdout (a service using socat)
On Mon, Jul 27, 2015 at 1:31 PM, John Lane wrote: > I have a problem with what I thought would be a simple service unit: > > # /etc/systemd/system/socat.service > [Service] > ExecStart=/usr/bin/socat UDP-RECV:4321 STDOUT > > The expected outcome is that "/usr/bin/socat UDP-RECV:4321 STDOUT" is > started with its standard output connected to the journal. > > However, the service terminates immediately without error. I've looked > into it and notice that socat is getting an EOF on FD#1, its standard > output, and it then terminates: > > N starting data transfer loop with FDs [5,5] and [1,1] > N socket 2 (fd 1) is at EOF > I close(5) > N exiting with status 0 > socat uses bidirectional streams by default, so if it says it hit EOF on "STDOUT", maybe it's treating it as alias to "STDIO" by default? Try using `socat -u` for unidirectional mode. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Getting EOF on FD#1 stdout (a service using socat)
I have a problem with what I thought would be a simple service unit: # /etc/systemd/system/socat.service [Service] ExecStart=/usr/bin/socat UDP-RECV:4321 STDOUT The expected outcome is that "/usr/bin/socat UDP-RECV:4321 STDOUT" is started with its standard output connected to the journal. However, the service terminates immediately without error. I've looked into it and notice that socat is getting an EOF on FD#1, its standard output, and it then terminates: N starting data transfer loop with FDs [5,5] and [1,1] N socket 2 (fd 1) is at EOF I close(5) N exiting with status 0 The command-line given in "ExecStart" works as expected if given on a command-line. I have tried adding an explicit "StandardOutput=journal" to the above but it made no difference. I expect I have got something wrong with my unit but I don't know what. Any pointers appreciated. Thanks. J ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev and dm inotify problems
В Mon, 27 Jul 2015 08:15:45 +0300 Oleksii Shevchuk пишет: > Andrei Borzenkov writes: > > > So that it the problem. Does it happen if you use cryptsetup directly? > > Yes, with cryptsetup behavior is the same. > > I have cryptsetup (1.6.7) and lvm2 (2.02.116). > > Btw, does your system behave differently? > Yes. bor@opensuse:~> sudo cryptsetup open --type plain /dev/mapper/system-docker --key-file /dev/urandom test bor@opensuse:~> LC_ALL=C ll /dev/mapper/ total 0 crw--- 1 root root 10, 236 Jun 28 11:05 control lrwxrwxrwx 1 root root 7 Jun 29 20:24 loop0p2 -> ../dm-5 lrwxrwxrwx 1 root root 7 Jun 28 11:05 system-datastore -> ../dm-3 lrwxrwxrwx 1 root root 7 Jul 27 12:18 system-docker -> ../dm-4 lrwxrwxrwx 1 root root 7 Jun 28 11:05 system-home -> ../dm-2 lrwxrwxrwx 1 root root 7 Jun 28 11:05 system-root -> ../dm-1 lrwxrwxrwx 1 root root 7 Jun 28 11:05 system-swap -> ../dm-0 lrwxrwxrwx 1 root root 7 Jul 27 12:18 test -> ../dm-6 bor@opensuse:~> rpm -q cryptsetup device-mapper cryptsetup-1.6.6-1.1.x86_64 device-mapper-1.02.78-20.2.2.x86_64 bor@opensuse:~> You should ask on cryptsetup/device-mapper list why it behaves differently in your case. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot mount anything after recovering and redoing boot mbr
On Mon, Jul 27, 2015 at 01:18:55AM -0500, Christopher Cox wrote: > I suspect that somebody here knows why, but all mounts now fail... well all > but /. > > Has anyone run across this before? What did I miss? I have seen this happen when I was using a kernel that was old and didn't have CONFIG_FHANDLE turned on (there now exists a work-around using /proc/self/fdinfo if your kernel is new enough), which may be worth checking, but given your later comments about manually mounting failing, this seems less likely to be the problem. > I accidentally messed up my boot mbr. and I did a rescue cd and > chroot in order to rerun grub2-mkconfig and do a grub2-install. > > Now the system boots to a grub menu and tries to boot, root > fileystem mounts but all other mounts fail so goes into "emergency" > mode. From that shell I cannot seem to mount anything, they all > fail saying that whatever I'm trying to mount is already mounted or > it's "in use". I can't fsck umounted filesystems either. They all > say "in use". This sounds like a udev malfunction to me, but I'm not familiar enough with how it works to do any more than guess. My best guess is that there's some locking going wrong, since udevd will flock(…, LOCK_SH|LOCK_NB) device nodes, and fsck will flock(…, LOCK_EX|LOCK_NB), so udev doesn't try to use a device while it is being fsck'd. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
