Re: [systemd-devel] Start a global service

[Damien Robert]

Lennart Poettering  wrote in message
<20170215172159.GA10587@gardel-login>:

> Sorry, but this is unlikely to be added. I understand that this would be
> handy, but this is semantically very questionable, as this would be
> transition from privileged code into unprivileged code, and that's
> something we can't really have.

Ok, I understand, I'll just parse /run/user/*/systemd to get the active
users (loginctl list-users is not very machine friendly)

> systemd is not really a battery manager, use services like upower for
> that, which do provide similar hooks.

Fair enough. But I don't really see the point to have a daemon that will
just listen to udev events for power change (udevd does other things which
I do not need). I prefer my solution which calls directly systemd services.

Thanks,
Damien Robert

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Start a global service

[Damien Robert]

1) Feature request

I would like a way [as root] to start a service on all active user sessions.
Typically to start a user service that was installed globally.

sudo systemctl --global start myservice.service

will start myservice.service as a root user service, not on the other user
sessions.

2) Feature request

Something that could be usefull too is a special target (both for the user
and system sessions) that is started automatically when there is ac loss,
so that we run on battery, and conversely. We could even imagine systemd
calling hooks like for systemd-sleep.

It is of course not hard to do that on the system session with a udev rule,
but I don't know how to start one automatically on the user sessions (hence
my feature request above).

I call my targets power-save.target and power-performance.target, but the
name may not be generic enough, maybe something like ac-loss.target,
ac-gain.target?

3) Usage

Here is my current implementation of a system wide special power-save target.

- In /etc/udev/rules.d, a rule:
ACTION=="change", SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="[01]", 
RUN+="/usr/local/lib/powersave/bin/power-dispatcher %E{POWER_SUPPLY_ONLINE}"

- power-dispatcher:
if (($1)); then # 1 = plug
  systemctl --no-block start power-performance.target
else # 0 = battery
  systemctl --no-block start power-save.target
fi

- power-performance.target:
[Unit]
Description=System power management: performance mode
Conflicts=power-save.target

- power-save.target:
[Unit]
Description=System power management: power-saving mode
Conflicts=power-performance.target
After=power-performance.target

- power-save.service:
[Unit]
Description=Powersave mode (global service)
PartOf=power-save.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStartPre=-/usr/bin/sleep 10
ExecStart=/usr/local/lib/powersave/bin/powersave true

[Install]
WantedBy=power-save.target

- power-performance.service:
[Unit]
Description=Power performance mode (global service)
PartOf=power-performance.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/local/lib/powersave/bin/powersave false

[Install]
WantedBy=power-performance.target

Note: the sleep 10 in power-save.service is that in case of <10s ac loss, like 
happen often in trains or planes the powersave settings do not get applied.

And it works very well!

However for X display settings like 'xset +dpms', it would make more sense
to run this as part of the user session, which has access to DISPLAY and
XAUTHORITY. It is not too hard to find the active display as roots, but the
DISPLAY without the XAUTHORITY is not enough (unless the user adds a 'xhost
+si:localuser:$(id -un) somewhere'). So I could try to find which user is
using which X display and find their .Xauthority but it gets cumbersome.

Thanks,
Damien Robert

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] slow uefi firmware/boot

[Damien Robert]

I apologize for the out of topic question, but since systemd-analyze
incorporate the firmware boot time I wonder if you may have any trick to
share in order to improve it.

Here is my boot timing (using systemd-boot and a lz4 compressed initrd):

$ systemd-analyzed
Startup finished in 14.156s (firmware) + 1.098s (loader) + 7.473s (kernel)
+ 2.608s (initrd) + 1.766s (userspace) = 27.103s

I have a few questions on how to improve things:
- obviously for the firmware time there is not much to do except maybe try
  to turn off some uefi autodiscovery settings
- the loader is perfect, I have configured it with 1s delay for the menu
- I am surprised by the kernel time. What does it include?
- the initrd time is fast but I am surprised too that it is slower than
  userspace [but I guess it is because of the mounting of / which also
  mounts /home as a subvolume]. 
  The initrd is also handled by systemd, so the switch root is
  done by initrd-switch-root.service which calls
  /usr/bin/systemctl --no-block --force switch-root /sysroot
  I don't know how much information is transmitted during this switch,
  is there a 'systemd-analyze blame' I could do to see the time spent in
  the initrd (without using bootchart)?

Thanks!

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Secret machine-id for RFC 7217 stable addresses

[Damien Robert]

Tom Gundersen  wrote in message
:
> If I understand correctly, most of the point of RFC7217 is achieved
> even if the secret key is known. The important point is to have a good
> hashing function, and in that case knowing the secret key will not let
> you discover any of the other parameters (which are the ones you
> really want to hide).

Well if you know the secret key and the hash, you can do an exhaustive
search on the other parameters to recover them since they have low
entropy.

> Moreover, if the point is privacy, if an attacker has access (in some
> way) to the machine-id, there is no point in him going after the
> interface identifier as he can already identify the client.
> Given those two facts, might it not be sufficient to use the
> machine-id as the secret key after all?

It all depends on your model of security. You could imagine an attack where
an attacker known several machine-ids (for whatever reason, I can imagine
for instance a client downloading a vm preseeded with a machine-id). Then
when the client connects to the attacker, the attacker can try to hash all
his known machine-ids and the other low entropy parameters into the hash
function to get a match, in order to recover the machine-id and hence break
privacy.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd user service when x is started

[Damien Robert]

From arnaud gaboury, Fri 07 Nov 2014 at 21:00:14 (+0100) :
 I maybe was not explicit enough.
 I have a bunch of user services started as soon as I log in.
 then I $ startx
 
 After this command, I would like systemctl --user start some services
 (window manager, etc).

Yes, this is the same setup I use.

 The first bunch of services are grouped under
 the console.target. Now I am looking for a way to group GUI services
 in something like graphical.target (or whatever else name).

As I said, you just need to ensure that when you startx, your session
launch 'systemctl --user wm.target' automatically. I put this command in my
'.xprofile' (because the *DM usually source this file), and my .xinitrc
contains
[ -r $HOME/.xprofile ]  . $HOME/.xprofile
so it works with startx too.

-- 
Damien Robert
http://www.normalesup.org/~robert/pro
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd user service when x is started

[Damien Robert]

 My plan is to use after X is started a second target, let's call it
 wm.target, with all services relevant to the X session. For now, I
 have no idea how to define After=
 It can't be right after the console.target as X need to be started first.

I don't understand, if you start X manually, why don't you launch
systemctl --user wm.target from your .xprofile or an equivalent file?

Maybe use systemctl import-environment DISPLAY before to get the correct
$DISPLAY.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] segfault in timesyncd

[Damien Robert]

Here are the logs:

Nov 06 16:14:56 numenor systemd[1]: Started Network Time Synchronization.
Nov 06 16:14:56 numenor systemd-timesyncd[4881]: Using NTP server 
10.3.255.254:123 (10.3.255.254).
Nov 06 16:15:06 numenor systemd-timesyncd[4881]: Timed out waiting for reply 
from 10.3.255.254:123 (10.3.255.254).
Nov 06 16:15:06 numenor kernel: systemd-timesyn[4881]: segfault at 8 ip 
b77bea0a sp bfddf800 error 4 in systemd-timesyncd[b77b5000+1c000]
Nov 06 16:15:06 numenor systemd[1]: systemd-timesyncd.service: main process 
exited, code=killed, status=11/SEGV
Nov 06 16:15:06 numenor systemd[1]: Unit systemd-timesyncd.service entered 
failed state.
Nov 06 16:15:06 numenor systemd[1]: systemd-timesyncd.service has no holdoff 
time, scheduling restart.

I don't understand why I don't get a core dump, sending SIGABRT to a 'sleep'
does produce one:
Nov 06 16:09:39 numenor systemd-coredump[4321]: Process 4315 (sleep) of user 100
0 dumped core.
And my systemd/system.conf does not have a DefaultLimitCORE, and indeed
$ systemctl show systemd-timesyncd | grep LimitCORE
LimitCORE=18446744073709551615

-- 
Damien
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [Featur Request] Allow list of names in file.network

[Damien Robert]

From Tom Gundersen, Thu 23 Oct 2014 at 20:14:45 (+0200) :
 Yes, this absolutely makes sense. Maybe even en*|usb*, like the udev
 logic. Happy to take a patch, but put on TODO for now.

Great! I'll try to write a patch if I have the time!

Thanks,
Damien
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Damien Robert]

From Lennart Poettering, Fri 24 Oct 2014 at 01:09:56 (+0200) :
 So, I really would prefer if this logic wasn't just a hook, but
 actually the primary action of logging in graphically via a display
 manager.

Ok, and login off would just be something like 'systemctl stop gnome.target'?

 Note though that in the scheme I'd propose for GNOME we wouldn't
 support multiple parallel logins of the same user anymore. Instead, if
 you do this we'd add the seat you are logging into to your existing
 session.

I sometime login from the same seat multiple times (to test my X settings).
But I agree Xephyr would probably be better for this case.

 On multiseat setups you could hence merge multiple seats into
 a single meta-session with the workspace spanning all of the seats if
 you keep logging in with the same user.

I could imagine having several virtual machines that connects via ssh -X to
the main computer to launch graphical sessions (so that there is no need to
install it on the vms); in this case there would be a need to start the
same target but with different displays. And the solution I outlined on my
preceding mail using instances target templates work very well (and it does
since a long time, I was very impressed when I tried it and it worked out
of the box); but having 'hooks' on logind would help a bit.

But this is not really an important feature request for me, it was just an
idea in passing.

-- 
Damien Robert
http://www.normalesup.org/~robert/pro
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Shell expressions in EnvironmentFile

[Damien Robert]

From Lennart Poettering, Wed 08 Oct 2014 at 20:48:55 (+0200) :
 SyslogIdentifier= should do it.

It works, thanks!

 See systemd.exec(5) for details.

When I was looking for something like that in the doc, I was confused by
this passage: This option is only useful when StandardOutput= or
StandardError= are set to syslog or kmsg., but it apparently actually
works with StandardOutput=journal.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Damien Robert]

From Mantas Mikulėnas, Thu 23 Oct 2014 at 07:06:18 (+0300) :
 Wasn't this already fixed in polkit.git recently?

Yes indeed:

commit  a68f5dfd7662767b7b9822090b70bc5bd145c50c
sessionmonitor-systemd: prepare for D-Bus user bus model

In the D-Bus user bus model, all sessions of a user share the same D-Bus 
instance, a polkit requesting process might live outside the login session 
which registered the user's polkit agent. In case a polkit requesting process 
is not part of the user's login session, we ask systemd-logind for the the 
user's display session instead. 
https://bugs.freedesktop.org/show_bug.cgi?id=78905 

Wonderfull! The future is bright for user session :)

With PA's socket activation, since mpd already has socket activation,
the only thing I am still missing is ssh-agent socket activation!

-- 
Damien Robert
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Damien Robert]

Zbigniew Jędrzejewski-Szmek  wrote in message
20141019135812.gu29...@in.waw.pl:
  PAM creates sessions by calling into systemd's pam-module, which then
  uses CreateSession() (internal api!). This call does not return until
  the job of user@.service is done. `systemd --user` notifies READY=1
  only after default.target is ready.
 Hm, this seems a bit excessive, because default.target can take 
 a while. basic.target would seem more natural.

But isn't using default.target more flexible than basic.target? When
basic.target is activated I expect at least socket.target, timers.target
and path.target to get activated too; whereas I could imagine an user
wanting a completly empty user session [*], which could be done with an empty
default.target [#].

[*] I don't use cron anymore, so I don't know if a cron session goes
through systemd's pam module in my distribution's pam settings default, 
but I could imagine that if it were the case we would want a mostly empty
user session in this case.

[#] With DefaultDependencies=false

Right now by default default.target is a symlink to basic.target. It seems
natural that the user session starts default.target, like the system session
does. Otherwise what would be the meaning of default.target? Something
started by the DM when the user logs in rather than by pam?
(Actually now that user sessions are getting more used, it would indeed be
nice to standardize a name of a target to start when a graphical login is
used!)

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Damien Robert]

From Lennart Poettering, Thu 23 Oct 2014 at 11:49:27 (+0200) :
 On Thu, 23.10.14 08:09, Damien Robert (damien.olivier.robert+gm...@gmail.com) 
 wrote:
  But isn't using default.target more flexible than basic.target? When
  basic.target is activated I expect at least socket.target, timers.target
  and path.target to get activated too; whereas I could imagine an user
  wanting a completly empty user session [*], which could be done with an 
  empty
  default.target [#].

 basic.target includes sockets.target, busnames.target, timers.target
 and paths.target as well as sysinit.target.

No, that's the system wide basic.target. The user basic.target only has
sockets, timers and paths.

But I was arguing that basic.target has a well defined meaning (basic
system wide/user wide system initialisation), and we may want to allow
default.target (in a user session) to be different from basic.target, even
if they should be the same for most user cases.

 Yes, all user code really should go through PAM, so that security
 labels and resource limits can be set up properly.

Yeah but do they need to go through pam_systemd.so also?

 Regarding graphical stuff: the way I figured this should work is that
 all desktop environments would define their own gnome.target,
 kde.target, xfce.target and then some graphical.target symlink would
 point to the preferred version. These targets would then bring up
 averything that's necessary for the specific session type.

Ok, that looks nice.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Damien Robert]

From Lennart Poettering, Thu 23 Oct 2014 at 14:01:22 (+0200) :
 Oh indeed, there is not sysinit.target. It sounded so wron in a user
 context... I figure if people want to stick something in there they
 can just as well use basic.target here...
 
  But I was arguing that basic.target has a well defined meaning (basic
  system wide/user wide system initialisation), and we may want to allow
  default.target (in a user session) to be different from basic.target, even
  if they should be the same for most user cases.
 
 sure, that sounds like something to support. i'd still say though that
 pam_systemd should only wait for basic.target, since that's where all
 the listening bits should be established, and everything else can be
 started later.

Yes but maybe the user wants something even more minimal than basic.target.
For instance if I run under a cron, maybe I don't want my timers to be
launched. I was thinking of using a default.target with
DefaultDependencies=false, so it does not even pull basic.target; not
something that launch more things than basic.target.

-- 
Damien Robert
http://www.normalesup.org/~robert/pro
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Damien Robert]

From Zbigniew Jędrzejewski-Szmek, Thu 23 Oct 2014 at 17:26:57 (+0200) :
  order it after basic.target (which things are by default anyway)...
  My proposal now, (which is the same Damien's as I understood him):
  
  1. pam_systemd should sync on default.target
  2. by default default.target should just be an alias to basic.target.
  
  That way we have two things:
  
  a) as basic.target pulls in all sockets and busnames we know that
 everything that needs to be listened on is listened on by the time
 PAM succeeds
  
  b) if people really want they can change the default.target symlink to
 something else and thus add additional services into this, that may
 run after the sockets/busnames, but before PAM succeeds.

I was more thinking of having a default.target that is even smaller than
basic.target, but I forgot that we may want pam_systemd to start a session
different from the synced session before login, so this also conflates two
different use of default.target.

 Maybe this should be made explicit and PAM should wait for a new
 user-login.target, which by default will simply have Wants=basic.target,
 but the user is free to add additional dependencies if they want to
 have more stuff running before they are allowed to log in.

Yes, this would be ideal. This way
- pam_systemd starts default.target
- the login returns when user-login.target is reached.
[the question is what happen is default.target does not pull
user-login.target; and I would argue that the login should return
immediatly rather than wait for default.target]

The important thing for me is that I may want default.target to be even
smaller than basic.target; and I thought that syncing on basic.target would
necessarily means launching it at each session, but maybe the
implementation could be carefull about that. So in a scheme where
- pam_systemd starts default.target
- the login returns when basic.target is reached OR returns immediatly if
  basic.target is not pulled in
I would be equally happy.

The proposal by Zbigniew has my preference because it is more flexible,
and does not conflates these three different things:
- when to return for the login (user-login.target)
- what services we want to launch by default (default.target)
- when standard basic setup is considered done (basic.target)

And unlike the system case where I always want default.target to requires
basic.target, in the user case I may want default.target to be smaller than
basic.target (for cron jobs I don't want my timers to launch); but still
requires basic.target when I launch say xfce.target.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Damien Robert]

Colin Guthrie  wrote in message m1rf8b$ojg$1...@ger.gmane.org:
 I want to rely on systemd --user to handle PulseAudio's activation
 (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE
 might start up their own session stuff and spawn some PA consuming
 process before systemd --user has reached it's sockets.target and is
 thus ready and listening on PA's native socket.

Interesting, does PA now support socket activation? Mine (pulseaudio 5.0)
does not seem to support it.

 Doesn't seem to be a problem on my machine here (it's working really
 nicely actually!) but figured I should ask here too.

I have been using systemd user sessions for a long time, and it works really
well, except for this policykit bug:
https://bugs.freedesktop.org/show_bug.cgi?id=67728

For instance since I start dbus under the user session, the dbus activated
services also run inside it:
   CGroup: /user.slice/user-1000.slice/user@1000.service
   ├─615 /usr/lib/systemd/systemd --user
   ├─616 (sd-pam)  
   ├─dbus.service
   │ ├─  702 /usr/bin/dbus-daemon --session --address=systemd: --nofork 
   │ ├─  835 /usr/lib/gvfs/gvfs-udisks2-volume-monitor

So udisks2 fails to mount my usb keys because it is not under an active
session (since it is not launche from my active session) so it gets denied
by policykit.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Damien Robert]

Lennart Poettering  wrote in message 20141020173828.GA4509@gardel-login:
 They should probably adopt socket activation anyway, otherwise they'd
 be quite annoying on multi-user systems if lingering is used.

I am brainstorming here, but would it make sense to add hooks to logind
when a session is started/closed (both system hooks and user hooks)?

For instance when I log into X, my .xprofile contains
systemctl --no-block --user  start xsession@${DISPLAY}.target
to start my user services.

I need to make sure that everyway I have to log into X (with a *DM, with
startx, with xinit) I somehow source .xprofile.

Stopping the started services also involve some contorsion. When I quit X
most of the services started by xsession@$DISPLAY fails because X is no
longer available, and I don't want systemd to try to restart them in this
case. So I need to stop these services whenever X exits.

So inside xsession@.target, I launch xwatch@.service:

[Unit]
Description=Watch for X on display %I
BindsTo=xsession@.target

[Service]
Environment=DISPLAY=%I
SyslogIdentifier=xwatch@%I
ExecStart=/bin/sh -c 'exec %h/mine/script/services/xwatch %I'
Nice=19

[Install]
WantedBy=xsession@.target

with $ cat ~/script/services/xwatch
#!/bin/sh
xprop -spy -root XFree86_VT
systemctl --user stop xsession@$1.target

So whenever my X session stops, xwatch will stop xsession@$DISPLAY.target,
and thus stop all services files that I configured to be PartOf
xsession@.target. For instance xcompmgr@.service:

[Unit]
Description=xcompmgr on display %I 
PartOf=xsession@.target
ConditionFileIsExecutable=/usr/bin/xcompmgr

[Service]
Environment=DISPLAY=%I
ExecStart=/usr/bin/xcompmgr
Restart=on-failure
RestartSec=3
StandardOutput=null

[Install]
WantedBy=xsession@.target
Also=xwatch@.service

It works really well, I can even log onto different X sessions and have the
corresponding services launched into the different $DISPLAY, but having
some close hooks in logind would help getting rid of xwatch.service.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-journald watchdog timeout

[Damien Robert]

On one boot I got a watchdog timeout on systemd-journald:

Oct 21 20:08:21 feanor systemd-journal[213]: Permanent journal is using 68.7M (m
Oct 21 20:08:21 feanor systemd-journal[213]: Time spent on flushing to /var is 2
Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not rea
Oct 21 20:08:25 feanor kernel: wlan0: authenticate with f4:ca:e5:cc:c7:40
Oct 21 20:08:25 feanor kernel: wlan0: send auth to f4:ca:e5:cc:c7:40 (try 1/3)
Oct 21 20:08:25 feanor kernel: wlan0: authenticated
Oct 21 20:08:25 feanor kernel: wlan0: associate with f4:ca:e5:cc:c7:40 (try 1/3)
Oct 21 20:08:25 feanor kernel: wlan0: RX AssocResp from f4:ca:e5:cc:c7:40 (capab
Oct 21 20:08:25 feanor kernel: wlan0: associated
Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link become
Oct 21 20:08:20 feanor systemd[1]: Started Trigger Flushing of Journal to Persis
Oct 21 20:08:20 feanor systemd[1]: Started Create Volatile Files and Directories
Oct 21 20:08:20 feanor systemd[1]: Starting Network Time Synchronization...
Oct 21 20:08:20 feanor systemd[1]: Starting Update UTMP about System Boot/Shutdo
Oct 21 20:08:20 feanor systemd[1]: Started Update UTMP about System Boot/Shutdow
Oct 21 20:08:20 feanor systemd[1]: Started Network Time Synchronization.
Oct 21 20:08:20 feanor systemd[1]: Starting System Initialization.
Oct 21 20:08:21 feanor systemd[1]: Reached target System Initialization.
Oct 21 20:08:21 feanor systemd[1]: Starting sshd.socket.
Oct 21 20:08:21 feanor systemd[1]: Listening on sshd.socket.
Oct 21 20:08:21 feanor systemd[1]: Starting D-Bus System Message Bus Socket.
Oct 21 20:08:25 feanor systemd-logind[516]: New seat seat0.
Oct 21 20:08:25 feanor systemd-networkd[518]: lo  : gained carrier
Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu
Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu
Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu
Oct 21 20:08:25 feanor systemd[1]: Started Network Service.
Oct 21 20:08:25 feanor systemd[1]: Starting Network.
Oct 21 20:08:25 feanor systemd[1]: Reached target Network.
Oct 21 20:08:25 feanor systemd[1]: Starting Network Name Resolution...
Oct 21 20:11:20 feanor systemd-journal[574]: Permanent journal is using 75.1M (m
Oct 21 20:11:20 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X
Oct 21 20:11:20 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not read
Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service watchdog timeout (li
Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service...
Oct 21 20:11:20 feanor systemd[1]: Started Getty on tty2.
Oct 21 20:11:20 feanor systemd[1]: lightdm.service start operation timed out. Te
Oct 21 20:11:20 feanor systemd[1]: systemd-timesyncd.service watchdog timeout (l
Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service stop-sigterm timed o
Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service...
Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service: main process exited
Oct 21 20:11:20 feanor systemd[1]: Unit systemd-journald.service entered failed 
Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service has no holdoff time,
Oct 21 20:11:20 feanor systemd[1]: Stopping Journal Service...
Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service...
Oct 21 20:11:20 feanor systemd[1]: Started Journal Service.

As you can see at 20:08:20 things appears to look fine, but everything
get stuck during 3 minutes until there is a watchdog timeout for the
journal and it gets restarted. Then the boot finished without any further
problem. The next time everything worked fine, so I am wondering what could
have happened?

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-journald watchdog timeout

[Damien Robert]

From Lennart Poettering, Wed 22 Oct 2014 at 16:59:09 (+0200) :
 On Wed, 22.10.14 13:10, Damien Robert (damien.olivier.robert+gm...@gmail.com) 
 wrote:
 That's difficult to say just from these logs.

Yeah that was what I feared.

 Can you reliably reproduce this? If so, can you attach strace to journald 
 before this happens and see what it is doing?

Un(?)fortunately no.

 What I find interesting is that after the 3min pause suddenly the
 network driver allocates irq 55. This kinda makes me wonder if this
 might be a kernel/driver problem of some kind, where for some reason
 userspace (and hence journald) don't get scheduled?

I am not sure this is related, on a non troublesome boot I also have
similar lines:
Oct 22 09:12:39 feanor systemd[1]: Started Network Service.
Oct 22 09:12:39 feanor systemd[1]: Starting Network.
Oct 22 09:12:39 feanor systemd[1]: Reached target Network.
Oct 22 09:12:39 feanor systemd[1]: Starting Network Name Resolution...
Oct 22 09:12:39 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X
Oct 22 09:12:39 feanor systemd-resolved[526]: Using system hostname 'feanor'.
Oct 22 09:12:39 feanor systemd[1]: Started Network Name Resolution.
Oct 22 09:12:39 feanor systemd[1]: Starting Multi-User System.
Oct 22 09:12:39 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X
Oct 22 09:12:39 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not read
Oct 22 09:12:39 feanor kernel: wlan0: authenticate with f4:ca:e5:cc:c7:40

 What distro/version/arch is this?

Up to date archlinux, kernel 3.16.4-1-ARCH x86_64, systemd 216-3.

-- 
Damien Robert
http://www.normalesup.org/~robert/pro
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [feature request] allow instances in file.preset

[Damien Robert]

From Lennart Poettering, Wed 08 Oct 2014 at 23:33:13 (+0200) :
 On Fri, 03.10.14 19:18, Damien Robert (damien.olivier.rob...@gmail.com) wrote:
   But this means it
   would only find the template, and the instance would have to come from
   somewhere else, but where?
  From the preset file?
 No, we enumerate the installed unit files, and then look them up in
 the preset files. 

Yes, I meant you can't do the otherway around anyway (enumerate lines in
preset files and enable/disable them accordingly) because the preset
information is given by globs.
 
 I have the impression that the current scheme already does everything
 what you need, no?
 I mean, if you list the template unit file in the preset file, and we
 enumerate such a template unit file, we end up enabling it's
 DefaultInstance=, which should be enough for you? Or am I missing
 something?

For preset-all:
- I may want to enable an instance different from the default instance.
  For example wpa_supplicant@.service does not have a default instance.
  (I could change the file but in this case I might as well write directly
  a non template service file)
- I may want to enable different instances of the same template file.
- disable * does not disable instanciated templates (except the ones with a
  default instance).

But as you said, I do not see an easy way to do that the way preset-all
works.

Damien

-- 
Damien Robert
http://www.normalesup.org/~robert/pro
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [feature request] allow instances in file.preset

[Damien Robert]

From Lennart Poettering, Thu 09 Oct 2014 at 16:44:42 (+0200) :
 But this means it
 would only find the template, and the instance would have to come from
 somewhere else, but where?
From the preset file?
   No, we enumerate the installed unit files, and then look them up in
   the preset files. 
  Yes, I meant you can't do the otherway around anyway (enumerate lines in
  preset files and enable/disable them accordingly) because the preset
  information is given by globs.
 This feels wrong. The preset files are actually globs, not full file
 names. They are not really suitable as a list of filenames, but only
 as something to match file names against...

Yes, this is exactly what I was saying, sorry for the miscommunication...

-- 
Damien Robert
http://www.normalesup.org/~robert/pro
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Shell expressions in EnvironmentFile

[Damien Robert]

Lennart Poettering  wrote in message
20141008094838.GB26284@gardel-login:
 On Tue, 07.10.14 19:18, Simon Peeters (peeters.si...@gmail.com) wrote:
 ExecStart=/bin/sh -c . /something/that/sets/var; /some/file $var
 THis would certainly work, but I'd strongly advise to use exec for
 executing /some/file at the end, so that the shell process is replaced
 by the actual daemon process, instead of continuing running with the
 demon process as child.

I am hijacking the thread because one minor inconvenience I have with sh -c
'exec foo' is that in journalctl the logging refers to 'sh':
For instance:

[Unit]
Description=Git backup
ConditionPathIsDirectory=%h/backups/gitbackup

[Service]
Type=simple
ExecStart=/bin/sh -c 'exec %h/mine/script/gitbackup -v save'
Nice=19
IOSchedulingClass=best-effort
IOSchedulingPriority=7

gives me the log:

Oct 08 21:35:43 mithrim sh[9680]: [master 54c23ae]
Oct 08 21:35:43 mithrim sh[9680]: 2 files changed, 3 insertions(+), 3 
deletions(-)
 
Do you know of any way to get 'gitbackup' in the log rather than 'sh'?

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [feature request] allow instances in file.preset

[Damien Robert]

From Lennart Poettering, Thu 02 Oct 2014 at 17:42:36 (+0200) :
 Hence so far the idea was to look for the presets only in the dirs
 where we look for static data, but not for configuration. We can
 certainly revisit this though.

This makes sense for system services, but for user services it is a bit
strange that a user cannot modify its own preset files.

I'll be happy to provide a patch, but I must test the behavior of systemd
more carefully because user preset files in
   /etc/systemd/user-preset/*.preset
does not seem to work in systemd master [but maybe my testing was too
hasty, I'll keep you updated].

Thanks,
Damien Robert
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [feature request] allow instances in file.preset

[Damien Robert]

From Lennart Poettering, Thu 02 Oct 2014 at 17:32:07 (+0200) :
  Would it be possible for the .preset file to just specify foo@.service
  and then the code that actually enables it just process the
  DefaultInstance rule as normal?
 
 That should already work, no?

Yes it works:
in 90-systemd.preset, the line
  enable getty@.service
correctly enables
getty@tty1.service

-- 
Damien Robert
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [feature request] allow instances in file.preset

[Damien Robert]

From Lennart Poettering, Thu 02 Oct 2014 at 16:48:19 (+0200) :
 Well, but from somewhere systemctl preset-all needs to be able to
 discover the bar string... How is that supposed to work?
 
 preset-all just enumerates all unit files that are installed and
 enables/disables them according to the preset file. But this means it
 would only find the template, and the instance would have to come from
 somewhere else, but where?

From the preset file? I agree that since the enable/disable directive
denotes glob, they are not well suited for instances services. Maybe add a
new directive:
instanciate foo@bar.service
uninstanciate foo@bar.service
(the uninstanciate is because disable does not disable instancied service
for the same reason enable doe not enable them).

I do not feel too strongly on this feature, afterwards it might as well be
easier to call systemctl enable directly...

Thanks,
Damien Robert
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [feature request] allow instances in file.preset

[Damien Robert]

From Damien Robert, Fri 03 Oct 2014 at 19:18:31 (+0200) :
 From the preset file? I agree that since the enable/disable directive
 denotes glob, they are not well suited for instances services. Maybe add a
 new directive:
 instanciate foo@bar.service
 uninstanciate foo@bar.service
 (the uninstanciate is because disable does not disable instancied service
 for the same reason enable doe not enable them).

Or activate/desactivate.

But whatever the name, there is going to be some ugly interactions with
enable/disable. (We would want desactivate to match globs too in order to
be able to desactivate older instances, but then how do we check which has
precedence between enable/disable/activate/desactivate).

Maybe it is instead way easier to just directly call systemctl enable.
Still, one feature missing is the ability to desactivate all services files
(systemctl preset-all leaves the instances alone even with a disable *) in
order to go back to a 'pristine' state from which one can call systemctl
preset-all and then enable the instances.

-- 
Damien Robert
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [feature request] allow instances in file.preset

[Damien Robert]

From Lennart Poettering, Thu 02 Oct 2014 at 16:07:03 (+0200) :
 How precisely would you envision this to work? I mean, so far
 systemctl preset foo@bar.service will precisely enable
 foo@bar.service

That's exactly what I want; I have not tried systemctl preset
foo@bar.service, but in 'systemctl preset-all' it does not work (it only
enables services that exist, not instanciated service).

 , but you are expecting that systemctl preset
 foo@.service would somehow result in enablement of foo@bar.service or
 so? How would we even denote that in the rules files?

No, I just want that
  enable foo@bar.service
in a preset rule works with systemctl preset-all. Maybe I missed something
and it already works?

Thanks,
Damien Robert
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [Featur Request] Allow list of names in file.network

[Damien Robert]

This is a minor feature request for systemd-networkd:
my files in /etc/systemd/network/ all share the same pattern:

[Match]
Name=en*
[Network]
DHCP=yes

[Match]
Name=eth*
[Network]
DHCP=yes

[Match]
Name=usb*
[Network]
DHCP=yes

I would like to be able to only write one file, like

[Match]
Name=en*,eth*,usb*
[Network]
DHCP=yes

or maybe to imitate extended globs like so

[Match]
Name={en,eth,usb}*
[Network]
DHCP=yes

This would greatly facilitate adding common options like custom DNS and so
on.

Thanks!

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [feature request] allow instances in file.preset

[Damien Robert]

I really like the new preset directive, and I plan to use preset files
to synchronise the services I launch at boot across my computers.

However it is a bit cumbersome that preset files do not parse instanced
services files. I could play with DefaultInstance in foobar@.service.d/
droplets and add foobar@.service in the preset file (this works); but this
only allow to configure one instance.

Thanks!

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [feature request] allow instances in file.preset

[Damien Robert]

Damien Robert  wrote in message m01rcj$dhh$2...@ger.gmane.org:
 I really like the new preset directive, and I plan to use preset files
 to synchronise the services I launch at boot across my computers.

Also according to the man file systemd.preset and my test,
while user systemd units are looked in user folders:
   $XDG_CONFIG_HOME/systemd/user/*
   $HOME/.config/systemd/user/*
   ...
preset files are only looked in system folders:
   /etc/systemd/user-preset/*.preset
   ...
Is there a reason for that?

Thanks,
Damien Robert

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [feature request] allow instances in file.preset

[Damien Robert]

Zbigniew Jędrzejewski-Szmek  wrote in message
20140925211702.gv29...@in.waw.pl:
 This seems to be a mis-design. I'm pretty sure we should allow users
 to set their own presets, so those directories underneath the home
 dir should be added.

Ok great! I'll be happy to provide a patch but I have never hacked systemd
before. Would something like that be ok? (not tested, just to see if I am
in the right direction)

Thanks,
Damien Robert

-- 8 -
From 7755e4afc3dc24f50c97c28fd7c00fd576d882cc Mon Sep 17 00:00:00 2001
From: Damien Robert damien.olivier.robert+...@gmail.com
Date: Fri, 26 Sep 2014 00:34:46 +0200
Subject: [PATCH 1/1] preset: read files in 
$XDG_CONFIG_HOME/systemd/user-preset/*

This is the only way for a user to modify preset files as the other
directory read
   /run/systemd/user-preset/*.preset
   /usr/lib/systemd/user-preset/*.preset
are not user owned.

---
 man/systemd.preset.xml |  1 +
 src/shared/install.c   | 24 ++--
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml
index 55cb4de..9d414f4 100644
--- a/man/systemd.preset.xml
+++ b/man/systemd.preset.xml
@@ -49,6 +49,7 @@
 
parafilename/etc/systemd/system-preset/*.preset/filename/para
 
parafilename/run/systemd/system-preset/*.preset/filename/para
 
parafilename/usr/lib/systemd/system-preset/*.preset/filename/para
+
paraliterallayoutfilename$XDG_CONFIG_HOME/systemd/user-preset/*/filename
 
parafilename/etc/systemd/user-preset/*.preset/filename/para
 
parafilename/run/systemd/user-preset/*.preset/filename/para
 
parafilename/usr/lib/systemd/user-preset/*.preset/filename/para
diff --git a/src/shared/install.c b/src/shared/install.c
index 61e572b..7981556 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1769,6 +1769,7 @@ UnitFileState unit_file_get_state(
 
 int unit_file_query_preset(UnitFileScope scope, const char *root_dir, const 
char *name) {
 _cleanup_strv_free_ char **files = NULL;
+_cleanup_free_ char *user_preset = NULL;
 char **p;
 int r;
 
@@ -1786,12 +1787,23 @@ int unit_file_query_preset(UnitFileScope scope, const 
char *root_dir, const char
 #endif
 NULL);
 else if (scope == UNIT_FILE_GLOBAL)
-r = conf_files_list(files, .preset, root_dir,
-/etc/systemd/user-preset,
-/usr/local/lib/systemd/user-preset,
-/usr/lib/systemd/user-preset,
-NULL);
-else
+if (user_config_home(user_preset) = 0) {
+user_preset = strappend(user_preset, -preset);
+if (!user_preset)
+return -ENOMEM;
+r = conf_files_list(files, .preset, root_dir,
+user_preset,
+/etc/systemd/user-preset,
+
/usr/local/lib/systemd/user-preset,
+/usr/lib/systemd/user-preset,
+NULL);
+}
+else
+r = conf_files_list(files, .preset, root_dir,
+/etc/systemd/user-preset,
+
/usr/local/lib/systemd/user-preset,
+/usr/lib/systemd/user-preset,
+NULL);
 return 1;
 
 if (r  0)
-- 
Patched on top of v216-385-g79d80fc (git version 2.1.0)


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [feature request] allow instances in file.preset

[Damien Robert]

[Resending to the list since I was not posting through gmane but through
gmail this time and my post was rejected because I was not subscribed to
the list. Sorry for the spam]

From Zbigniew Jędrzejewski-Szmek, Fri 26 Sep 2014 at 01:00:11 (+0200) :
  +
  paraliterallayoutfilename$XDG_CONFIG_HOME/systemd/user-preset/*/filename
 You seem to open an xml element, without closing it.

Oups! A hasty copy and paste from systemd.unit

  +_cleanup_free_ char *user_preset = NULL;
 You can define this below, where it is used.

According to CODING_STYLE it is better to declare all variables at the top
of the function.

  -else
  +if (user_config_home(user_preset) = 0) {
  +user_preset = strappend(user_preset, -preset);
  +if (!user_preset)
  +return -ENOMEM;
  +r = conf_files_list(files, .preset, root_dir,
  +user_preset,
  +/etc/systemd/user-preset,
  +
  /usr/local/lib/systemd/user-preset,
  +/usr/lib/systemd/user-preset,
  +NULL);
  +}
  +else
  +r = conf_files_list(files, .preset, root_dir,
  +/etc/systemd/user-preset,
  +
  /usr/local/lib/systemd/user-preset,
  +/usr/lib/systemd/user-preset,
  +NULL);
 Please align all the if's at the same level, not nested.

In fact they are part of the outer 'else if () {' and i was missing some
brackets. Here is an updated patch, but I really need to test it inside a
container first; I'll send you a real version asap.

Thanks for your comments!

-- 8 ---
From: Damien Robert damien.olivier.robert+...@gmail.com
Date: Fri, 26 Sep 2014 00:34:46 +0200
Subject: [PATCH 1/1] preset: read files in 
$XDG_CONFIG_HOME/systemd/user-preset/*

This is the only way for a user to modify preset files as the other
directory read
   /run/systemd/user-preset/*.preset
   /usr/lib/systemd/user-preset/*.preset
are not user owned.

Signed-off-by: Damien Robert damien.olivier.robert+...@gmail.com
---
 man/systemd.preset.xml |  1 +
 src/shared/install.c   | 26 --
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml
index 55cb4de..3a45cbd 100644
--- a/man/systemd.preset.xml
+++ b/man/systemd.preset.xml
@@ -49,6 +49,7 @@
 
parafilename/etc/systemd/system-preset/*.preset/filename/para
 
parafilename/run/systemd/system-preset/*.preset/filename/para
 
parafilename/usr/lib/systemd/system-preset/*.preset/filename/para
+
paraliterallayoutfilename$XDG_CONFIG_HOME/systemd/user-preset/*/filename/literallayout/para
 
parafilename/etc/systemd/user-preset/*.preset/filename/para
 
parafilename/run/systemd/user-preset/*.preset/filename/para
 
parafilename/usr/lib/systemd/user-preset/*.preset/filename/para
diff --git a/src/shared/install.c b/src/shared/install.c
index 61e572b..b666b96 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1769,6 +1769,7 @@ UnitFileState unit_file_get_state(
 
 int unit_file_query_preset(UnitFileScope scope, const char *root_dir, const 
char *name) {
 _cleanup_strv_free_ char **files = NULL;
+_cleanup_free_ char *user_preset = NULL;
 char **p;
 int r;
 
@@ -1785,12 +1786,25 @@ int unit_file_query_preset(UnitFileScope scope, const 
char *root_dir, const char
 /lib/systemd/system-preset,
 #endif
 NULL);
-else if (scope == UNIT_FILE_GLOBAL)
-r = conf_files_list(files, .preset, root_dir,
-/etc/systemd/user-preset,
-/usr/local/lib/systemd/user-preset,
-/usr/lib/systemd/user-preset,
-NULL);
+else if (scope == UNIT_FILE_GLOBAL) {
+if (user_config_home(user_preset) = 0) {
+user_preset = strappend(user_preset, -preset);
+if (!user_preset)
+return -ENOMEM;
+r = conf_files_list(files, .preset, root_dir,
+user_preset,
+/etc/systemd/user-preset,
+
/usr/local/lib/systemd/user-preset,
+/usr/lib/systemd/user

Re: [systemd-devel] cannot start swap unit on lvm

[Damien Robert]

Alexey Shabalin  wrote in message
CAEdvWkQTe1rZ=+artom3hfr6rc8qgvbf2mgqfx44k+erjhp...@mail.gmail.com:
 [Swap]
 What=/dev/disk/by-uuid/a8ce6981-1afd-4af6-8783-784b3c7a7d64
 systemctl start
 dev-disk-by\x2duuid-a8ce6981\x2d1afd\x2d4af6\x2d8783\x2d784b3c7a7d64.swap
 cannot activate swap, error by timeout.
 but swapon /dev/disk/by-uuid/a8ce6981-1afd-4af6-8783-784b3c7a7d64 fork fine.

This looks a lot like the bug I had here
https://bugs.archlinux.org/task/31306

I talk about a timeout for mounting /home, but mounting swap also
timeouted.

As you can see on the bug report, I have a similar setup to yours: swap on
lvm, and referencing to it by the uuid. A possible explanation given by the
arch maintainer was that the /dev/by-uuid links were not made, explaining
why systemd could not find the filesystem. The swapon and mount works
because they don't rely on these symlinks whereas systemd work. So if this
is the case it would be more a udev problem than a systemd one.

This happened with kernel 3.4.9, upgrading to 3.5.3 solved it (and
strangely going back to 3.4.9 did not give back the problems, so I could
not investigate further and the conditions for the bug to produce look to 
be quite unstable).

 Sorry, i know that swap on lvm bad idea, but ...

I use lvm for my /, /boot, /home and swap partition and I really regret it.
- Since grub2 went from 1.99 to 2.00, the lvm code changed, and the
corresponding core.img does not longer fit in my 31.5kiB MBR gap.
- I got the bug you mentioned
- Currently with kernel 3.5.3 using ArchLinux the lvm detection fails in
  the initrd (the dm_mod module takes longer to load, so there is a race
  such that lvm vgchange --sysinit -a y sometime do not find the lvm
  partitions): 
  https://bugs.archlinux.org/task/30966?string=lvm
- it slows down the boot
  http://freedesktop.org/wiki/Software/systemd/Optimizations
Next time I reinstall my computers I'll go with btrfs subvolumes instead!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemctl --user

[Damien Robert]

 in condition not absolute, ignoring: %h/.conkyrc
while something like
  ExecStart=/bin/echo %h
will work correctly and display my $HOME.
This is really annoying with user service files, because I have to specify
the home path manually, like in
  ExecStart=/home/username/script/services/xwatch %I
rather than
  ExecStart=%h/script/services/xwatch %I
and I don't always have the same $HOME (especially when I am not root...)

2) To work around the first problem, the services in ~/.config/systemd/user
are symlinks pointing to a service file with the right hardcoded HOME.
While systemctl start work fine with symlinks, systemctl enable does not:
   Failed to issue method call: No such file or directory
(this is not too annoying since I can always make the symlinks myself)

And the feature requests:
1) it would be nice to have a way to launch something when the service
   exit. (This is different from ExecStop is that it would be launched even
   if the service is not stopped by systemd). Maybe something like
   OnExitExec=
(one could even imagine adding things like OnExitSuccessExec=, 
OnExitFailureExec=, OnExitAbortExec=)

This would allow to write a pure systemd xwatch.service:

  [Unit]
  Description=Watch for X on display %I
  BindsTo=xsession@.target
  
  [Service]
  Environment=DISPLAY=%I
  ExecStart=/usr/bin/xprop -spy -root XFree86_VT
  OnExitExec=/usr/bin/systemctl --user stop xsession@%I.target
  
  [Install]
  WantedBy=xsession@.target

2) somewhat related: having a way to configure StartLimitAction= other than 
rebooting, which is not really usefull for user services.
(this would allow to simulate OnExitExec= by putting it on
StartLimitAction= and setting StartLimitBurst=1 and Restart=always, but it
is probably not a good idea).

-- 
Damien Robert
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [Feature Request] systemctl --user status to output journal logs

[Damien Robert]

Hi all,

when using systemctl status foo.service, the last journald entries
correspondingto this service are printed, which is a very nice feature of
systemd.

However, this is not the case when running a systemd --user, then systemctl
--user foo.service will not print the corresponding journal logs, even if
there are some. So here is to a feature request :)


While I am at it, I have a question about how to distinguish in the
user-mypid.journal what come from services started by the service systemd
and what come from services started by systemd --user. A look at journalctl
_AUDIT_LOGINUID=myid -o verbose show that the messages corresponding to
services started by systemd --user could be identified by their
_SYSTEMD_CGROUP of the form
_SYSTEMD_CGROUP=/user/myname/8/systemd-30697/foo.service
   ^
so something like journalctl _SYSTEMD_CGROUP='the right regular expression'
could print them, but journalctl does not seem to support regular
expression yet.

To tell the truth I was expecting to identify these messages by using
_SYSTEMD_OWNER_UID=myid, but it seem that systemd --user does not set this
property: I have some message with _SYSTEMD_OWNER_UID=myid in my logs but
they do not correspond to messages generated by the services from systemd
--user, so I don't really know what _SYSTEMD_OWNER_UID means :)

Cheers!

Damien Robert
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel