[systemd-devel] Is masking an error?
Hi, on my systemd v208 + many patches from the Fedora 21 source RPM i get TWO error messages in my journal when I login as root: 09:27:58 systemd-logind[118]: Failed to start unit user@0.service: Unit user@0.service failed to load: No such file or directory. 09:27:58 systemd-logind[118]: Failed to start user service: Unit user@0.service failed to load: No such file or directory. But it was my decision as an admin to disable user sessions, by doing "ln -s /dev/null /etc/systemd/systemd/user@.service". In my case systemd runs in embedded devices and no one would use use user service files anyway -> tightly controlled environment. So, it would be better to a) only spit one message that this is masked and b) put that at debug level ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is masking an error?
Am 21.01.2014 09:33, schrieb Holger Schurig: > on my systemd v208 + many patches from the Fedora 21 source RPM i get > TWO error messages in my journal when I login as root: > > 09:27:58 systemd-logind[118]: Failed to start unit user@0.service: > Unit user@0.service failed to load: No such file or directory. > 09:27:58 systemd-logind[118]: Failed to start user service: Unit > user@0.service failed to load: No such file or directory. Since logind explicitly creates a "start" job for user@0.service, this is an error, since the service does not exist. > But it was my decision as an admin to disable user sessions, by doing > "ln -s /dev/null /etc/systemd/systemd/user@.service". In my case > systemd runs in embedded devices and no one would use use user service > files anyway -> tightly controlled environment. In such a case, wouldn't it be better to disable logind entirely (or even trim down the systemd installation to not include it)? Since you are not interested in user sessions, you need no resource control for user sessions. You don't need suspend/hibernate/shutdown/reboot for users either. Nor do you need configuration of device ACLs. So, I'd mask systemd-logind.service and remove pam_systemd.so from the PAM configuration (I think it's set so that failure is ignored anyway, but removing it should still be safer). signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is masking an error?
On Tue, Jan 21, 2014 at 1:01 AM, Thomas Bächler wrote: > So, I'd mask systemd-logind.service and remove pam_systemd.so from the > PAM configuration (I think it's set so that failure is ignored anyway, > but removing it should still be safer). It will detect a lack of systemd-logind and no-op, but its detection method is based on a directory systemd-logind creates on first start each boot. So, the proper way to disable systemd-logind is to mask it and either reboot or prune away the directory. Otherwise, pam_systemd will assume systemd-logind is present *even if it's been stopped*. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is masking an error?
Thomas, logind in conjunction with udev's tagging also sets some device ACLs correctly, which I like. I also like that I can have a protection to not reboot my system while a user is active. So I'm not ready to get rid of logind completely. I'd actually have used user sessions if starting a user-dbus (in text mode, not in X) and "systemd-run --user" would have worked with my vanilla v208. But it was a mess, so I solved that entireley differently. For now I have a yucky type=oneshot ExecStart=/bin/true service file in /etc/systemd/system/user@.service. This is very ugly, so I raised the question if announcing masked services as an *ERROR* is really the way to go. Every masking is a system admin decision, after all. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is masking an error?
> I'd actually have used user sessions Not sure if "I'd" translate to "I would have actually used". But that is what I meant :-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is masking an error?
On Tue, Jan 21, 2014 at 1:01 PM, Thomas Bächler wrote: > Am 21.01.2014 09:33, schrieb Holger Schurig: >> on my systemd v208 + many patches from the Fedora 21 source RPM i get >> TWO error messages in my journal when I login as root: >> >> 09:27:58 systemd-logind[118]: Failed to start unit user@0.service: >> Unit user@0.service failed to load: No such file or directory. >> 09:27:58 systemd-logind[118]: Failed to start user service: Unit >> user@0.service failed to load: No such file or directory. > > Since logind explicitly creates a "start" job for user@0.service, this > is an error, since the service does not exist. > systemd could certainly be intelligent enough to notice that template was deliberately masked by admin. That not exactly the same as "service does not exist". ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] build-sys: merge libsystemd-login into libsystemd
'Twas brillig, and Simon McVittie at 20/01/14 17:47 did gyre and gimble: > Choosing a default linker seems like a system-integration issue rather > than something individual upstreams should be doing. Yup, I'd rather keep things this way too if possible. It can often catch integrators off-guard. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Debugging acl settings for /dev//snd/pcm* nodes
Hi, On 01/20/2014 10:54 AM, Colin Guthrie wrote: 'Twas brillig, and Hans de Goede at 20/01/14 08:42 did gyre and gimble: Hi, For some reason after I've built the Xorg xserver from git, and then login through gdm (on an otherwise unmodified F-20 install), the acls on /dev/snd/pcm* (and likely others too) no longer get setup to give the user I've just logged in with access to them. Reverting to Xorg from the F-20 packages fixes this. I was wonder if someone could give a short step by step of all components involved in doing the acl management for devices which should be usable by console users now a days. As well as some hints for debugging this. Ultimately, the ACLs are applied to the active session to all device nodes which have the uaccess tag. e.g. on my machine: [colin@jimmy code (master)]$ udevadm info /dev/snd/pcmC0D0p P: /devices/pci:00/:00:1b.0/sound/card0/pcmC0D0p N: snd/pcmC0D0p E: DEVNAME=/dev/snd/pcmC0D0p E: DEVPATH=/devices/pci:00/:00:1b.0/sound/card0/pcmC0D0p E: MAJOR=116 E: MINOR=3 E: SUBSYSTEM=sound E: TAGS=:uaccess: E: USEC_INITIALIZED=62743 Notice the uaccess tag. Ultimately this is applied to the "active" session, so you have to look to loginctl: [colin@jimmy code (master)]$ loginctl SESSIONUID USER SEAT 1603 colinseat0 20603 colinseat0 I seem to have two sessions here. I'll look a the first one: [colin@jimmy code (master)]$ loginctl show-session 1 Id=1 Timestamp=Thu 2014-01-16 12:34:44 GMT TimestampMonotonic=41640698 VTNr=1 Display=:0 Remote=no Service=gdm-password Scope=session-1.scope Leader=3563 Audit=1 Type=x11 Class=user Active=no State=closing IdleHint=no IdleSinceHint=1389896019397017 IdleSinceHintMonotonic=20376502012 Name=colin OK, this one is NOT active and is closing. This is likely an older session that has since been replaced after logging out and back in again but it keeps some binaries running (likely gpg-agent stuff at a first guess). Lets look: [colin@jimmy code (master)]$ loginctl session-status 1 1 - colin (603) Since: Thu 2014-01-16 12:34:44 GMT; 3 days ago Leader: 3563 Seat: seat0; vc1 Display: :0 Service: gdm-password; type x11; class user State: closing Unit: session-1.scope ├─3647 ssh-agent ├─3672 gpg-agent --daemon ├─3889 /usr/bin/pulseaudio --start --log-target=syslog ├─3898 /usr/libexec/pulse/gconf-helper └─6871 gpg-agent --keep-display --daemon --write-env-file /root/.gnupg/gpg-agent-info Yup, in this case, I have my ssh-agent, gpg-agent and PulseAudio services all loaded under the previous session. They didn't timeout and stop after my logout and as things are not setup to kill all processes, the session stays around in it's closing state. This is, so far, not overly surprising even if the whole situation there is a little messy (having the "closing" session live on as a kind of expected thing). Anyway, looking at session 20: [colin@jimmy code (master)]$ loginctl show-session 20 Id=20 Timestamp=Thu 2014-01-16 18:15:14 GMT TimestampMonotonic=20471336546 VTNr=1 Display=:0 Remote=no Service=gdm-password Scope=session-20.scope Leader=17287 Audit=20 Type=x11 Class=user Active=yes State=active IdleHint=no IdleSinceHint=1390208956248075 IdleSinceHintMonotonic=138343463253 Name=colin It IS active, and thus my ACLs should be in place. To actually debug the process of the uaccess tag and the device chowining etc. you'd have to look more into logind itself and perhaps turn on systemd debugging to see what it says about it (that said, I'm not sure what debug it actually shows about this operation). Certainly if the above bits are all working OK, then you can start to probe further. If you don't have an active session then this is likely what's wrong. Note that logging in via a tty and using e.g. startx *can* lead to this situation unless the VT is reused for X11 which is not the default upstream behaviour AFAIK. Most downstreams patch this behaviour in in some way however, but worth pointing out just in case that's what's tripping you up. Thanks, very useful info. This seems to be caused by some of my own changes to Xorg. For those interested: It seems that the problem is that gdm starts Xorg without a controlling tty, and some of the patches I've to make Xorg run without root rights cause /dev/tty1 to no longer automatically become the controlling tty of Xorg when it opens it. And then "loginctl show-session" says: VTNr=0 Active=no And hence no acls on /dev/snd/pcm* (and others) The problem is that Xorg needs to become session leader to get a controlling tty assigned, but if it does that (by calling setsid) then if the tty is already controlling another session it won't become Xorg's controlling tty and Xorg cannot make various VT_FOO ioctls without root rights.
Re: [systemd-devel] remove duplicate includes
On Wed, Nov 20, 2013 at 10:54:15PM +0100, Lennart Poettering wrote: > On Tue, 19.11.13 02:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > > > On Mon, Nov 18, 2013 at 02:48:14PM +0100, Karel Zak wrote: > > > A few trivial patches... the duplications found by > > > https://raw.github.com/karelzak/util-linux/master/tools/checkincludes.pl > > Wow. Applied in one big fell swoop. > > I'd be happy to also apply a patch that adds that tool to our tree so > that we can easily rerun it again... Do you want the script in the top level directory? .. in util-linux we usually use tools/ subdirectory for such things. It seems that in systemd source tree it would be possible to move things like make-directive-index.py, make-man-index.py, make-man-rules.py and xml_helper.py to the subdirectory too. Karel -- Karel Zak http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] remove duplicate includes
On Tue, Jan 21, 2014 at 04:50:24PM +0100, Karel Zak wrote: > On Wed, Nov 20, 2013 at 10:54:15PM +0100, Lennart Poettering wrote: > > On Tue, 19.11.13 02:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > wrote: > > > > > > > > On Mon, Nov 18, 2013 at 02:48:14PM +0100, Karel Zak wrote: > > > > A few trivial patches... the duplications found by > > > > https://raw.github.com/karelzak/util-linux/master/tools/checkincludes.pl > > > Wow. Applied in one big fell swoop. > > > > I'd be happy to also apply a patch that adds that tool to our tree so > > that we can easily rerun it again... > > Do you want the script in the top level directory? .. in util-linux > we usually use tools/ subdirectory for such things. > > It seems that in systemd source tree it would be possible to move > things like make-directive-index.py, make-man-index.py, > make-man-rules.py and xml_helper.py to the subdirectory too. I don't have particular feeling either way. They are not called directly, so the location is an implementation detail. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] bug: AVC denial when systemd-journald set to write to separate btrfs subvolume
This is a follow-up on this thread about directing the journal to a btrfs subvolume, if it's desired to maintain one journal even when booting other snapshots (such as doing a rollback): http://lists.freedesktop.org/archives/systemd-devel/2014-January/016253.html When I do this, systemd-journald tries to change permissions on /var/log/journal but selinux prohibits it. I think it's because such permission change isn't to a directory, but rather a mount point which would affect the permissions of the subvolume. So this could very well be user error, and instead I need to make the subvolume permissions and ownership correct, and not expect that systemd can or should do this. But I figure it's better to ask. AVC denial when systemd-journald set to write to separate btrfs subvolume https://bugzilla.redhat.com/show_bug.cgi?id=1056309 Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
