Re: [systemd-devel] rpcbind.socket failing
On Wed, 2016-11-02 at 06:16 +0100, Kai Krakow wrote: > Do you still use DefaultDependencies=no? > > Then /usr is probably not available that early (now that it can start > much earlier due to /run being available). What's the exercise of > disabling default dependencies anyway? /usr is always available, it's mounted together with the root fs (normally by the initramfs if it is a separate partition). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] rpcbind.socket failing
On Tue, 2016-11-01 at 20:01 +0300, Andrei Borzenkov wrote: > 01.11.2016 18:47, Lennart Poettering пишет: > > DefaultDependencies=no now, which means you run in early boot, and > > then things become more complex, as /var is not around fully yet. > > > > Unit file had RequiresMountsFor=/var/run. If this is not enough to > ensure unit starts only after /var/run is mounted, then what exactly > RequiresMountsFor does? /var/run is not a mountpoint, it's an obsolete compatibility symlink to /run. Thus that RequiresMountsFor is satisfied as long as /var is mounted. The symlink is created by tmpfiles. Though even without correct dependencies on tmpfiles, I'd expect the symlink to already be around from previous boots on a persistent /var partition, so I don't know why that'd cause a visible failure. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] The auto login configuration can't pass the first appeared screen after reboot/shutdown
Hi, I am a Linux beginner user. Because the device is a tablet, I would like to can use it "take away" also without the attached wireless keyboard, that's why, I intend to use the auto login. I would like to resolve if it is posssible the next issues, without to install a login manager. It seams that the auto login could not pass the first screen appeared after reboot, or after shutdown. My auto login configuration http://paste.ubuntu.com/23412534/ ~/.xsession-errors http://paste.ubuntu.com/23413124/ /var/log/Xorg.0.log http://paste.ubuntu.com/23413137/ journalctl -b http://paste.ubuntu.com/23412613/ /var/log/Xorg.0.log https://paste.ubuntu.com/23357560/ systemctl status getty@tty1 http://paste.ubuntu.com/23412860/ After reboot it is stuck on the first appeared screen which it seams that is the systemd screen /dev/sda1: clean 1123123/1231312 files 12312312/13212312 blocks. The only way to pass this screen is to ctrl+alt+f1 and after that the autologin to x works automatically. I don't use any login manager, or any desktop environment, only jwm. I am 99% percent sure that the same config passed also the above systemd first screen On Ubuntu 16.10, but it seams that on Ubuntu 16.04 it can't. While the above screen is standing by the login manager which will appear after ctrl+alt+f1 is appearing "like a ghost" for a few "mili seconds" like it would trying to start in the background of the first screen /dev/sda1: clean 1123123/1231312 files 12312312/13212312 blocks. but it can't until I don't ctr+alt+f1. I appreciate. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The auto login configuration can't pass the first appeared screen after reboot/shutdown
On Wed, 02.11.16 17:53, Alin Craciunescu (alinxcraciune...@gmail.com) wrote: > Hi, > > I am a Linux beginner user. > > Because the device is a tablet, I would like to can use it "take away" also > without the attached wireless keyboard, that's why, I intend to use the > auto login. > > I would like to resolve if it is posssible the next issues, without to > install a login manager. Well, on systemd systems access to graphics devices/mice and so on is controlled via ACLs that are assigned to the foreground session's user. This only works if the session is properly registered, via pam_systemd. Normally this is done via a display manager such as gdm. gdm has an autologin mode, that just works, so your best option is to just use that. Many alternative display managers get this right too. If you don't want to use any of those, then your only option is to put together some replacement of your own, that does the correct registration. The registration for this is documented here: https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/ If I were you I'd just use an existing display manager. Otherwise you should really know what you do. Good luck, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] rpcbind.socket failing
On Wed, 02.11.16 06:16, Kai Krakow (hurikha...@gmail.com) wrote: > Am Tue, 1 Nov 2016 12:05:43 -0400 > schrieb Steve Dickson : > > > rpcbind.service: Failed at step EXEC spawning /usr/bin/rpcbind: No > > such file or directory > > Do you still use DefaultDependencies=no? > > Then /usr is probably not available that early (now that it can start > much earlier due to /run being available). What's the exercise of > disabling default dependencies anyway? No! systemd does not support /usr not being around from earliest boot on. If distros permit /usr being split out onto its own partition they must pre-mount it in the initrd, so that /usr is constantly available from the first moment of the host PID 1 to its last moment. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] rpcbind.socket failing
On Tue, 01.11.16 20:01, Andrei Borzenkov (arvidj...@gmail.com) wrote: > 01.11.2016 18:47, Lennart Poettering пишет: > > On Tue, 01.11.16 11:11, Steve Dickson (ste...@redhat.com) wrote: > > > >> > >> > >> On 10/31/2016 03:40 PM, Michael Biebl wrote: > >>> Why is it using /var/run (where /var could be on a separate partition) > >>> and not /run for the socket files? > >> > >> Historical reasons?? I guess that's way its always been > >> and never caused a problem... > > > > Yeah, it normally shouldn't create problems – however, you are setting > > DefaultDependencies=no now, which means you run in early boot, and > > then things become more complex, as /var is not around fully yet. > > Unit file had RequiresMountsFor=/var/run. If this is not enough to > ensure unit starts only after /var/run is mounted, then what exactly > RequiresMountsFor does? RequiresMountsFor= orders your unit so that the mount points required to make the specified path available are mounted first. It thus guarantees successful read access at the least. If used for regular services (by which I mean: non-early-boot services) it also gaurantees successful write access to the directories in question. However, during early boot things are a bit different: the kernel/initrd might pre-mount a number of dirs, but generally only in a read-only mode. Typically the root partition (on which /var is more often than not located) is read-only this early. Now, "systemd-remount-fs.service" service is responsible to adjust the mount flags in a way that they match what /etc/fstab defines. Hence, to summarize this differently: 1) if you are in late boot and just want to pull in mounts for some dir and don't want to rely on it being listed as "auto" in fstab, then use RequiresMountsFor= on it and you are happy 2) if you are in early boot and need read-only access to something, then use RequiresMountsFor= on it and you are happy 3) if you are in early boot and need write access to something, then use RequiresMountsFor= in combination with an After=systemd-remount-fs.service and you should be happy. Hope this makes sense, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] rpcbind.socket failing
On Tue, 01.11.16 12:42, Steve Dickson (ste...@redhat.com) wrote: > > > On 11/01/2016 12:14 PM, Reindl Harald wrote: > > > > > > Am 01.11.2016 um 17:05 schrieb Steve Dickson: > >> and I still getting the following errors > >> > >> rpcbind.socket: Failed to listen on sockets: No such file or directory > I though this was talking about /run/rpcbind.sock since > that's the only patch defined in that file... I didn't > even think it was talking about the patch to the > daemon since that's defined in the service file. > > >> Failed to listen on RPCbind Server Activation Socket. > >> Starting RPC Bind... > >> rpcbind.service: Failed at step EXEC spawning /usr/bin/rpcbind: No such > >> file or directory > >> rpcbind.service: Main process exited, code=exited, status=203/EXEC > >> Failed to start RPC Bind. > Maybe the ENOENT was being carried over to the socket file?? Oh yes, it was. This is because you are using an SELinux-based distro. And on those the label for the socket is calculated from the binary that will eventually be started on it. If that binary doesn't exist, the calculation and the socket binding will fail with ENOENT... But yeah, we should generate more useful errors in this case, indeed. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
