On Wed, Apr 3, 2013 at 1:28 PM, Tom Gundersen wrote:
> On Wed, Apr 3, 2013 at 9:43 PM, Kok, Auke-jan H
> wrote:
>> On Wed, Apr 3, 2013 at 12:30 PM, Matthew Monaco wrote:
>>> Here are my user session units. I have a few dbus activated examples
>>>
>>> https://github.com/mmonaco/systemd-user-sessi
On Tue, Apr 02, 2013 at 10:42:46AM -0700, Kok, Auke-jan H wrote:
> On Tue, Apr 2, 2013 at 6:29 AM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Tue, Apr 02, 2013 at 08:26:17AM +0200, Tomasz Torcz wrote:
> >> On Tue, Apr 02, 2013 at 05:54:32AM +0200, Zbigniew Jędrzejewski-Szmek
> >> wrote:
> >> > O
On Wed, Apr 03, 2013 at 02:00:20PM -0700, Lennart Poettering wrote:
> -* systemctl status: show drop-in snippets for service files in addition to
> service file path themesevles.
Unfortunately this part is not done yet. Only the dbus API is done.
Zbyszek
_
On Wed, Apr 3, 2013 at 9:43 PM, Kok, Auke-jan H
wrote:
> On Wed, Apr 3, 2013 at 12:30 PM, Matthew Monaco wrote:
>> Here are my user session units. I have a few dbus activated examples
>>
>> https://github.com/mmonaco/systemd-user-session
>>
>> I have one target for an i3 session and another for a
> Would you be willing to contribute some of these (the dbus activation
> units for instance) back to user-session-units? There are quite a few
> folks using work based on user-session-units (a few distro's package
> it) and getting these in a central repository would help a lot of
> folks.
I have
On Wed, Apr 3, 2013 at 12:30 PM, Matthew Monaco wrote:
> Here are my user session units. I have a few dbus activated examples
>
> https://github.com/mmonaco/systemd-user-session
>
> I have one target for an i3 session and another for an openbox/cairo-dock
> session. I can freely switch between the
On 04/03/2013 08:22 AM, Will Stephenson wrote:
> I'm joining the flock of desktop people investigating using systemd to start a
> desktop session. So far I've checked out user-session-units and have created
> some more granular unit files that will do a native systemd start rather than
> u-s-u's w
Sadly it makes the journal totally useless for me.
I gather its fixed but I'm just wondering if there is any way to fix
it in place,
or if I need to try to build the latest version and if so I'd like to
get a general
idea if that's going to be practical or if the whole OS will need rewired along
w
On Wed, 03.04.13 17:02, Harald Hoyer ([email protected]) wrote:
> > Well, this explanation is too short. You need to clarify that this only
> > has an effect on devices listed in fstab with their device mapper path
> > (i.e. rather than LABEL= or UUID=, which is by far more common). For the
> > ge
On Wed, Apr 3, 2013 at 6:22 AM, Will Stephenson wrote:
>
> I'm joining the flock of desktop people investigating using systemd to start
> a desktop session. So far I've checked out user-session-units and have
> created some more granular unit files that will do a native systemd start
> rather
On Wed, Apr 3, 2013 at 3:22 PM, Will Stephenson wrote:
> I'm joining the flock of desktop people investigating using systemd to start
> a desktop session. So far I've checked out user-session-units and have
> created some more granular unit files that will do a native systemd start
> rather than
From: Harald Hoyer
The password query for a crypto device currently times out after 90s,
which is too short to grab a cup of coffee when a machine boots up.
The resulting decrypted device /dev/mapper/luks- might not
be a mountpoint (but part of a LVM PV or raid array)
and therefore the timeout c
Am 03.04.2013 16:52, schrieb Lennart Poettering:
> On Wed, 03.04.13 15:34, [email protected] ([email protected]) wrote:
>
>> From: Harald Hoyer
>>
>> put JobTimeoutSec=0 in .d/JobTimeoutSec0.conf files
>>
>> This helps with grabbing a cup of coffee while booting and not have the
>> crypto passwor
On Wed, 03.04.13 15:34, [email protected] ([email protected]) wrote:
> From: Harald Hoyer
>
> put JobTimeoutSec=0 in .d/JobTimeoutSec0.conf files
>
> This helps with grabbing a cup of coffee while booting and not have the
> crypto password dialog timeout and systemd in a failed state.
>
> This
I would really appreciate some help with this from someone who's familiar with
the systemd internals.
What mechanism to prevent cg_trim from removing a cgroup before the newly
created child has completed cg_set_task_access?
I've created bug 63080 for this as well.
/Anders
> -Original Mess
On Wed, Apr 03, 2013 at 02:59:18PM +0200, Lennart Poettering wrote:
> On Wed, 03.04.13 08:27, Holger Freyther ([email protected]) wrote:
>
> > +#define PROCFS_PATH_LEN (sizeof("/proc/")-1 + DECIMAL_STR_MAX(unsigned
> > long))
>
> Even though we use %lu to actually print the PID it's stil in the
From: Harald Hoyer
put JobTimeoutSec=0 in .d/JobTimeoutSec0.conf files
This helps with grabbing a cup of coffee while booting and not have the
crypto password dialog timeout and systemd in a failed state.
This is even needed for "timeout=0" in /etc/crypttab!
---
src/cryptsetup/cryptsetup-gener
I'm joining the flock of desktop people investigating using systemd to
start a desktop session. So far I've checked out user-session-units and
have created some more granular unit files that will do a native systemd
start rather than u-s-u's wrapper around the upstream start script.
I'm stuck
On Wed, 03.04.13 08:27, Holger Freyther ([email protected]) wrote:
> +#define PROCFS_PATH_LEN (sizeof("/proc/")-1 + DECIMAL_STR_MAX(unsigned long))
Even though we use %lu to actually print the PID it's stil in the PID
range, so I'd prefer using DECIMAL_STR_MAX(pid_t) here...
> +#define format_p
19 matches
Mail list logo
