Sorry I meant upower rather than udevd in my message.
Reindl Harald wrote in message
<10fb87e3-7aeb-7917-512a-2d750961b...@thelounge.net>:
> the point is that daemon is desigend to care about that and nothing else
> and you just need the right hooks - what is the point to fireup a system
> servic
imilar 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
__
s 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
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 (firm
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
'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 work
> 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, wh
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
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 wa
>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
__
>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
Standa
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.targ
nimal 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 thi
>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 exp
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 RE
er'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 Robe
>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, c
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 r
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
Colin Guthrie wrote in message :
> 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 soc
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
>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 els
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
> executi
>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@
ier 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
k, 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
ing 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
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
system
ot;/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 th
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
Fr
Damien Robert wrote in message :
> 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 f
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
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
Alexey Shabalin wrote in message
:
> [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-878
[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=
me 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 lis
36 matches
Mail list logo
