Re: [systemd-devel] How to set a limit for mounting roofs?

2016-07-06 Thread Kai Krakow
Am Wed, 6 Jul 2016 06:21:17 +0200 schrieb Lennart Poettering : > On Mon, 04.07.16 12:32, Chris Murphy (li...@colorremedies.com) wrote: > > > 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 u

Re: [systemd-devel] How to set a limit for mounting roofs?

2016-07-06 Thread Kai Krakow
Am Wed, 6 Jul 2016 06:26:03 +0200 schrieb Lennart Poettering : > On Tue, 05.07.16 14:00, Chris Murphy (li...@colorremedies.com) wrote: > > > On Tue, Jul 5, 2016 at 12:45 PM, Chris Murphy > > wrote: > > > OK it must be this. > > > > > > :/# cat /usr/lib/udev/rules.d/64-btrfs.rules > > > # do no

Re: [systemd-devel] How to set a limit for mounting roofs?

2016-07-06 Thread Chris Murphy
On Wed, Jul 6, 2016 at 3:36 AM, Andrei Borzenkov wrote: > On Wed, Jul 6, 2016 at 7:26 AM, Lennart Poettering > wrote: >> I figure it would be OK to merge a patch that makes the udev rules >> above set SYSTEMD_READY immediately if the device popped up in case >> some new kernel command line optio

Re: [systemd-devel] Zero downtime restart of Web application (Nginx, Puma, JRuby)

2016-07-06 Thread David Timothy Strauss
You either need a load balancer (less elegant) or need to make use of the Linux kernel's SO_REUSEPORT option so the new application can bind to the same port as the old one (at which point the old application should unbind the port and shut itself down).

Re: [systemd-devel] does "Before=network.target" really work

2016-07-06 Thread Michael Biebl
2016-07-06 6:41 GMT+02:00 Lennart Poettering : > On Fri, 24.06.16 18:53, Xin Long (lucien@gmail.com) wrote: >> ./firewalld.service:Before=network.target > > The line for firewalld appears wrong btw. The firewall should really > be up before the network is even initiated. Hence it should be > Be

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Jóhann B . Guðmundsson
># gnome-user-graphical.target > >[Unit] >Description=User systemd services for graphical session >StopWhenUnneeded=yes So this is just another name for "my" gnome.target/gnome-session.target. As I said I'm not too fussed about how we name those, we should just decide about some convention.

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Martin Pitt
Hello Jóhann, Jóhann B. Guðmundsson [2016-07-06 15:23 +]: > What I'm ( poorly ) trying to say is that you will need to make a clear > distinction of naming on the type units for the desktop environment and the > type units for the desktop environment user I don't understand the distinction be

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Jóhann B . Guðmundsson
On 07/06/2016 02:34 PM, Martin Pitt wrote: This /usr/lib/systemd/user/graphical.target (and only that)*does* belong in to systemd, as it cannot sensibly be in any gnome-session/mate-session/kde-session/etc. package -- it's a shared resource/synchronization point between all of those. Having a un

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Martin Pitt
Jóhann B. Guðmundsson [2016-07-06 14:02 +]: > Martin is proposing changes to and dependency's on the graphical.target I'm not changing anything. graphical.target as it exists in systemd today is for the *system* instance. I'm talking about the *user* instance, which has no graphical.target at

[systemd-devel] systemd-journald cannot recover after failed rotation due to disk space ?

2016-07-06 Thread Kemppainen, Heikki (Nokia - FI/Espoo)
Hi! Is it normal functionality or bug that systemd-journald cannot recover logging to journal automatically in case when: 1) root file system gets almoust full 2) journal rotation fails: [402131.473154] systemd-journald[93]: Failed to create new system journal: No space left on device 3) journal

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Jóhann B . Guðmundsson
On 07/06/2016 12:51 PM, Jan Alexander Steffens wrote: On Wed, Jul 6, 2016 at 2:21 PM Jóhann B. Guðmundsson mailto:johan...@gmail.com>> wrote: It's questionable if such application should reside in upstream systemd since arguably systemd should have never created the graphical.tar

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Martin Pitt
Hello Jan, Jan Alexander Steffens [2016-07-06 11:57 +]: > Note that systemd makes a difference between "gnome-session.service became > inactive" and "gnome-session.service gets stopped". A service terminating > by itself is the former. > > Requires= and PartOf= will only propagate the latter.

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Martin Pitt
Martin Pitt [2016-07-06 13:47 +0200]: > Simon McVittie [2016-07-05 10:27 +0100]: > > Could this be done by having the .desktop file in /usr/share/xsessions > > or /usr/share/wayland-sessions start an appropriate systemd user unit > > directly, and wait for it to terminate? > > There is currently n

Re: [systemd-devel] Standardizing names for graphical session units -- version 3, now working!

2016-07-06 Thread Martin Pitt
Andrei Borzenkov [2016-07-06 14:44 +0300]: > On Wed, Jul 6, 2016 at 2:25 PM, Martin Pitt wrote: > >$ cat .config/systemd/user/gnome-session.target > >[Unit] > >Description=User systemd services for GNOME graphical session > >Requires=graphical.target > >PartOf=graphical.target

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Jan Alexander Steffens
On Wed, Jul 6, 2016 at 2:21 PM Jóhann B. Guðmundsson wrote: > > It's questionable if such application should reside in upstream systemd > since arguably systemd should have never created the graphical.target to > begin with ( if it had not we probably would not be having this discussion > since d

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Jóhann B . Guðmundsson
On 07/06/2016 08:50 AM, Colin Guthrie wrote: I'm not sure how this would work regarding things like g-s-d which you want in multiple DEs.. perhaps the gnome.target would have to be split up into gnome-base.target and gnome.target to allow for this use case? Or perhaps g-s-d could just become bus

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Jan Alexander Steffens
On Wed, Jul 6, 2016 at 1:50 PM Martin Pitt wrote: > Martin Pitt [2016-07-06 13:47 +0200]: > > I have a gut feeling that this should be expressible with systemd > > dependencies -- i. e. "if gnome-session.service stops, then stop > > gnome-session.target". Naïvely this would be > > "PartOf=gnome-s

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Martin Pitt
Simon McVittie [2016-07-05 10:27 +0100]: > On 04/07/16 21:01, Martin Pitt wrote: > > A session type like "GNOME" or "KDE" then defines which top-level > > servcies it wants. > > Could this be done by having the .desktop file in /usr/share/xsessions > or /usr/share/wayland-sessions start an appropr

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Martin Pitt
Martin Pitt [2016-07-06 13:47 +0200]: > I have a gut feeling that this should be expressible with systemd > dependencies -- i. e. "if gnome-session.service stops, then stop > gnome-session.target". Naïvely this would be > "PartOf=gnome-session.target" in gnome-session.service, but this does > not c

Re: [systemd-devel] Standardizing names for graphical session units -- version 2

2016-07-06 Thread Andrei Borzenkov
On Wed, Jul 6, 2016 at 2:25 PM, Martin Pitt wrote: >$ cat .config/systemd/user/gnome-session.target >[Unit] >Description=User systemd services for GNOME graphical session >Requires=graphical.target >PartOf=graphical.target > Is not this redundant? Requires=graphical.target alr

Re: [systemd-devel] Standardizing names for graphical session units -- version 2

2016-07-06 Thread Martin Pitt
Hello all, Colin, Jan, Zbigniew, thanks for your input! Based on that I have an updated proposal. Jan Alexander Steffens [2016-07-06 9:44 +]: > On Wed, Jul 6, 2016 at 10:51 AM Colin Guthrie wrote: > > Not commenting on the general approach (which I did read and broadly > > agree with withou

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Colin Guthrie
Jan Alexander Steffens wrote on 06/07/16 10:44: > On Wed, Jul 6, 2016 at 10:51 AM Colin Guthrie > wrote: > > Martin Pitt wrote on 04/07/16 23:08: > >> > Why would you call it graphical-<$DE>.slice as opposed to > simply <$DE>.slice > >> > which is part

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Jan Alexander Steffens
On Wed, Jul 6, 2016 at 10:51 AM Colin Guthrie wrote: > Martin Pitt wrote on 04/07/16 23:08: > >> > 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 upstrea

Re: [systemd-devel] How to set a limit for mounting roofs?

2016-07-06 Thread Andrei Borzenkov
On Wed, Jul 6, 2016 at 7:26 AM, Lennart Poettering wrote: > On Tue, 05.07.16 14:00, Chris Murphy (li...@colorremedies.com) wrote: > >> On Tue, Jul 5, 2016 at 12:45 PM, Chris Murphy >> wrote: >> > OK it must be this. >> > >> > :/# cat /usr/lib/udev/rules.d/64-btrfs.rules >> > # do not edit this f

Re: [systemd-devel] Samba Server dosen't start

2016-07-06 Thread Reindl Harald
Am 06.07.2016 um 07:12 schrieb Lennart Poettering: On Sun, 26.06.16 14:28, Reindl Harald (h.rei...@thelounge.net) wrote: Am 26.06.2016 um 14:16 schrieb Tom H: On Sun, Jun 26, 2016 at 8:09 AM, Reindl Harald wrote: Am 26.06.2016 um 13:27 schrieb Ralf Recktenwald: Smb.conf how is that a s

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Colin Guthrie
Martin Pitt wrote on 04/07/16 23:08: >> > 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 o