Re: [systemd-devel] How to set a limit for mounting roofs?
04.07.2016 21:32, Chris Murphy пишет: > I have a system where I get an indefinite > > "A start job is running for dev-vda2.device (xmin ys / no limit)" > > Is there a boot parameter to use to change the no limit to have a > limit? rd.timeout does nothing. It should. Use rd.break and examine unit configuration (systemctl show dev-vda2.device) as well as /run/systemd/system/dev-vda1.device.d. dracut is using infinite timeout by default indeed. > When I use rd.break=pre-mount and use > blkid, /dev/vda2 is there and can be mounted with the same mount > options as specified with rootflags= on the command line. So I'm not > sure why it's hanging indefinitely. I figure with > systemd.log_level=debug and rd.debug and maybe rd.udev.debug I should > be able to figure out why this is failing to mount. > In all cases I can remember this was caused by lack of CONFIG_FHANDLE support in kernel. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] audit support weirdness
On Tue, Jul 05, 2016 at 01:15:30AM +0200, Michał Zegan wrote: > Hello. > > There is a problem with current audit support in journald. it listens > for audit events, but those same audit events go to dmesg, making a lot > of garbage. There were patches for the kernel to not log to dmesg when journald is listening over netlink. I think they went in a while ago, so this should be fixed if you're using a new enough kernel. > Also, in case of a selinux enabled system, it generates huge amount of > audit output even if you do not want that, for example, pam generates > audit events for all pam stacks being traversed during user login, and > in addition this is doubled because dmesg. > This is even more of a problem because you cannot for example tell > journalctl to get all logs except audit and things like that, so it hits > readability. Yeah. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] audit support weirdness
Hello. There is a problem with current audit support in journald. it listens for audit events, but those same audit events go to dmesg, making a lot of garbage. Also, in case of a selinux enabled system, it generates huge amount of audit output even if you do not want that, for example, pam generates audit events for all pam stacks being traversed during user login, and in addition this is doubled because dmesg. This is even more of a problem because you cannot for example tell journalctl to get all logs except audit and things like that, so it hits readability. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Standardizing names for graphical session units
On Mon, Jul 04, 2016 at 10:01:48PM +0200, Martin Pitt wrote:
> Hello all,
>
> a while ago I started experimenting with converting Ubuntu's upstart
> graphical session to the user D-Bus and systemd session. This works
> nicely and naturally for services which don't need $DISPLAY and are
> not session specific, like pulseaudio or gvfs. However, others like
> nautilus, mutter, unity etc. are absolutely specific to the
> graphical session, so they need some shims to bind starting/stopping
> them to the lifetime of the graphical session instead of the user. I
> started a small discussion here in May [1].
>
> I now have a prototype [2] which converts about half of the graphical
> session to systemd units. We'll have a mini-sprint later in July to
> complete/formalize this, but I'd like to settle some ground work
> before. I don't think it makes much sense if every distro or project
> comes up with their own naming schema and approach for this, as this
> would again mean to introduce pointless diversion -- and one of
> systemd's goals is to reduce these between distros -- and consequently
> the inability to send/maintain these session service units upstream.
> So let's see whether we can reach some agreement and recommendation
> here and ship that upstream?
>
> One proposed home-grown solution [3] is to introduce an
> X11@${_DISPLAY}.target, but this isn't ideal: We shouldn't use "X11"
> when Wayland/Mir become increasingly popular, and this is too
> inflexible wrt. having multiple session types, such as "GNOME", "KDE",
> "Unity", or "i3": Some services may want to start in all or several of
> those (e. g. gnome-settings-daemon is useful in an Xfce or i3
> session), some others like gnome-shell are only being used in the
> "GNOME" session.
>
> There's two separate issues here, a "container" unit for the session
> services and how to start/stop them with the session.
>
> Container unit(s)
> -
> All services/programs that should start in a particular graphical
> session like "GNOME" or "Xfce" should be "bundled" by some wrapper
> unit, so that they can be shut down as a group when the session ends.
> target units would be the immediate natural choice, but are not
> actually that suitable:
>
> * Stopping a target doesn't (by default) stop its requirements
> (but maybe I'm just missing something here).
Hi Martin,
I don't think we should "misuse" slices for this. Slices are for
resource management, and reusing them for unit grouping will be
confusing for users. Also, using slices for this ties the target
hierarchy to the resource hierarchy.
I think we should instead enhance target units to provide missing
functionality. The most important thing would be to have something
like PartOf, but more nicely configured. PartOf=graphical-kde.target
would do the trick, but it would need to be configured in each
unit separately, which would mean that we'd need to duplicate each
unit for each target, which is unacceptable. I don't see a nice
way to achieve this with the current set of options. What about
adding DependenciesPartOf=yes|no on the target unit, with "yes"
meaning that we automatically add PartOf= dependencies to any service
which has a Wants= or Requires= dependency to the target.
> * You have to pre-define them, so we would need to have on-disk
> units for all session types like graphical-xfce.target,
> graphical-gnome.target, etc.
I don't think this is such a big problem. After all it's going to be
a few (3? 5?) units, and a file is needed to provide Description=
and Documentation= anyway.
I have to agree with Jóhann that "graphical-" part does not seem necessary.
I'd rather go for "kde-session.target", "gnome-session.target", etc.
And I don't think that the requirement for a unit file is a hurdle
for step-wise conversion. Once you want to convert, let's say, xfce,
you create xfce-session.target with some Description, and start linking
units to it through .wants or .requires dirs, and that's totally
independent of any other session.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Standardizing names for graphical session units
Hello Jóhann, Jóhann B. Guðmundsson [2016-07-04 20:53 +]: > Shipping an predefined desktop units arguably does not belong upstream since > it's just catering to one ( desktop ) out of three ( > embedded/server/desktop) target user base. Right, embedded/server would never start this new unit. But we also ship a graphical.target on the system side, even though that doesn't apply to servers either. This is just an extra two-line unit. Also, if that is really an issue, we do not *need* to ship an actual unit file for that -- we merely need to define what its name is, so that we can start shipping such units in upstream desktop projects. > It might result in other two target user base having to patch things > out in the environment. What would you need to patch out? Having an extra unused unit on them isn't going to cause any harm, other than the extra microsecond to read the unit file (but we already parse plenty). > Why would you call it graphical-<$DE>.slice as opposed to simply <$DE>.slice > which is part of the <$DE>.target and graphical target is link to that > <$DE>.target ( if shipped upstream it needs to be generic enough to cater > whatever is out there right ) target units don't work well as they don't stop their dependencies on stop, as I explained -- unless there's a trick which I'm missing? If you just make it a top-level slice like "gnome.slice", then you don't have a parent like "graphical.slice" any more which you can refer to in units. We certainly don't want to use the root slice (-.slice) as we don't want to kill *all* the user services on graphical logout. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Standardizing names for graphical session units
On 07/04/2016 08:01 PM, Martin Pitt wrote: Feedback appreciated! Shipping an predefined desktop units arguably does not belong upstream since it's just catering to one ( desktop ) out of three ( embedded/server/desktop) target user base. It might result in other two target user base having to patch things out in the environment. Why would you call it graphical-<$DE>.slice as opposed to simply <$DE>.slice which is part of the <$DE>.target and graphical target is link to that <$DE>.target ( if shipped upstream it needs to be generic enough to cater whatever is out there right ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to set a limit for mounting roofs?
I have a system where I get an indefinite "A start job is running for dev-vda2.device (xmin ys / no limit)" Is there a boot parameter to use to change the no limit to have a limit? rd.timeout does nothing. When I use rd.break=pre-mount and use blkid, /dev/vda2 is there and can be mounted with the same mount options as specified with rootflags= on the command line. So I'm not sure why it's hanging indefinitely. I figure with systemd.log_level=debug and rd.debug and maybe rd.udev.debug I should be able to figure out why this is failing to mount. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Solved] How to mount NFS prior to start postgresql from this volume
>-Ursprüngliche Nachricht- >Von: Lennart Poettering [mailto:lenn...@poettering.net] >Betreff: Re: [systemd-devel] How to mount NFS prior to start postgresql from >this volume > >Normally, if you want a service to run only after all NFS mounts are in place, >add an ordering dependency towards remote-fs.target to it. Specifically: add a >drop-in file >/etc/systemd/system/postgresql@.service.d/50-nfs.conf and write into it: > > > [Unit] > After=remote-fs.target > Thank You Lennart, your tip was the solution for my problem. Now all works as expected. Only one question remains: I do not understand, why the "@" in the directory-name is necessary or what it does. The other question about the dependency-cycle remains open, but I presume, this is a problem between Vmware and Debian. > So, there's an ordering cycle: basic.target → sysinit.target → > rpcbind.service → network-line.target → vmware-tools.service → basic.target. > Reach each arror in this as "After=" ordering. > >This suggests some borkage probably either in vmware-tools.service or in >rpcbind.service. Not sure why the latter wants to be ordered until after the >network is fully up, and not sure why > the former wants to be ordered before that... The key of the issue though is > that vmware-tools is declared a late-boot service (since it wants to be > ordered after basic.target) while > rpcbind.service is declared an early boot service (since it wants to be > ordered before basic.target), but of course that cannot be fulfilled, given > both their request for ordering towards > network-online.target. > > Consider asking your distro for help, or vmware. This is really borkage in > those unit files. Most likely rpcbind is most broken service in this regard. The Distro is a plain Debian 8.5 running on vmware 6.0 The Cycle comes from the init.d-file of the vmware-tools. ### BEGIN INIT INFO # Provides: vmware-tools # Required-Start: $local_fs # Required-Stop: $local_fs # X-Start-Before: $network # X-Stop-After: $network # Default-Start: 2 3 5 # Default-Stop: 0 6 # Short-Description: VMware Tools service # Description: Manages the services needed to run VMware Tools ### END INIT INFO I do not understand, how systemd interprets this information and builds its dependencies, this requieres more reading in the doku by me. Thank You for Your quick help. mit freundlichen Grüssen Wolfgang Wagner Systemadministration RIWA GmbH Gesellschaft für Geoinformationen Zwingerstr. 2, 87435 Kempten E-Mail: wolfgang.wag...@riwa-gis.de http://www.riwa-gis.de -- RIWA GmbH, Zwingerstrasse 2, 87435 Kempten Sitz der Gesellschaft: Kempten (Allgaeu) Registergericht: Amtsgericht Kempten, HRB 6480 Geschaeftsfuehrer: Dipl.-Ing. Guenter Kraus -- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
