[systemd-devel] systemd-networkd and After=network.target

[Ivan Shapovalov]

Hello all,

I've noticed that systemd-networkd.service (ordered Before=network.target) 
finishes its startup before the connection is established/failed. Because of 
this, some networking daemons ordered After=network.target (like openvpn) are 
prone to failures when they attempt to connect at startup.

Is this intended, or is this a bug, or have I overlooked some piece of 
configuration?

Thanks,
--
Ivan Shapovalov / intelfx /

(Sent from my phone. Havoc may be wreaked on the formatting.)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd and After=network.target

[Ivan Shapovalov]

On Wednesday 02 April 2014 at 12:00:07, Umut Tezduyar Lindskog wrote:   
 Hi Ivan,
 
 On Wed, Apr 2, 2014 at 11:41 AM, Ivan Shapovalov intelfx...@gmail.com 
wrote:
  Hello all,
  
  I've noticed that systemd-networkd.service (ordered Before=network.target)
  finishes its startup before the connection is established/failed. Because
  of this, some networking daemons ordered After=network.target (like
  openvpn) are prone to failures when they attempt to connect at startup.
 Please take a look at
 http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/. It is
 explained there what network.target actually does.
 What you are expecting is a phase where interfaces up and configured.
 There has been some work coming up for this,
 020d59000f86b3d98be763eaee6a2671f0427e46.
 
 Thanks,
 Umut

Thanks for the link, got it. I think that for my usecase (a single interface) 
it is in fact usable, so I'll craft a wait-online unit using NM's one as a 
reference. Are there any pitfalls?

-- 
Ivan Shapovalov / intelfx /

 
  Is this intended, or is this a bug, or have I overlooked some piece of
  configuration?
  
  Thanks,
  --
  Ivan Shapovalov / intelfx /
  
  (Sent from my phone. Havoc may be wreaked on the formatting.)

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?

[Ivan Shapovalov]

On Monday 09 June 2014 at 23:32:28, Mike Gilbert wrote: 
 On Mon, Jun 9, 2014 at 4:42 PM, Reindl Harald h.rei...@thelounge.net wrote:
 
  Am 09.06.2014 22:32, schrieb Leonid Isaev:
  On Mon, Jun 09, 2014 at 09:19:20PM +0200, Reindl Harald wrote:
  [...]
 
  on our production infrastrcuture these messages would be
  *a lot* more than all other logs summarized
 
  *and* they are spitted to /var/log/messages to make things worst
 
  But why can't you write a syslog filter which uses facility as well as 
  program
  name? So if you believe that systemd-generated messages are useless, 
  drop them
 
  because you *can not* distinguish between *that* user messages
  and system message sbecause they have systemd as program name
  common, the PID changes and you don't want to drop *system
  messages* from systemd
 
  So, systemd starts certain things on _any_ user login: be it a real 
  user, or
  a daemon. However
 
  * why do it need to do that much stuff
  * why can't it keep that stuff long-running
 
  you have already /usr/lib/systemd/systemd --user and (sd-pam)
  processes for every userid ever started a cronjob running all
  the time - so why flood the logs every minute again?
 
 
 Now that you mention it, you can cut down on a lot of the log spam by
 enabling linger for root and other users which run cron jobs.
 
 loginctl enable-linger user
 
 This will keep a systemd user instance running so that a new one is
 not spawned every time cron wakes up.

It's more interesting, why a logind session is ever being created for the cron 
job...
It shouldn't be that way, or do I misunderstand something?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Locking current session programmatically

[Ivan Shapovalov]

I want to lock my current session using a command-line tool (or a D-Bus call).

The only apparent way to do this is `loginctl lock-session $XDG_SESSION_ID`.
However, this results in an Access denied reply, which is somewhat strange
(I expect to be able to lock my own session).

Is this by design or a bug? In either case, is it possible to lock the current
session?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Locking current session programmatically

[Ivan Shapovalov]

 27 июня 2014 г., в 21:54, Lennart Poettering lenn...@poettering.net 
 написал(а):
 
 On Fri, 27.06.14 17:45, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
 I want to lock my current session using a command-line tool (or a D-Bus 
 call).
 
 The only apparent way to do this is `loginctl lock-session $XDG_SESSION_ID`.
 However, this results in an Access denied reply, which is somewhat strange
 (I expect to be able to lock my own session).
 
 Is this by design or a bug?
 
 Neither. Just missing functionality. I added this to the TODO list now. 
 
 In either case, is it possible to lock the current
 session?
 
 Well, not with logind, no. But you should be able to do it with GNOME's APIs.
 
 Lennart
 
 -- 
 Lennart Poettering, Red Hat

I've got a DE-less setup (a freestanding window manager). Should I just invoke 
whatever tool I use for screenlocking (i3lock in my case)?

--
Ivan Shapovalov / intelfx /

(Sent from a phone. Havoc may be wreaked on the formatting.)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] serializing execution of units

[Ivan Shapovalov]

Consider the following situation.
We have foo.target and foo@.service. All instances of foo@.service are
WantedBy=foo.target (and implicitly After=foo.target). So, when foo.target
is activated, all instances of foo@.service are started in parallel.

The question is -- how to run them sequentially?

Thanks,
-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] serializing execution of units

[Ivan Shapovalov]

On Wednesday 02 July 2014 at 18:04:36, Mantas Mikulėnas wrote:  
 On Wed, Jul 2, 2014 at 4:05 PM, Ivan Shapovalov intelfx...@gmail.com wrote:
  Consider the following situation.
  We have foo.target and foo@.service. All instances of foo@.service are
  WantedBy=foo.target (and implicitly After=foo.target). So, when foo.target
  is activated, all instances of foo@.service are started in parallel.
 
  The question is -- how to run them sequentially?
 
 You can't do this with systemd features (and I'm curious why this
 would be needed in the first place). But the program itself, or a
 wrapper script, could use flock() or the `flock` tool on a shared
 lockfile to serialize startup.

That's a good idea. I'll use wrapper+flock, thanks.

/*
The templated unit invokes `bup index` on a given path (bup is a tool for
doing incremental backups). Running multiple instances of `bup index` is
bogus, as they will end up overwriting the index file.
*/

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?

[Ivan Shapovalov]

On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote: 
 Hi,
 
   I have a read-only / filesystem and /etc/mtab points to
 /proc/self/mounts as it should.
   So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab
 because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - -
 ../proc/self/mounts. 
   Is this intentional? Besides failing on ro /, it is also confusing
 because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem'
 package), so why tmpfiles instead of including this symlink with systemd?
   The same question applies to the entire etc.conf: why does tmpfiles
 touch /etc at all, especially if /etc is already properly set up?
 
 Thanks,
 

L+ (as well as any other + directives) only force-overwrite files if this is
needed, e. g. if a symlink points to the wrong desination.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?

[Ivan Shapovalov]

On Sunday 06 July 2014 at 13:13:55, Mike Gilbert wrote: 
 On Sun, Jul 6, 2014 at 1:08 PM, Ivan Shapovalov intelfx...@gmail.com wrote:
  On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote:
  Hi,
 
I have a read-only / filesystem and /etc/mtab points to
  /proc/self/mounts as it should.
So, in systemd-215 tmpfile.d fails to create a symbolic link 
  /etc/mtab
  because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - 
  - -
  ../proc/self/mounts.
Is this intentional? Besides failing on ro /, it is also confusing
  because /etc/mtab can be supplied by a package (in archlinux, the 
  'filesystem'
  package), so why tmpfiles instead of including this symlink with systemd?
The same question applies to the entire etc.conf: why does tmpfiles
  touch /etc at all, especially if /etc is already properly set up?
 
  Thanks,
 
 
  L+ (as well as any other + directives) only force-overwrite files if this 
  is
  needed, e. g. if a symlink points to the wrong desination.
 
 
 Right.
 
 I think the path matching is a little naive; Using a simple string
 comparison, /proc/self/mounts != ../proc/self/mounts even though
 both paths refer to the same object.

No, they aren't referring to the same object. This makes a difference
when you mount a foreign system image for maintainance.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Implementing resume from hibernation as a systemd unit file

[Ivan Shapovalov]

Hello all,

I'm trying to implement resuming from hibernation with systemd-based initramfs,
i. e. in terms of systemd unit files. That is, there should be a unit which
waits for the resume device and writes its major:minor into /sys/power/resume.

I've chosen to write a templated resume@path.service and a generator which
parses 'resume=' kernel parameter and enables a corresponding instance of the
resume@.service unit.

The resume@.service itself shall be ordered so that it is activated when there
are no filesystems mounted read-write, except tmpfs instances. It will be good
if it works both from initramfs and from real rootfs (if it is mounted RO).

So, here are some questions:
- is it the way to go (overall)?
- is it OK to use generators for outlined purpose?
- how to order resume@.service and where to symlink it?

I'm using Arch, if that matters -- but, IIUC, Arch strives to do everything
in the upstream's way, so there should be no distro-specific details.

Thanks,
-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Pairing udev's SYSTEMD_WANTS and systemd's templated units

[Ivan Shapovalov]

Hello all,

I'm trying to start from an udev rule a templated systemd unit, whose instance
should be a properly escaped device node path (so that %i.device would represent
an existing unit). Which udev specifier should I use for this?

Or, in more clear wording:

given the rule:

ACTION==add, ..., TAG+=systemd, 
ENV{SYSTEMD_WANTS}+=foo@$some_specifier.service

and the unit foo@.service:

[Unit]
After=%i.device
BindsTo=%i.device
...

Which $some_specifier should I use in the udev rule to get %i.device in
my service file to refer to the valid and corresponding device unit?

The closest match I've got is sys%p, but it does not work because dashes are 
not
escaped, and I get
sys-devices-pci:00-:00:1d.0-usb4-4-1-4-1.2.device
instead of
sys-devices-pci:00-:00:1d.0-usb4-4\x2d1-4\x2d1.2.device
and so on.

Thanks,
-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file

[Ivan Shapovalov]

On Thursday 14 August 2014 at 03:10:30, Lennart Poettering wrote:   
 On Mon, 28.07.14 14:06, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  Hello all,
  
  I'm trying to implement resuming from hibernation with systemd-based 
  initramfs,
  i. e. in terms of systemd unit files. That is, there should be a unit which
  waits for the resume device and writes its major:minor into 
  /sys/power/resume.
  
  I've chosen to write a templated resume@path.service and a generator which
  parses 'resume=' kernel parameter and enables a corresponding instance of 
  the
  resume@.service unit.
  
  The resume@.service itself shall be ordered so that it is activated when 
  there
  are no filesystems mounted read-write, except tmpfs instances. It will be 
  good
  if it works both from initramfs and from real rootfs (if it is mounted RO).
  
  So, here are some questions:
  - is it the way to go (overall)?
  - is it OK to use generators for outlined purpose?
  - how to order resume@.service and where to symlink it?
  
  I'm using Arch, if that matters -- but, IIUC, Arch strives to do everything
  in the upstream's way, so there should be no distro-specific details.
 
 I am not entirely sure how the hibernation logic precisely works, but
 wouldn't it be possible to write a little udev rule (maybe with a
 helper) that adds a special device node symlink to the resume partition,
 so that /dev/disk/resume or so always points to the resume partition to
 use?
 
 That udev rule should then maybe also pull in a unit that acts on
 it. But that unit doesn't have to be an instance, could just be a normal
 one...
 
 Does that make any sense?
 
 Lennart

The udev rule should be possible (provided that udevd does not need rootfs
remounted read-write -- I'd like to preserve some decency towards initrd-less
systems), but udev is a framework for handling events, whereas we don't have
any events here: such symlink can be derived from kernel command-line alone,
statically.

Yes, a udev rule would allow to create a symlink which is tracked by systemd,
so the dev-disk-resume.device appears and then it can be easily After='ed
from the resume unit, but... really, is udev the proper tool for this?

Actually, the main question is how to order the resume unit. It needs to run
before any real filesystems are mounted (speaking in terms of initrd) AND before
rootfs is remounted read-write (speaking in terms of initrd-less system), but
after whatever is needed to make the device node appear.

Thanks,
-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Pairing udev's SYSTEMD_WANTS and systemd's templated units

[Ivan Shapovalov]

On Thursday 14 August 2014 at 01:55:26, Lennart Poettering wrote:   
 On Thu, 31.07.14 16:55, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  Hello all,
  
  I'm trying to start from an udev rule a templated systemd unit, whose 
  instance
  should be a properly escaped device node path (so that %i.device would 
  represent
  an existing unit). Which udev specifier should I use for this?
  
  Or, in more clear wording:
  
  given the rule:
  
  ACTION==add, ..., TAG+=systemd, 
  ENV{SYSTEMD_WANTS}+=foo@$some_specifier.service
  
  and the unit foo@.service:
  
  [Unit]
  After=%i.device
  BindsTo=%i.device
  ...
  
  Which $some_specifier should I use in the udev rule to get %i.device in
  my service file to refer to the valid and corresponding device unit?
  
  The closest match I've got is sys%p, but it does not work because dashes 
  are not
  escaped, and I get
  sys-devices-pci:00-:00:1d.0-usb4-4-1-4-1.2.device
  instead of
  sys-devices-pci:00-:00:1d.0-usb4-4\x2d1-4\x2d1.2.device
  and so on.
 
 Can you invoke systemd-escape from the udev rule? 
 
 Lennart
 
 

Yes, (built systemd from git) it seems to work.

/etc/udev/rules.d/99-foo.rules:

ACTION==add, ..., TAG+=systemd, PROGRAM=/usr/bin/systemd-escape -p 
%S%p, ENV{SYSTEMD_WANTS}+=foo@%c.service

/etc/systemd/system/foo@.service:

[Unit]
Description=Test unit for %f
BindsTo=%i.device
After=%i.device

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/etc/systemd/scripts/foo.sh %f

The only thing: PROGRAM=..., ENV{SYSTEMD_WANTS}+=...%c... idiom seems a
pretty ugly way to invoke systemd-escape. This looks like a pretty common
thing to do; shouldn't there be a shorthand or something? (just a suggestion)

Thanks!

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file

[Ivan Shapovalov]

On Thursday 14 August 2014 at 12:56:10, Lennart Poettering wrote:   
 On Thu, 14.08.14 09:20, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  The udev rule should be possible (provided that udevd does not need rootfs
  remounted read-write -- I'd like to preserve some decency towards 
  initrd-less
  systems), but udev is a framework for handling events, whereas we don't have
  any events here: such symlink can be derived from kernel command-line alone,
  statically.
 
 udev is totally fine with read-only everything. It just needs writable
 /run.
 
  Yes, a udev rule would allow to create a symlink which is tracked by 
  systemd,
  so the dev-disk-resume.device appears and then it can be easily After='ed
  from the resume unit, but... really, is udev the proper tool for this?
 
 The symlink thing we already do in a very similar way for the gpt auto root 
 logic (see
 60-persistent-storage.rules) already, so there's prior art.

Understood. So there's a helper (ata_id) ran by IMPORT which sets
ID_PART_GPT_AUTO_ROOT, and then this variable is used to match against...
Looks beautiful, but here's a slightly another case.

In context of hibernation/resume, the path to device node is already
explicitly specified as a kernel cmdline parameter, and it could be anything
from /dev/sdXY to /dev/disk/by-label/foo, so we can't use a helper to translate
that path into a per-device flag (pathes for devices are generated after
running helpers).

So, IIUC, using udev is not an option here. Did I miss anything? If I didn't,
are you OK with the generator + templated unit approach?

 
  Actually, the main question is how to order the resume unit. It needs to run
  before any real filesystems are mounted (speaking in terms of initrd) AND 
  before
  rootfs is remounted read-write (speaking in terms of initrd-less system), 
  but
  after whatever is needed to make the device node appear.
 
 You could turn this into a generator, that pulls the switch from the
 kernel cmdline, and generates a service that orders itself before
 local-fs-pre.taret and after the device you need. The device you need
 you give a stable name via an udev rule. 

So is Before=local-fs-pre.target a sufficient ordering for such resume unit?

Again, the resume unit must be started before any filesystems are (re)mounted
read-write, either from initrd or not.

Seems like there's at least systemd-remount-fs.service that also needs to be
taken into account...

Thanks,
-- 
Ivan Shapovalov / intelfx /

 
 That's pretty much exactly how the got auto root thing works...
 
 Lennart
 
 

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file

[Ivan Shapovalov]

On Friday 15 August 2014 at 11:32:59, Lennart Poettering wrote: 
 On Fri, 15.08.14 13:02, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
 Ah, well, if the resume= switch is supposed to simply carry the finished
 device node path, and nothing we still have to translate into one, then
 of course the entire udev rules step is unnecessary, and you can just
 write this out directly from the generator.

Yes, that's how it happens now.

 
Actually, the main question is how to order the resume unit. It needs 
to run
before any real filesystems are mounted (speaking in terms of initrd) 
AND before
rootfs is remounted read-write (speaking in terms of initrd-less 
system), but
after whatever is needed to make the device node appear.
   
   You could turn this into a generator, that pulls the switch from the
   kernel cmdline, and generates a service that orders itself before
   local-fs-pre.taret and after the device you need. The device you need
   you give a stable name via an udev rule. 
  
  So is Before=local-fs-pre.target a sufficient ordering for such resume 
  unit?
  
  Again, the resume unit must be started before any filesystems are 
  (re)mounted
  read-write, either from initrd or not.
 
 Yes. That should be enough.
 
  Seems like there's at least systemd-remount-fs.service that also needs to be
  taken into account...
 
 That only runs after the transition into the host OS.

I'd like to make this work both with initramfs and without one (provided that
the rootfs has been mounted read-only by using 'ro' kernel cmdline parameter).

In this case, what are the needed orderings?

Thanks,
-- 
Ivan Shapovalov / intelfx /

 
 Lennart
 
 

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Pairing udev's SYSTEMD_WANTS and systemd's templated units

[Ivan Shapovalov]

On Thursday 14 August 2014 at 13:00:50, Lennart Poettering wrote:   
 On Thu, 14.08.14 10:02, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  The only thing: PROGRAM=..., ENV{SYSTEMD_WANTS}+=...%c... idiom seems a
  pretty ugly way to invoke systemd-escape. This looks like a pretty common
  thing to do; shouldn't there be a shorthand or something? (just a 
  suggestion)
 
 Yeah, I agree, but I not entirely sure how this could look like in a
 nice way?
 
 Maybe add:
 
 ENV{SYSTEMD_WANTS_INSTANCE}=bar
 ENV{SYSTEMD_WANTS_TEMPLATE}=foo@.service
 
 or so, would escape bar and add it into foo@.service... But that's not
 particularly generic but focusses only on the instance/template case...
 
 Ideas?
 
 Lennart

How about $(/usr/bin/systemd-escape ...) shell-like syntax ? :)

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Pairing udev's SYSTEMD_WANTS and systemd's templated units

[Ivan Shapovalov]

On Friday 15 August 2014 at 11:34:28, Lennart Poettering wrote: 
 On Fri, 15.08.14 09:58, Harald Hoyer (harald.ho...@gmail.com) wrote:
 
  
  On 14.08.2014 17:27, Lennart Poettering wrote:
   On Thu, 14.08.14 17:10, Harald Hoyer (harald.ho...@gmail.com) wrote:
   
  
   On 14.08.2014 13:00, Lennart Poettering wrote:
   On Thu, 14.08.14 10:02, Ivan Shapovalov (intelfx...@gmail.com) wrote:
  
   The only thing: PROGRAM=..., ENV{SYSTEMD_WANTS}+=...%c... idiom 
   seems a
   pretty ugly way to invoke systemd-escape. This looks like a pretty 
   common
   thing to do; shouldn't there be a shorthand or something? (just a 
   suggestion)
  
   Yeah, I agree, but I not entirely sure how this could look like in a
   nice way?
  
   Maybe add:
  
   ENV{SYSTEMD_WANTS_INSTANCE}=bar
   ENV{SYSTEMD_WANTS_TEMPLATE}=foo@.service
  
   or so, would escape bar and add it into foo@.service... But that's not
   particularly generic but focusses only on the instance/template case...
  
   Ideas?
  
   Lennart
  
  
   Why not extend udev with new % specifiers for the systemd escaped name?
   
   What syntax would you propose? Note that there are probably a couple of
   different strings people might want to have escaped?
   
   Lennart
   
  
  We could probably make it $[path], which would result in $[$devpath] $[%p]
 
 Well, there are at least two modes how to escape strings for unit names
 (one for general string, one for paths). This would become awfully
 complex...
 
 Lennart
 
 

$[...] and ${...} maybe.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file

[Ivan Shapovalov]

On Friday 15 August 2014 at 12:00:41, Lennart Poettering wrote: 
 [...] 

So is Before=local-fs-pre.target a sufficient ordering for such 
resume unit?

Again, the resume unit must be started before any filesystems are 
(re)mounted
read-write, either from initrd or not.
   
   Yes. That should be enough.
   
Seems like there's at least systemd-remount-fs.service that also needs 
to be
taken into account...
   
   That only runs after the transition into the host OS.
  
  I'd like to make this work both with initramfs and without one (provided 
  that
  the rootfs has been mounted read-only by using 'ro' kernel cmdline 
  parameter).
  
  In this case, what are the needed orderings?
 
 Actually systemd-remount-fs.service uses After=local-fs-pre.target
 anyway, so ordering before l-f-p.t should be nough.

Hm. In git (v215-651-g41488fe), it is

Before=local-fs-pre.target local-fs.target shutdown.target
Wants=local-fs-pre.target

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file

[Ivan Shapovalov]

On Friday 15 August 2014 at 12:19:50, Lennart Poettering wrote: 
 [...]

I'd like to make this work both with initramfs and without one 
(provided that
the rootfs has been mounted read-only by using 'ro' kernel cmdline 
parameter).

In this case, what are the needed orderings?
   
   Actually systemd-remount-fs.service uses After=local-fs-pre.target
   anyway, so ordering before l-f-p.t should be nough.
  
  Hm. In git (v215-651-g41488fe), it is
  
  Before=local-fs-pre.target local-fs.target shutdown.target
  Wants=local-fs-pre.target
 
 Ah, right. This is actually correct here. We want to make sure that the
 root fs is remounted before we mount the other units, since this might
 required creating additional directories to mount things on...
 
 There are two more complications: 
 
 a) if you want to make use of local-fs-pre.target you actually have to
pull it in, it's a passive unit. See systemd.special(5).
 
 b) You want to run your stuff before fsck is run on the devices, so that
you don't end up interrupting an fsck that is half in progress.
 
 To put this together, in your unit file you need:
 
 Before=local-fs-pre.target systemd-remount-fs.service 
 systemd-fsck-root.service
 Wants=local-fs-pre.target
 
 That should be enough. (You don't need to individually order the
 systemd-fsck@.service instances for the other devices after your
 service, since they are already ordered after systemd-fsck-root.service,
 and you order yourself before that, so all is good).
 
 Lennart

One more question. What about setups with no initrd and read-write rootfs?
In such cases, the resume unit must silently skip itself.

ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs
this check will yield a false-negative.

This can be solved by introducing two resume units (say,
systemd-resume@.service and initrd-resume@.service), first with

Before=local-fs-pre.target systemd-remount-fs.service 
systemd-fsck-root.service
Wants=local-fs-pre.target
ConditionPathIsReadWrite=!/

and the second one with

ConditionPathExists=/etc/initrd-release
# something else ?

BTW... are you sure that the second variant (in initramfs) does not require 
something
to order before sysroot.mount and all fsck units?..

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [aur-requests] [PRQ#512] Request Accepted

[Ivan Shapovalov]

On Sunday 17 August 2014 at 11:18:25, Martti Kühne wrote:   
 On Sun, Aug 17, 2014 at 7:39 AM, carstene1ns a...@carsten-teibes.de wrote:
 
  Package maintainer was a TU and he even re-uploaded the package now.
  Who is at fault here? FredBezies for requesting? foutrelis for deleting?
  keenerd for maintaining and re-uploading?
 
 
 
 just to bring it up: ...or google for threading all request accepted
 and request declined emails. can't we use the same subject
 (thread-id?) as the respective request? that would provide a more
 sensible grouping in whatever email browser you're using...
 
 cheers!
 mar77i

The In-Reply-To: header seems to be correctly set on automated emails.

Apparently it's gmail web interface to blame.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file

[Ivan Shapovalov]

On Friday 15 August 2014 at 15:35:06, Ivan Shapovalov wrote:
 [...]
  
  Ah, right. This is actually correct here. We want to make sure that the
  root fs is remounted before we mount the other units, since this might
  required creating additional directories to mount things on...
  
  There are two more complications: 
  
  a) if you want to make use of local-fs-pre.target you actually have to
 pull it in, it's a passive unit. See systemd.special(5).
  
  b) You want to run your stuff before fsck is run on the devices, so that
 you don't end up interrupting an fsck that is half in progress.
  
  To put this together, in your unit file you need:
  
  Before=local-fs-pre.target systemd-remount-fs.service 
  systemd-fsck-root.service
  Wants=local-fs-pre.target
  
  That should be enough. (You don't need to individually order the
  systemd-fsck@.service instances for the other devices after your
  service, since they are already ordered after systemd-fsck-root.service,
  and you order yourself before that, so all is good).
  
  Lennart
 
 One more question. What about setups with no initrd and read-write rootfs?
 In such cases, the resume unit must silently skip itself.
 
 ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs
 this check will yield a false-negative.
 
 This can be solved by introducing two resume units (say,
 systemd-resume@.service and initrd-resume@.service), first with
 
 Before=local-fs-pre.target systemd-remount-fs.service 
 systemd-fsck-root.service
 Wants=local-fs-pre.target
 ConditionPathIsReadWrite=!/
 
 and the second one with
 
 ConditionPathExists=/etc/initrd-release
 # something else ?
 
 BTW... are you sure that the second variant (in initramfs) does not require 
 something
 to order before sysroot.mount and all fsck units?..

Actually, in case of initramfs these dependencies are not enough.

In case of initramfs, there is no apparent way to order before
all mounts and their fsck instances, especially given that there are no
equivalents of systemd-remount-fs.service and systemd-fsck-root.service.

Or do I miss something? Could you (someone) please give an advice?

I'm also uncertain whether having two units (for initramfs and for real root)
is the only way.

Thanks,
-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file

[Ivan Shapovalov]

On Monday 18 August 2014 at 15:57:25, Lennart Poettering wrote: 
 On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
   That should be enough. (You don't need to individually order the
   systemd-fsck@.service instances for the other devices after your
   service, since they are already ordered after systemd-fsck-root.service,
   and you order yourself before that, so all is good).
  
  One more question. What about setups with no initrd and read-write rootfs?
  In such cases, the resume unit must silently skip itself.
  
  ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs
  this check will yield a false-negative.
 
 I am pretty sure the hibernation stuff should only be supported when an
 initrd is used. And in that case we should simply not pull in the
 hibernation service into the non-initrd initial transaction (or in other
 words, only pull it in by initrd.target, but not otherwise).

Even if initramfs-only, ordering dependencies still need to be worked out.
Inside of initramfs, neither systemd-fsck-root.service nor 
systemd-remount-fs.service
do exist, so there's apparently nothing to reliably order against.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file

[Ivan Shapovalov]

On Monday 18 August 2014 at 18:40:59, Lennart Poettering wrote: 
 On Mon, 18.08.14 18:00, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  On Monday 18 August 2014 at 15:57:25, Lennart Poettering wrote: 
   On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote:
   
 That should be enough. (You don't need to individually order the
 systemd-fsck@.service instances for the other devices after your
 service, since they are already ordered after 
 systemd-fsck-root.service,
 and you order yourself before that, so all is good).

One more question. What about setups with no initrd and read-write 
rootfs?
In such cases, the resume unit must silently skip itself.

ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with 
initramfs
this check will yield a false-negative.
   
   I am pretty sure the hibernation stuff should only be supported when an
   initrd is used. And in that case we should simply not pull in the
   hibernation service into the non-initrd initial transaction (or in other
   words, only pull it in by initrd.target, but not otherwise).
  
  Even if initramfs-only, ordering dependencies still need to be worked out.
  Inside of initramfs, neither systemd-fsck-root.service nor 
  systemd-remount-fs.service
  do exist, so there's apparently nothing to reliably order against.
 
 Well, in the initrd the root dir is mounted to /sysroot, which means you
 should be able to order yourself before sysroot.mount.
 
 Lennart
 


...missing sysroot's fsck, as well as any other x-initrd mounts and their fsck 
instances.

Seems that sysroot.mount alone isn't sufficient.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file

[Ivan Shapovalov]

On Thursday 21 August 2014 at 01:03:20, Lennart Poettering wrote:   
 [...]
   
   ...missing sysroot's fsck, as well as any other x-initrd mounts and their 
   fsck instances.
   
   Seems that sysroot.mount alone isn't sufficient.
  
  ...Anything on this?
  
  Should we add yet another passive target(s), something like fsck-pre? I 
  don't
  actually know what is the best way to tackle this. The resume unit shall be
  activated before any writes to any block devices, including fsck, cryptsetup
  and whatever else.
 
 Hmm, so I though a bit about this, and I think we should make the
 following changes to systemd:
 
 a) move local-fs-pre.target before all the fsck. This way we can make
use of it as a barrier against modifications of any fs.

...all fsck except the systemd-fsck-root.service, right? It's already ordered
before local-fs-pre.target.

Makes sense; then the resume unit will be

Wants=local-fs-pre.target
Before=local-fs-pre.target systemd-fsck-root.service 
systemd-remount-fs.service shutdown.target
ConditionPathIsReadWrite=!/

However, this breaks when there is a legacy /usr mount without fsck...
src/core/mount.c:mount_add_default_dependencies() does not add
After=local-fs-pre.target if the mount in question is / or /usr.

Hence, the legacy /usr mount is missed by this scheme.

 
 
 b) introduce initrd-fs-pre.target that then plays a similar role, but in
the initrd.

Is it neeeded? IIUC, local-fs-pre.target can be used in initramfs as well,
the default dependency on this target is still generated on all mounts.
(except in-initramfs /usr, see the above problem)

 
 A service that wants to run before any fs is touched should then order
 itself before both and everything should be good.
 
 If this makes sense, I would be happy to take a patch.
 
 I'd be willing to merge a good patch for a generator + mini-tool that
 parse the resume= option into systemd as well, btw.

I've already implemented the generator and resume tool prototype. Sure, when we
solve the dependencies problem, I'll submit this for inclusion.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file

[Ivan Shapovalov]

On Thursday 21 August 2014 at 22:06:49, Ivan Shapovalov wrote:  
 On Thursday 21 August 2014 at 01:03:20, Lennart Poettering wrote: 
  [...]

...missing sysroot's fsck, as well as any other x-initrd mounts and 
their fsck instances.

Seems that sysroot.mount alone isn't sufficient.
   
   ...Anything on this?
   
   Should we add yet another passive target(s), something like fsck-pre? I 
   don't
   actually know what is the best way to tackle this. The resume unit shall 
   be
   activated before any writes to any block devices, including fsck, 
   cryptsetup
   and whatever else.
  
  Hmm, so I though a bit about this, and I think we should make the
  following changes to systemd:
  
  a) move local-fs-pre.target before all the fsck. This way we can make
 use of it as a barrier against modifications of any fs.
 
 ...all fsck except the systemd-fsck-root.service, right? It's already ordered
 before local-fs-pre.target.
 
 Makes sense; then the resume unit will be
 
 Wants=local-fs-pre.target
 Before=local-fs-pre.target systemd-fsck-root.service 
 systemd-remount-fs.service shutdown.target
 ConditionPathIsReadWrite=!/
 
 However, this breaks when there is a legacy /usr mount without fsck...
 src/core/mount.c:mount_add_default_dependencies() does not add
 After=local-fs-pre.target if the mount in question is / or /usr.
 
 Hence, the legacy /usr mount is missed by this scheme.

Actually, I don't pretty understand the reasoning behind skipping the default
dependencies on /usr mount (commit b24de9d2, but the commit message doesn't
say much).

So hypothetically there are three solutions of different ugliness and
acceptability:

- introduce yet another target (all-fs-pre.t?)
- revert b24de9d2
- add explicit Before=usr.mount to the resume unit

-- 
Ivan Shapovalov / intelfx /

 
  
  
  b) introduce initrd-fs-pre.target that then plays a similar role, but in
 the initrd.
 
 Is it neeeded? IIUC, local-fs-pre.target can be used in initramfs as well,
 the default dependency on this target is still generated on all mounts.
 (except in-initramfs /usr, see the above problem)
 
  
  A service that wants to run before any fs is touched should then order
  itself before both and everything should be good.
  
  If this makes sense, I would be happy to take a patch.
  
  I'd be willing to merge a good patch for a generator + mini-tool that
  parse the resume= option into systemd as well, btw.
 
 I've already implemented the generator and resume tool prototype. Sure, when 
 we
 solve the dependencies problem, I'll submit this for inclusion.
 
 

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file

[Ivan Shapovalov]

On Thursday 21 August 2014 at 19:32:01, Simon McVittie wrote:   
 On 21/08/14 19:12, Ivan Shapovalov wrote:
  Actually, I don't pretty understand the reasoning behind skipping the 
  default
  dependencies on /usr mount
 
 (Some of) the default dependencies require that /usr is mounted, so
 mounting /usr cannot depend on them, to avoid a cycle.
 
 (Or to put it the way round: normal, non-early-boot services should be
 able to assume that /usr is mounted so that they can rely on files in
 /usr/lib or /usr/share without explicitly declaring extra dependencies,
 which again means /usr can't depend on the default dependencies.)

Understood, thanks.

(For the original discussion: so is it better to explicitly Before=usr.mount?)

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file

[Ivan Shapovalov]

On Thursday 21 August 2014 at 01:03:20, Lennart Poettering wrote:   
 On Tue, 19.08.14 15:46, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  On Monday 18 August 2014 at 22:04:29, Ivan Shapovalov wrote:
   [..]
 
 Even if initramfs-only, ordering dependencies still need to be worked 
 out.
 Inside of initramfs, neither systemd-fsck-root.service nor 
 systemd-remount-fs.service
 do exist, so there's apparently nothing to reliably order against.

Well, in the initrd the root dir is mounted to /sysroot, which means you
should be able to order yourself before sysroot.mount.

Lennart

   
   
   ...missing sysroot's fsck, as well as any other x-initrd mounts and their 
   fsck instances.
   
   Seems that sysroot.mount alone isn't sufficient.
  
  ...Anything on this?
  
  Should we add yet another passive target(s), something like fsck-pre? I 
  don't
  actually know what is the best way to tackle this. The resume unit shall be
  activated before any writes to any block devices, including fsck, cryptsetup
  and whatever else.
 
 Hmm, so I though a bit about this, and I think we should make the
 following changes to systemd:
 
 a) move local-fs-pre.target before all the fsck. This way we can make
use of it as a barrier against modifications of any fs.
 
 
 b) introduce initrd-fs-pre.target that then plays a similar role, but in
the initrd.
 
 A service that wants to run before any fs is touched should then order
 itself before both and everything should be good.
 
 If this makes sense, I would be happy to take a patch.
 
 I'd be willing to merge a good patch for a generator + mini-tool that
 parse the resume= option into systemd as well, btw.

So I have the prototype ready, but it seems that udevd indirectly depends
on remounting / read-write.

systemd-remount-fs.service - systemd-sysusers.service - systemd-udevd.service

This breaks the idea at least in the initramfs-less case (and also in the
pathological case of including systemd-sysusers.service into initramfs).

What would you suggest?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [RFC] [PATCH 3/3] resume-generator: add a generator for instantiating the resume unit.

[Ivan Shapovalov]

resume-generator understands resume= kernel command line parameter and
instantiates the systemd-resume@.service accordingly if it is passed.

This enables resume from hibernation using device specified on the kernel
command line, where the device path may point to an arbitrary udev-created
symlink, not only /dev/sdXY which is understood by the in-kernel
implementation.
---
 man/kernel-command-line.xml | 13 -
 man/systemd-resume-generator.xml| 91 +
 src/resume-generator/Makefile   |  1 +
 src/resume-generator/resume-generator.c | 89 
 4 files changed, 193 insertions(+), 1 deletion(-)
 create mode 100644 man/systemd-resume-generator.xml
 create mode 12 src/resume-generator/Makefile
 create mode 100644 src/resume-generator/resume-generator.c

diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index f244bfc..4bc6cee 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -351,6 +351,16 @@
 /listitem
 /varlistentry
 
+varlistentry
+termvarnameresume=/varname/term
+
+listitem
+paraEnables resume from hibernation
+using the specified device. For
+details, see
+
citerefentryrefentrytitlesystemd-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry./para
+/listitem
+/varlistentry
 /variablelist
 
 /refsect1
@@ -373,7 +383,8 @@
   
citerefentryrefentrytitlesystemd-gpt-auto-generator/refentrytitlemanvolnum8/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd-modules-load.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd-backlight@.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
-  
citerefentryrefentrytitlesystemd-rfkill@.service/refentrytitlemanvolnum8/manvolnum/citerefentry
+  
citerefentryrefentrytitlesystemd-rfkill@.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
+  
citerefentryrefentrytitlesystemd-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry
   /para
 /refsect1
 
diff --git a/man/systemd-resume-generator.xml b/man/systemd-resume-generator.xml
new file mode 100644
index 000..7962534
--- /dev/null
+++ b/man/systemd-resume-generator.xml
@@ -0,0 +1,91 @@
+?xml version=1.0?
+!--*-nxml-*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+!--
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+--
+refentry id=systemd-resume-generator
+
+refentryinfo
+titlesystemd-resume-generator/title
+productnamesystemd/productname
+
+authorgroup
+author
+contribDeveloper/contrib
+firstnameIvan/firstname
+surnameShapovalov/surname
+emailintelfx...@gmail.com/email
+/author
+/authorgroup
+/refentryinfo
+
+refmeta
+refentrytitlesystemd-resume-generator/refentrytitle
+manvolnum8/manvolnum
+/refmeta
+
+refnamediv
+refnamesystemd-resume-generator/refname
+refpurposeUnit generator for resume= kernel 
parameter/refpurpose
+/refnamediv
+
+refsynopsisdiv
+
parafilename/usr/lib/systemd/system-generators/systemd-resume-generator/filename/para
+/refsynopsisdiv
+
+refsect1
+titleDescription/title
+
+parafilenamesystemd-resume-generator/filename is
+a generator that instantiates
+
citerefentryrefentrytitlesystemd-resume@.service/refentrytitlemanvolnum8/manvolnum/citerefentry
+unit

[systemd-devel] [RFC] [PATCH 2/3] resume: add a tool to write a device node's major:minor to /sys/power/resume.

[Ivan Shapovalov]

 # 
--
 systemgenerator_PROGRAMS +=  \
diff --git a/man/systemd-res...@.service.xml b/man/systemd-res...@.service.xml
new file mode 100644
index 000..b7d28fb
--- /dev/null
+++ b/man/systemd-res...@.service.xml
@@ -0,0 +1,81 @@
+?xml version=1.0?
+!--*-nxml-*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+!--
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+--
+refentry id=systemd-resume@.service
+
+refentryinfo
+titlesystemd-resume@.service/title
+productnamesystemd/productname
+
+authorgroup
+author
+contribDeveloper/contrib
+firstnameIvan/firstname
+surnameShapovalov/surname
+emailintelfx...@gmail.com/email
+/author
+/authorgroup
+/refentryinfo
+
+refmeta
+refentrytitlesystemd-resume@.service/refentrytitle
+manvolnum8/manvolnum
+/refmeta
+
+refnamediv
+refnamesystemd-resume@.service/refname
+refnamesystemd-resume/refname
+refpurposeResume from hibernation/refpurpose
+/refnamediv
+
+refsynopsisdiv
+parafilenamesystemd-resume@.service/filename/para
+
parafilename/usr/lib/systemd/systemd-resume/filename/para
+/refsynopsisdiv
+
+refsect1
+titleDescription/title
+
+parafilenamesystemd-resume@.service/filename is a
+service that initiates hibernation resume from a device
+containing the resume image. It is instantiated for each
+device that is configured for resuming from./para
+
+parafilenamesystemd-resume/filename only supports
+the in-kernel hibernation implementation, known as swsusp.
+Internally, it works by writing the major:minor of specified
+device node to filename/sys/power/resume/filename./para
+
+paraFailing to initiate a resume is not an error condition.
+It may mean that there was no resume image (e. g. if the
+system has been simply powered off and not hibernated). In
+such case, the boot is ordinarily continued./para
+/refsect1
+
+refsect1
+titleSee Also/title
+para
+
citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry,
+
citerefentryrefentrytitlesystemd-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry
+/para
+/refsect1
+
+/refentry
diff --git a/src/resume/Makefile b/src/resume/Makefile
new file mode 12
index 000..d0b0e8e
--- /dev/null
+++ b/src/resume/Makefile
@@ -0,0 +1 @@
+../Makefile
\ No newline at end of file
diff --git a/src/resume/resume.c b/src/resume/resume.c
new file mode 100644
index 000..9bda8ff
--- /dev/null
+++ b/src/resume/resume.c
@@ -0,0 +1,82 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include stdio.h
+#include errno.h
+#include sys/types.h
+#include sys/stat.h
+#include unistd.h
+
+#include log.h
+#include util.h
+#include fileio.h
+
+int main(int argc, char *argv[]) {
+struct stat st;
+const char *device

[systemd-devel] [RFC] [PATCH 1/3] units: order systemd-fsck@.service after local-fs-pre.target.

[Ivan Shapovalov]

With this change, it becomes possible to order a unit to activate before any
modifications to the file systems. This is especially useful for supporting
resume from hibernation.
---
 units/systemd-f...@.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/units/systemd-f...@.service.in b/units/systemd-f...@.service.in
index c12efa8..d2cda6a 100644
--- a/units/systemd-f...@.service.in
+++ b/units/systemd-f...@.service.in
@@ -10,7 +10,7 @@ Description=File System Check on %f
 Documentation=man:systemd-fsck@.service(8)
 DefaultDependencies=no
 BindsTo=%i.device
-After=systemd-readahead-collect.service systemd-readahead-replay.service 
%i.device systemd-fsck-root.service
+After=systemd-readahead-collect.service systemd-readahead-replay.service 
%i.device systemd-fsck-root.service local-fs-pre.target
 Before=shutdown.target
 
 [Service]
-- 
2.1.0

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

[systemd-devel] [RFC] [PATCH 0/3] resume: implement support for resuming from hibernation

[Ivan Shapovalov]

This patchset allows systemd to parse resume= kernel command line parameter
and initiate resume from the specified device.

It adds:
- a 'systemd-resume' tool which takes path to a device node and
  writes its major:minor to /sys/power/state;
- a corresponding 'systemd-resume@.service' templated unit;
- a 'systemd-resume-generator' generator which parses the kernel command line
  and instantiates the unit as necessary.

This functionality already exists in-kernel, but only for /dev/sdXY-style
pathes. Implementing it in userspace allows to use arbitrary udev-created
symlinks, e. g. persistent block device pathes (/dev/disk/by-foo/bar).

Userspace parsing of resume= kernel command line parameter has been
traditionally done in initramfs via shell scripts (for Arch Linux, this is
resume mkinitcpio hook), so I feel that this feature has its place within
systemd.

Due to the nature of hibernation, the resume unit must be activated before
any modifications to filesystems take place. This can happen
1) in initramfs before mounting anything, and
2) without initramfs before remounting rootfs read-write (provided that it is
   mounted RO initially).

So, first patch orders all non-root fsck after local-fs-pre.target, which in
turn allows to order the resume unit before those fsck instances.

Second and third patches add the tool, the unit and the generator.

There are some issues with this implementation:

- legacy usr.mount is not automatically ordered after local-fs-pre.target,
  so systemd-resume@.service has to be manually ordered before it;
- systemd-udevd.service, which is needed for creating persistent block device
  symlinks, is transitively ordered after systemd-remount-fs.service via at
  least systemd-udev-hwdb-update.service and systemd-sysusers.service.
  Hence, if these units are present (at least initramfs-less case), an ordering
  cycle happens and resume is impossible.

So, I would like someone to comment on these.

This is my first patch to this project, so feel free to flak me for missing
something obvious :)

Thanks for reviewing!

Ivan Shapovalov (3):
  units: order systemd-fsck@.service after local-fs-pre.target.
  resume: add a tool to write a device node's major:minor to /sys/power/resume.
  resume-generator: add a generator for instantiating the resume unit.

 Makefile-man.am |  9 
 Makefile.am | 28 --
 man/kernel-command-line.xml | 13 -
 man/systemd-resume-generator.xml| 91 +
 man/systemd-res...@.service.xml | 81 +
 src/resume-generator/Makefile   |  1 +
 src/resume-generator/resume-generator.c | 89 
 src/resume/Makefile |  1 +
 src/resume/resume.c | 82 +
 units/systemd-f...@.service.in  |  2 +-
 units/systemd-res...@.service.in| 23 +
 11 files changed, 414 insertions(+), 6 deletions(-)
 create mode 100644 man/systemd-resume-generator.xml
 create mode 100644 man/systemd-res...@.service.xml
 create mode 12 src/resume-generator/Makefile
 create mode 100644 src/resume-generator/resume-generator.c
 create mode 12 src/resume/Makefile
 create mode 100644 src/resume/resume.c
 create mode 100644 units/systemd-res...@.service.in

-- 
2.1.0

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

Re: [systemd-devel] [RFC] [PATCH 0/3] resume: implement support for resuming from hibernation

[Ivan Shapovalov]

On Saturday 23 August 2014 at 18:22:42, Andrei Borzenkov wrote: 
 В Sat, 23 Aug 2014 16:47:51 +0400
 Ivan Shapovalov intelfx...@gmail.com пишет:
 
  This patchset allows systemd to parse resume= kernel command line parameter
  and initiate resume from the specified device.
  
  It adds:
  - a 'systemd-resume' tool which takes path to a device node and
writes its major:minor to /sys/power/state;
  - a corresponding 'systemd-resume@.service' templated unit;
  - a 'systemd-resume-generator' generator which parses the kernel command 
  line
and instantiates the unit as necessary.
  
  This functionality already exists in-kernel, but only for /dev/sdXY-style
  pathes. Implementing it in userspace allows to use arbitrary udev-created
  symlinks, e. g. persistent block device pathes (/dev/disk/by-foo/bar).
  
  Userspace parsing of resume= kernel command line parameter has been
  traditionally done in initramfs via shell scripts (for Arch Linux, this is
  resume mkinitcpio hook), so I feel that this feature has its place within
  systemd.
  
  Due to the nature of hibernation, the resume unit must be activated before
  any modifications to filesystems take place. This can happen
  1) in initramfs before mounting anything, and
  2) without initramfs before remounting rootfs read-write (provided that it 
  is
 mounted RO initially).
  
 
 Your patch has
 
 +ConditionPathExists=|/etc/initrd-release
 
 Which excludes non-initrd usage, right? Also some filesystems (reiserfs
 comes in mind) replayed journal even when mounted read-only. So may be
 it should explicitly state initrd-only support and name units
 accordingly.

It doesn't exclude non-initramfs image -- there is a second OR-ed conditional
allowing this unit to run on a ro-mounted real root.

I didn't know that reiserfs can write to a ro-mounted fs. If that's true,
non-initramfs usage must be prohibited. I'll send a v2.

Thanks for pointing that out!

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [RFC] [PATCHv2 3/3] resume-generator: add a generator for instantiating the resume unit.

[Ivan Shapovalov]

resume-generator understands resume= kernel command line parameter and
instantiates the systemd-resume@.service accordingly if it is passed.

This enables resume from hibernation using device specified on the kernel
command line, where the device path may point to an arbitrary udev-created
symlink, not only /dev/sdXY which is understood by the in-kernel
implementation.
---
 Makefile-man.am |  2 +
 man/kernel-command-line.xml | 13 -
 man/systemd-resume-generator.xml| 91 
 src/resume-generator/Makefile   |  1 +
 src/resume-generator/resume-generator.c | 93 +
 5 files changed, 199 insertions(+), 1 deletion(-)
 create mode 100644 man/systemd-resume-generator.xml
 create mode 12 src/resume-generator/Makefile
 create mode 100644 src/resume-generator/resume-generator.c

diff --git a/Makefile-man.am b/Makefile-man.am
index be19905..00daae2 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -76,6 +76,7 @@ MANPAGES += \
man/systemd-nspawn.1 \
man/systemd-path.1 \
man/systemd-remount-fs.service.8 \
+   man/systemd-resume-generator.8 \
man/systemd-resume@.service.8 \
man/systemd-run.1 \
man/systemd-shutdownd.service.8 \
@@ -1632,6 +1633,7 @@ EXTRA_DIST += \
man/systemd-readahead-replay.service.xml \
man/systemd-remount-fs.service.xml \
man/systemd-resolved.service.xml \
+   man/systemd-resume-generator.xml \
man/systemd-res...@.service.xml \
man/systemd-rfk...@.service.xml \
man/systemd-run.xml \
diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index f244bfc..4bc6cee 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -351,6 +351,16 @@
 /listitem
 /varlistentry
 
+varlistentry
+termvarnameresume=/varname/term
+
+listitem
+paraEnables resume from hibernation
+using the specified device. For
+details, see
+
citerefentryrefentrytitlesystemd-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry./para
+/listitem
+/varlistentry
 /variablelist
 
 /refsect1
@@ -373,7 +383,8 @@
   
citerefentryrefentrytitlesystemd-gpt-auto-generator/refentrytitlemanvolnum8/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd-modules-load.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd-backlight@.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
-  
citerefentryrefentrytitlesystemd-rfkill@.service/refentrytitlemanvolnum8/manvolnum/citerefentry
+  
citerefentryrefentrytitlesystemd-rfkill@.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
+  
citerefentryrefentrytitlesystemd-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry
   /para
 /refsect1
 
diff --git a/man/systemd-resume-generator.xml b/man/systemd-resume-generator.xml
new file mode 100644
index 000..7962534
--- /dev/null
+++ b/man/systemd-resume-generator.xml
@@ -0,0 +1,91 @@
+?xml version=1.0?
+!--*-nxml-*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+!--
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+--
+refentry id=systemd-resume-generator
+
+refentryinfo
+titlesystemd-resume-generator/title
+productnamesystemd/productname
+
+authorgroup
+author
+contribDeveloper/contrib
+firstnameIvan/firstname
+surnameShapovalov/surname
+emailintelfx...@gmail.com/email
+/author
+/authorgroup
+/refentryinfo

[systemd-devel] [RFC] [PATCHv2 0/3] resume: implement support for resuming from hibernation

[Ivan Shapovalov]

This patchset allows systemd to parse resume= kernel command line parameter
and initiate resume from the specified device.

It adds:
- a 'systemd-resume' tool which takes path to a device node and
  writes its major:minor to /sys/power/state;
- a corresponding 'systemd-resume@.service' templated unit;
- a 'systemd-resume-generator' generator which parses the kernel command line
  and instantiates the unit as necessary.

This functionality already exists in-kernel, but only for /dev/sdXY-style
pathes. Implementing it in userspace allows to use arbitrary udev-created
symlinks, e. g. persistent block device pathes (/dev/disk/by-foo/bar).

Userspace parsing of resume= kernel command line parameter has been
traditionally done in initramfs via shell scripts (for Arch Linux, this is
resume mkinitcpio hook), so I feel that this feature has its place within
systemd.

Due to the nature of hibernation, the resume unit must be activated before
any modifications to filesystems take place. This can happen only in initramfs
before mounting anything.

So, first patch orders all non-root fsck after local-fs-pre.target, which in
turn allows to order the resume unit before those fsck instances.

Second and third patches add the tool, the unit and the generator.

There are some issues with this implementation.

- legacy usr.mount is not automatically ordered after local-fs-pre.target,
  so systemd-resume@.service has to be manually ordered before it;
- systemd-udevd.service, which is needed for creating persistent block device
  symlinks, is transitively ordered after systemd-remount-fs.service via at
  least systemd-udev-hwdb-update.service and systemd-sysusers.service.
  Hence, if these units are present, an ordering cycle happens and resume is
  impossible.

Encountering these conditions is very unlikely inside of an initramfs (who
would make the in-initramfs /usr external? who would add systemd-sysusers
into initramfs?), but there can still be pathological cases.

So, I would like someone to comment on these issues.

This is my first patch to this project, so feel free to flak me for missing
something obvious :)

Thanks for reviewing!

v2: fix issues pointed out by Andrei:
- don't RemainAfterExit because it's useless
- don't attempt to resume outside of initramfs because it's unsafe
  (reiserfs replays journal even if mounted RO)

Ivan Shapovalov (3):
  units: order systemd-fsck@.service after local-fs-pre.target.
  resume: add a tool to write a device node's major:minor to /sys/power/resume.
  resume-generator: add a generator for instantiating the resume unit.

 Makefile-man.am |  9 
 Makefile.am | 28 --
 man/kernel-command-line.xml | 13 -
 man/systemd-resume-generator.xml| 91 
 man/systemd-res...@.service.xml | 81 
 src/resume-generator/Makefile   |  1 +
 src/resume-generator/resume-generator.c | 93 +
 src/resume/Makefile |  1 +
 src/resume/resume.c | 82 +
 units/systemd-f...@.service.in  |  2 +-
 units/systemd-res...@.service.in| 20 +++
 11 files changed, 415 insertions(+), 6 deletions(-)
 create mode 100644 man/systemd-resume-generator.xml
 create mode 100644 man/systemd-res...@.service.xml
 create mode 12 src/resume-generator/Makefile
 create mode 100644 src/resume-generator/resume-generator.c
 create mode 12 src/resume/Makefile
 create mode 100644 src/resume/resume.c
 create mode 100644 units/systemd-res...@.service.in

-- 
2.1.0

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

[systemd-devel] [RFC] [PATCHv2 1/3] units: order systemd-fsck@.service after local-fs-pre.target.

[Ivan Shapovalov]

With this change, it becomes possible to order a unit to activate before any
modifications to the file systems. This is especially useful for supporting
resume from hibernation.
---
 units/systemd-f...@.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/units/systemd-f...@.service.in b/units/systemd-f...@.service.in
index c12efa8..d2cda6a 100644
--- a/units/systemd-f...@.service.in
+++ b/units/systemd-f...@.service.in
@@ -10,7 +10,7 @@ Description=File System Check on %f
 Documentation=man:systemd-fsck@.service(8)
 DefaultDependencies=no
 BindsTo=%i.device
-After=systemd-readahead-collect.service systemd-readahead-replay.service 
%i.device systemd-fsck-root.service
+After=systemd-readahead-collect.service systemd-readahead-replay.service 
%i.device systemd-fsck-root.service local-fs-pre.target
 Before=shutdown.target
 
 [Service]
-- 
2.1.0

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

[systemd-devel] [RFC] [PATCHv2 2/3] resume: add a tool to write a device node's major:minor to /sys/power/resume.

[Ivan Shapovalov]

 # 
--
 systemgenerator_PROGRAMS +=  \
diff --git a/man/systemd-res...@.service.xml b/man/systemd-res...@.service.xml
new file mode 100644
index 000..b7d28fb
--- /dev/null
+++ b/man/systemd-res...@.service.xml
@@ -0,0 +1,81 @@
+?xml version=1.0?
+!--*-nxml-*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+!--
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+--
+refentry id=systemd-resume@.service
+
+refentryinfo
+titlesystemd-resume@.service/title
+productnamesystemd/productname
+
+authorgroup
+author
+contribDeveloper/contrib
+firstnameIvan/firstname
+surnameShapovalov/surname
+emailintelfx...@gmail.com/email
+/author
+/authorgroup
+/refentryinfo
+
+refmeta
+refentrytitlesystemd-resume@.service/refentrytitle
+manvolnum8/manvolnum
+/refmeta
+
+refnamediv
+refnamesystemd-resume@.service/refname
+refnamesystemd-resume/refname
+refpurposeResume from hibernation/refpurpose
+/refnamediv
+
+refsynopsisdiv
+parafilenamesystemd-resume@.service/filename/para
+
parafilename/usr/lib/systemd/systemd-resume/filename/para
+/refsynopsisdiv
+
+refsect1
+titleDescription/title
+
+parafilenamesystemd-resume@.service/filename is a
+service that initiates hibernation resume from a device
+containing the resume image. It is instantiated for each
+device that is configured for resuming from./para
+
+parafilenamesystemd-resume/filename only supports
+the in-kernel hibernation implementation, known as swsusp.
+Internally, it works by writing the major:minor of specified
+device node to filename/sys/power/resume/filename./para
+
+paraFailing to initiate a resume is not an error condition.
+It may mean that there was no resume image (e. g. if the
+system has been simply powered off and not hibernated). In
+such case, the boot is ordinarily continued./para
+/refsect1
+
+refsect1
+titleSee Also/title
+para
+
citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry,
+
citerefentryrefentrytitlesystemd-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry
+/para
+/refsect1
+
+/refentry
diff --git a/src/resume/Makefile b/src/resume/Makefile
new file mode 12
index 000..d0b0e8e
--- /dev/null
+++ b/src/resume/Makefile
@@ -0,0 +1 @@
+../Makefile
\ No newline at end of file
diff --git a/src/resume/resume.c b/src/resume/resume.c
new file mode 100644
index 000..9bda8ff
--- /dev/null
+++ b/src/resume/resume.c
@@ -0,0 +1,82 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include stdio.h
+#include errno.h
+#include sys/types.h
+#include sys/stat.h
+#include unistd.h
+
+#include log.h
+#include util.h
+#include fileio.h
+
+int main(int argc, char *argv[]) {
+struct stat st;
+const char *device, *major_minor;
+int r;
+
+if (argc != 2) {
+log_error

Re: [systemd-devel] [RFC] [PATCH 0/3] resume: implement support for resuming from hibernation

[Ivan Shapovalov]

On Saturday 23 August 2014 at 21:05:13, Tobias Geerinckx-Rice wrote:
 On 23 August 2014 14:47, Ivan Shapovalov intelfx...@gmail.com wrote:
  This is my first patch to this project, so feel free to flak me for missing
  something obvious :)
 
 On 4 August 2014 10:39, Tobias Geerinckx-Rice
 tobias.geerinckx.r...@gmail.com wrote:
  (As this is my first systemd patch, feel free to flak me for missing
  something obvious.)
 
 http://media.tumblr.com/tumblr_lpn8viK7f61qc4jgq.jpg
 
 On a more serious note: thanks for pursuing this; I hope it makes it
 into git soon!

I was just struggling to recall where have I seen this phrase :)

Well, sorry for stealing, but it exactly describes my feeling about this.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [RFC] [PATCHv3 2/3] resume: add a tool to write a device node's major:minor to /sys/power/resume.

[Ivan Shapovalov]

This can be used to initiate a resume from hibernation by path to a swap
device containing the hibernation image.

The respective templated unit is also added. It is instantiated using
path to the desired resume device.
---
 Makefile-man.am  |  7 
 Makefile.am  | 17 ++--
 man/systemd-res...@.service.xml  | 81 +++
 src/resume/Makefile  |  1 +
 src/resume/resume.c  | 83 
 units/systemd-res...@.service.in | 20 ++
 6 files changed, 206 insertions(+), 3 deletions(-)
 create mode 100644 man/systemd-res...@.service.xml
 create mode 12 src/resume/Makefile
 create mode 100644 src/resume/resume.c
 create mode 100644 units/systemd-res...@.service.in

diff --git a/Makefile-man.am b/Makefile-man.am
index 5c289dd..be19905 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -76,6 +76,7 @@ MANPAGES += \
man/systemd-nspawn.1 \
man/systemd-path.1 \
man/systemd-remount-fs.service.8 \
+   man/systemd-resume@.service.8 \
man/systemd-run.1 \
man/systemd-shutdownd.service.8 \
man/systemd-sleep.conf.5 \
@@ -206,6 +207,7 @@ MANPAGES_ALIAS += \
man/systemd-poweroff.service.8 \
man/systemd-reboot.service.8 \
man/systemd-remount-fs.8 \
+   man/systemd-resume.8 \
man/systemd-shutdown.8 \
man/systemd-shutdownd.8 \
man/systemd-shutdownd.socket.8 \
@@ -311,6 +313,7 @@ man/systemd-kexec.service.8: man/systemd-halt.service.8
 man/systemd-poweroff.service.8: man/systemd-halt.service.8
 man/systemd-reboot.service.8: man/systemd-halt.service.8
 man/systemd-remount-fs.8: man/systemd-remount-fs.service.8
+man/systemd-resume.8: man/systemd-resume@.service.8
 man/systemd-shutdown.8: man/systemd-halt.service.8
 man/systemd-shutdownd.8: man/systemd-shutdownd.service.8
 man/systemd-shutdownd.socket.8: man/systemd-shutdownd.service.8
@@ -592,6 +595,9 @@ man/systemd-reboot.service.html: 
man/systemd-halt.service.html
 man/systemd-remount-fs.html: man/systemd-remount-fs.service.html
$(html-alias)
 
+man/systemd-resume.html: man/systemd-res...@.service.html
+   $(html-alias)
+
 man/systemd-shutdown.html: man/systemd-halt.service.html
$(html-alias)
 
@@ -1626,6 +1632,7 @@ EXTRA_DIST += \
man/systemd-readahead-replay.service.xml \
man/systemd-remount-fs.service.xml \
man/systemd-resolved.service.xml \
+   man/systemd-res...@.service.xml \
man/systemd-rfk...@.service.xml \
man/systemd-run.xml \
man/systemd-shutdownd.service.xml \
diff --git a/Makefile.am b/Makefile.am
index e238cde..c4327ca 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -371,7 +371,8 @@ rootlibexec_PROGRAMS = \
systemd-sleep \
systemd-bus-proxyd \
systemd-socket-proxyd \
-   systemd-update-done
+   systemd-update-done \
+   systemd-resume
 
 systemgenerator_PROGRAMS = \
systemd-getty-generator \
@@ -509,7 +510,8 @@ nodist_systemunit_DATA = \
units/initrd-udevadm-cleanup-db.service \
units/initrd-switch-root.service \
units/systemd-nspawn@.service \
-   units/systemd-update-done.service
+   units/systemd-update-done.service \
+   units/systemd-resume@.service
 
 dist_userunit_DATA = \
units/user/basic.target \
@@ -556,7 +558,8 @@ EXTRA_DIST += \
units/initrd-udevadm-cleanup-db.service.in \
units/initrd-switch-root.service.in \
units/systemd-nsp...@.service.in \
-   units/systemd-update-done.service.in
+   units/systemd-update-done.service.in \
+   units/systemd-res...@.service.in
 
 CLEANFILES += \
units/console-shell.service.m4 \
@@ -1930,6 +1933,14 @@ systemd_delta_LDADD = \
libsystemd-shared.la
 
 # 
--
+systemd_resume_SOURCES = \
+   src/resume/resume.c
+
+systemd_resume_LDADD = \
+   libsystemd-internal.la \
+   libsystemd-shared.la
+
+# 
--
 systemd_getty_generator_SOURCES = \
src/getty-generator/getty-generator.c
 
diff --git a/man/systemd-res...@.service.xml b/man/systemd-res...@.service.xml
new file mode 100644
index 000..b7d28fb
--- /dev/null
+++ b/man/systemd-res...@.service.xml
@@ -0,0 +1,81 @@
+?xml version=1.0?
+!--*-nxml-*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+!--
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful

[systemd-devel] [RFC] [PATCHv3 1/3] units: order systemd-fsck@.service after local-fs-pre.target.

[Ivan Shapovalov]

With this change, it becomes possible to order a unit to activate before any
modifications to the file systems. This is especially useful for supporting
resume from hibernation.
---
 units/systemd-f...@.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/units/systemd-f...@.service.in b/units/systemd-f...@.service.in
index c12efa8..d2cda6a 100644
--- a/units/systemd-f...@.service.in
+++ b/units/systemd-f...@.service.in
@@ -10,7 +10,7 @@ Description=File System Check on %f
 Documentation=man:systemd-fsck@.service(8)
 DefaultDependencies=no
 BindsTo=%i.device
-After=systemd-readahead-collect.service systemd-readahead-replay.service 
%i.device systemd-fsck-root.service
+After=systemd-readahead-collect.service systemd-readahead-replay.service 
%i.device systemd-fsck-root.service local-fs-pre.target
 Before=shutdown.target
 
 [Service]
-- 
2.1.0

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

[systemd-devel] [RFC] [PATCHv3 0/3] resume: implement support for resuming from hibernation

[Ivan Shapovalov]

This patchset allows systemd to parse resume= kernel command line parameter
and initiate resume from the specified device.

It adds:
- a 'systemd-resume' tool which takes path to a device node and
  writes its major:minor to /sys/power/state;
- a corresponding 'systemd-resume@.service' templated unit;
- a 'systemd-resume-generator' generator which parses the kernel command line
  and instantiates the unit as necessary.

This functionality already exists in-kernel, but only for /dev/sdXY-style
pathes. Implementing it in userspace allows to use arbitrary udev-created
symlinks, e. g. persistent block device pathes (/dev/disk/by-foo/bar).

Userspace parsing of resume= kernel command line parameter has been
traditionally done in initramfs via shell scripts (for Arch Linux, this is
resume mkinitcpio hook), so I feel that this feature has its place within
systemd.

Due to the nature of hibernation, the resume unit must be activated before
any modifications to filesystems take place. This can happen only in initramfs
before mounting anything.

So, first patch orders all non-root fsck after local-fs-pre.target, which in
turn allows to order the resume unit before those fsck instances.

Second and third patches add the tool, the unit and the generator.

There are some issues with this implementation.

- legacy usr.mount is not automatically ordered after local-fs-pre.target,
  so systemd-resume@.service has to be manually ordered before it;
- systemd-udevd.service, which is needed for creating persistent block device
  symlinks, is transitively ordered after systemd-remount-fs.service via at
  least systemd-udev-hwdb-update.service and systemd-sysusers.service.
  Hence, if these units are present, an ordering cycle happens and resume is
  impossible.

Encountering these conditions is very unlikely inside of an initramfs (who
would make the in-initramfs /usr external? who would add systemd-sysusers
into initramfs?), but there can still be pathological cases.

So, I would like someone to comment on these issues.

Thanks for reviewing!

v2: fix issues pointed out by Andrei:
- don't RemainAfterExit because it's useless
- don't attempt to resume outside of initramfs because it's unsafe
  (reiserfs replays journal even if mounted RO)

v3: fix mistakes spotted by Thomas:
- return 0 in main path of resume.c:process_resume()
- fix type and add missing cleanup attribute in resume-generator.c:main()

Ivan Shapovalov (3):
  units: order systemd-fsck@.service after local-fs-pre.target.
  resume: add a tool to write a device node's major:minor to /sys/power/resume.
  resume-generator: add a generator for instantiating the resume unit.

 Makefile-man.am |  9 
 Makefile.am | 28 --
 man/kernel-command-line.xml | 13 -
 man/systemd-resume-generator.xml| 91 +++
 man/systemd-res...@.service.xml | 81 
 src/resume-generator/Makefile   |  1 +
 src/resume-generator/resume-generator.c | 95 +
 src/resume/Makefile |  1 +
 src/resume/resume.c | 83 
 units/systemd-f...@.service.in  |  2 +-
 units/systemd-res...@.service.in| 20 +++
 11 files changed, 418 insertions(+), 6 deletions(-)
 create mode 100644 man/systemd-resume-generator.xml
 create mode 100644 man/systemd-res...@.service.xml
 create mode 12 src/resume-generator/Makefile
 create mode 100644 src/resume-generator/resume-generator.c
 create mode 12 src/resume/Makefile
 create mode 100644 src/resume/resume.c
 create mode 100644 units/systemd-res...@.service.in

-- 
2.1.0

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

[systemd-devel] [RFC] [PATCHv3 3/3] resume-generator: add a generator for instantiating the resume unit.

[Ivan Shapovalov]

resume-generator understands resume= kernel command line parameter and
instantiates the systemd-resume@.service accordingly if it is passed.

This enables resume from hibernation using device specified on the kernel
command line, where the device path may point to an arbitrary udev-created
symlink, not only /dev/sdXY which is understood by the in-kernel
implementation.
---
 Makefile-man.am |  2 +
 Makefile.am | 11 +++-
 man/kernel-command-line.xml | 13 -
 man/systemd-resume-generator.xml| 91 +++
 src/resume-generator/Makefile   |  1 +
 src/resume-generator/resume-generator.c | 95 +
 6 files changed, 211 insertions(+), 2 deletions(-)
 create mode 100644 man/systemd-resume-generator.xml
 create mode 12 src/resume-generator/Makefile
 create mode 100644 src/resume-generator/resume-generator.c

diff --git a/Makefile-man.am b/Makefile-man.am
index be19905..00daae2 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -76,6 +76,7 @@ MANPAGES += \
man/systemd-nspawn.1 \
man/systemd-path.1 \
man/systemd-remount-fs.service.8 \
+   man/systemd-resume-generator.8 \
man/systemd-resume@.service.8 \
man/systemd-run.1 \
man/systemd-shutdownd.service.8 \
@@ -1632,6 +1633,7 @@ EXTRA_DIST += \
man/systemd-readahead-replay.service.xml \
man/systemd-remount-fs.service.xml \
man/systemd-resolved.service.xml \
+   man/systemd-resume-generator.xml \
man/systemd-res...@.service.xml \
man/systemd-rfk...@.service.xml \
man/systemd-run.xml \
diff --git a/Makefile.am b/Makefile.am
index c4327ca..820d082 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -378,7 +378,8 @@ systemgenerator_PROGRAMS = \
systemd-getty-generator \
systemd-fstab-generator \
systemd-system-update-generator \
-   systemd-debug-generator
+   systemd-debug-generator \
+   systemd-resume-generator
 
 dist_bashcompletion_DATA = \
shell-completion/bash/busctl \
@@ -1973,6 +1974,14 @@ systemd_system_update_generator_LDADD = \
libsystemd-label.la \
libsystemd-shared.la
 
+# 
--
+systemd_resume_generator_SOURCES = \
+   src/resume-generator/resume-generator.c
+
+systemd_resume_generator_LDADD = \
+   libsystemd-label.la \
+   libsystemd-shared.la
+
 if ENABLE_EFI
 # 
--
 systemgenerator_PROGRAMS +=  \
diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index f244bfc..4bc6cee 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -351,6 +351,16 @@
 /listitem
 /varlistentry
 
+varlistentry
+termvarnameresume=/varname/term
+
+listitem
+paraEnables resume from hibernation
+using the specified device. For
+details, see
+
citerefentryrefentrytitlesystemd-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry./para
+/listitem
+/varlistentry
 /variablelist
 
 /refsect1
@@ -373,7 +383,8 @@
   
citerefentryrefentrytitlesystemd-gpt-auto-generator/refentrytitlemanvolnum8/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd-modules-load.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd-backlight@.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
-  
citerefentryrefentrytitlesystemd-rfkill@.service/refentrytitlemanvolnum8/manvolnum/citerefentry
+  
citerefentryrefentrytitlesystemd-rfkill@.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
+  
citerefentryrefentrytitlesystemd-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry
   /para
 /refsect1
 
diff --git a/man/systemd-resume-generator.xml b/man/systemd-resume-generator.xml
new file mode 100644
index 000..7962534
--- /dev/null
+++ b/man/systemd-resume-generator.xml
@@ -0,0 +1,91 @@
+?xml version=1.0?
+!--*-nxml-*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+!--
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1

Re: [systemd-devel] [RFC] [PATCHv3 0/3] resume: implement support for resuming from hibernation

[Ivan Shapovalov]

On Monday 25 August 2014 at 19:42:21, Lennart Poettering wrote: 
 On Mon, 25.08.14 02:16, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  This patchset allows systemd to parse resume= kernel command line parameter
  and initiate resume from the specified device.
  
  It adds:
  - a 'systemd-resume' tool which takes path to a device node and
writes its major:minor to /sys/power/state;
  - a corresponding 'systemd-resume@.service' templated unit;
  - a 'systemd-resume-generator' generator which parses the kernel command 
  line
and instantiates the unit as necessary.
  
  This functionality already exists in-kernel, but only for /dev/sdXY-style
  pathes. Implementing it in userspace allows to use arbitrary udev-created
  symlinks, e. g. persistent block device pathes (/dev/disk/by-foo/bar).
  
  Userspace parsing of resume= kernel command line parameter has been
  traditionally done in initramfs via shell scripts (for Arch Linux, this is
  resume mkinitcpio hook), so I feel that this feature has its place within
  systemd.
  
  Due to the nature of hibernation, the resume unit must be activated before
  any modifications to filesystems take place. This can happen only in 
  initramfs
  before mounting anything.
  
  So, first patch orders all non-root fsck after local-fs-pre.target, which in
  turn allows to order the resume unit before those fsck instances.
  
  Second and third patches add the tool, the unit and the generator.
  
  There are some issues with this implementation.
  
  - legacy usr.mount is not automatically ordered after local-fs-pre.target,
so systemd-resume@.service has to be manually ordered before it;
 
 Not following here. We do not really support /usr split out unless it is
 already mounted in the initrd. But in the initrd its called
 sysroot-usr.mount... To me this doesn't look like something to do here?

Theoretically it is possible to have initramfs's /usr split out.
I know that it sounds crazy, but if someone will do this, they will lose their
data if usr.mount not properly handled.

 
  - systemd-udevd.service, which is needed for creating persistent block 
  device
symlinks, is transitively ordered after systemd-remount-fs.service via at
least systemd-udev-hwdb-update.service and systemd-sysusers.service.
Hence, if these units are present, an ordering cycle happens and resume is
impossible.
 
 Hmm? What's the cycle precisely? Not following?

systemd-remount.fs.service - systemd-udev-hwdb-update.service - 
systemd-udevd.service
 systemd-sysusers.service

Here, the arrow represents an After= dependency.

If either systemd-udev-hwdb-update.service or systemd-sysusers.service
becomes part of the transaction (== becomes included in the initramfs),
it becomes impossible for systemd-resume@.service to start after
systemd-udevd.service. The outcome can vary:

- a 90 second wait for dev-disk-by\x2dfoo-bar.device and dependency failure
  (if After=systemd-udevd.service has not been specified);
- an ordering cycle and removal of systemd-resume@.service from transaction
  (if After=systemd-udevd.service has been specified, just as it is now).

Both situations are very unlikely (who would add usr.mount to initramfs? who
would add systemd-sysusers.service to initramfs?), but nevertheless possible.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] [PATCHv3 2/3] resume: add a tool to write a device node's major:minor to /sys/power/resume.

[Ivan Shapovalov]

On Monday 25 August 2014 at 19:49:52, Lennart Poettering wrote: 
 On Mon, 25.08.14 02:16, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  +int main(int argc, char *argv[]) {
  +struct stat st;
  +const char *device;
  +_cleanup_free_ char *major_minor = NULL;
  +int r;
  +
  +if (argc != 2) {
  +log_error(This program expects one argument.);
  +return EXIT_FAILURE;
  +}
  +
  +log_set_target(LOG_TARGET_AUTO);
  +log_parse_environment();
  +log_open();
  +
  +umask(0022);
  +
  +device = argv[1];
  +
  +if (stat(device, st)  0) {
  +log_error(Failed to stat '%s': %m, device);
  +return EXIT_FAILURE;
  +}
  +
  +if (!S_ISBLK(st.st_mode)) {
  +log_error(Resume device '%s' is not a block device., 
  device);
  +return EXIT_FAILURE;
  +}
  +
  +if (asprintf(major_minor, %d:%d, major(st.st_rdev), 
  minor(st.st_rdev))  0) {
  +log_oom();
  +return EXIT_FAILURE;
  +}
  +
  +r = write_string_file(/sys/power/resume, major_minor);
  +if (r  0) {
  +log_error(Failed to write '%s' to /sys/power/resume: %s,
  +  major_minor, strerror(-r));
  +return EXIT_FAILURE;
 
 So, we explicitly do not break lines at 80ch... Nobody has such tiny
 screens anymore. This doesn't really matter, but I 'd prefer if you
 didn't break lines that aggressively. I mean, don't overdo it with
 super long lines either, but 140ch or so should be OK.
 
 (this is just nitpicking, and not a necessity to fix before I merge it...)

That's because I've seen 80-wrapped lines in couple of other places.
Fixed for v4.

 
  +}
  +
  +/*
  + * The write above shall not return.
  + *
  + * However, failed resume is a normal condition (may mean that 
  there is
  + * no hibernation image).
  + */
  +
  +log_notice(Failed to resume from device '%s' (%s).,
  +   device, major_minor);
 
 same here..

Fixed as well.

 
 Hmm, what's the logic here? Is this something where we should halt the
 machine? How fatal shall we consider this error?

 
  +return EXIT_SUCCESS;
 
 ... especially, since you return success here...
 
 I am just wondering whether log_notice() + EXIT_SUCCESS is the right
 reaction here. Or maybe log_error() + freeze()? or maybe log_warning() +
 EXIT_FAILURE?... Dunno. Just want to hear some rationale here... 

This is absolutely not fatal, and arguably not an error condition at all.

If a machine is simply rebooted, without hibernation image in place (but with
resume= kernel parameter), this code path will be hit.

We could return EXIT_FAILURE with something like no image == failure to resume
in mind, but this does not really worth attention as an error.

(Reaction to other errors handled in this file can be subject to discussion.

Errors like wrong parameter, device not found are essentially programmatic,
because the unit has correct dependencies in place.

Failing to write to /sys/power/resume can indicate that the resume has been
unsuccessful: corrupted image, filesystem mount timestamps are post hibernation,
and so on. I have not really triggered failure conditions so I don't know
whether a write error is really returned in this case. But if I were
kernel-space, I'd do it this way.)

 
  +}
  diff --git a/units/systemd-res...@.service.in 
  b/units/systemd-res...@.service.in
  new file mode 100644
  index 000..c6aa0d2
  --- /dev/null
  +++ b/units/systemd-res...@.service.in
  @@ -0,0 +1,20 @@
  +#  This file is part of systemd.
  +#
  +#  systemd is free software; you can redistribute it and/or modify it
  +#  under the terms of the GNU Lesser General Public License as published by
  +#  the Free Software Foundation; either version 2.1 of the License, or
  +#  (at your option) any later version.
  +
  +[Unit]
  +Description=Resume from hibernation using device %f
  +Documentation=man:systemd-resume@.service(8)
  +DefaultDependencies=no
  +BindsTo=%i.device
  +Wants=local-fs-pre.target
  +After=%i.device systemd-udevd.service
 
 Ordering after systemd-udevd.service sounds unnecessary? I mean, no
 devices will show up before udevd, but there's no need to do anything
 about this.
 
  +Before=local-fs-pre.target systemd-remount-fs.service
  systemd-fsck-root.service usr.mount
 
 The usr.mount should really not be listed.
 
  +ConditionPathExists=/etc/initrd-release
  +
  +[Service]
  +Type=oneshot
  +ExecStart=@rootlibexecdir@/systemd-resume %f
 
 Looks great otherwise!
 
 Lennart
 
 

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] [PATCHv3 0/3] resume: implement support for resuming from hibernation

[Ivan Shapovalov]

On Monday 25 August 2014 at 20:07:28, Lennart Poettering wrote: 
 On Mon, 25.08.14 21:52, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
- legacy usr.mount is not automatically ordered after 
local-fs-pre.target,
  so systemd-resume@.service has to be manually ordered before it;
   
   Not following here. We do not really support /usr split out unless it is
   already mounted in the initrd. But in the initrd its called
   sysroot-usr.mount... To me this doesn't look like something to do here?
  
  Theoretically it is possible to have initramfs's /usr split out.
  I know that it sounds crazy, but if someone will do this, they will lose 
  their
  data if usr.mount not properly handled.
 
 initrd cannot have their data split out. I am completely happy about
 breaking this, should it exist (which I doubt).

OK. Removed Before=usr.mount for v4.

 
  If either systemd-udev-hwdb-update.service or systemd-sysusers.service
  becomes part of the transaction (== becomes included in the initramfs),
  it becomes impossible for systemd-resume@.service to start after
  systemd-udevd.service. The outcome can vary:
  
  - a 90 second wait for dev-disk-by\x2dfoo-bar.device and dependency failure
(if After=systemd-udevd.service has not been specified);
 
  - an ordering cycle and removal of systemd-resume@.service from 
  transaction
(if After=systemd-udevd.service has been specified, just as it is now).
  
  Both situations are very unlikely (who would add usr.mount to initramfs? who
  would add systemd-sysusers.service to initramfs?), but nevertheless 
  possible.
 
 Hmm, let me see, so you are basically saying that udev wants to run
 after sysusers, and sysusers shall run after the file systems are
 mounted, and that systemd-resume@.service wants to run before that, but
 needs to wait until the devices have popped up, which they won't until
 udev is started?

Yes, I've meant exactly this.

 
 So, I am pretty sure we don#t want an explicit After= order here between
 dbus and systemd-resume@.service...
 
 Hmm, but yuck, I don't see a nice way to fix this for good. Grrr.
 
 I'd probably just merge this as is, and let people who are crazy enough
 to run sysuers or hwdb-update in the initrd, to figure this out. Let's
 just wait until this pops up...
 
 Lennart

So, do you want me to leave After=systemd-udevd.service or remove it?
(An ordering cycle or a waiting timeout?)

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] [PATCHv3 3/3] resume-generator: add a generator for instantiating the resume unit.

[Ivan Shapovalov]

On Monday 25 August 2014 at 19:58:52, Lennart Poettering wrote: 
 [...]
 
 One more question though, regarding the terminology. So far we used the
 following terms:
 
 suspend → means suspend-to-ram
 hibernate → means suspend-to-disk
 hybrid-sleep → means both STR + STD combined
 sleep → a generic term for all of the above.
 
 Now, I do wonder how we should call the operation when we come back from
 the sleep states.
 
 To me resume would probably most clearly be the reverse of suspend,
 but you actually are looking for the reverse of hibernate here. 
 
 The reverse of sleep would be wake I figure...
 
 On the kernel side the terminology for all of this is completely
 random. Especially given that the input layer names some keys with the
 precise opposite of what the PM layer calls the operations... But we
 really should try to clean this up a bit when exposing this in
 userspace...
 
 So, dunno, what's the antonym of hibernate? SOmething like thaw
 maybe? Any native english speakers with ideas?
 
 Lennart

I've called it resume just because the kernel command line parameter
is named resume=, kernel messages use the term resume, the arch initramfs
hook is also named resume and so on... This may be inconsistent globally,
but the opposite of hibernation is called resume pretty much everywhere.

However, suggestions welcome.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Current status wrt. realtime services (aka jackd)

[Ivan Shapovalov]

Hello all,

is there some replacement of the ControlGroupAttribute=cpu.rt_runtime_us 
somevalue
tunable described at 
http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/
for allowing services like `jackd -R` to run?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCHv4 2/3] resume: add a tool to write a device node's major:minor to /sys/power/resume.

[Ivan Shapovalov]

This can be used to initiate a resume from hibernation by path to a swap
device containing the hibernation image.

The respective templated unit is also added. It is instantiated using
path to the desired resume device.
---
 Makefile-man.am  |  7 
 Makefile.am  | 17 +++--
 man/systemd-res...@.service.xml  | 81 
 src/resume/Makefile  |  1 +
 src/resume/resume.c  | 81 
 units/systemd-res...@.service.in | 20 ++
 6 files changed, 204 insertions(+), 3 deletions(-)
 create mode 100644 man/systemd-res...@.service.xml
 create mode 12 src/resume/Makefile
 create mode 100644 src/resume/resume.c
 create mode 100644 units/systemd-res...@.service.in

diff --git a/Makefile-man.am b/Makefile-man.am
index 5c289dd..be19905 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -76,6 +76,7 @@ MANPAGES += \
man/systemd-nspawn.1 \
man/systemd-path.1 \
man/systemd-remount-fs.service.8 \
+   man/systemd-resume@.service.8 \
man/systemd-run.1 \
man/systemd-shutdownd.service.8 \
man/systemd-sleep.conf.5 \
@@ -206,6 +207,7 @@ MANPAGES_ALIAS += \
man/systemd-poweroff.service.8 \
man/systemd-reboot.service.8 \
man/systemd-remount-fs.8 \
+   man/systemd-resume.8 \
man/systemd-shutdown.8 \
man/systemd-shutdownd.8 \
man/systemd-shutdownd.socket.8 \
@@ -311,6 +313,7 @@ man/systemd-kexec.service.8: man/systemd-halt.service.8
 man/systemd-poweroff.service.8: man/systemd-halt.service.8
 man/systemd-reboot.service.8: man/systemd-halt.service.8
 man/systemd-remount-fs.8: man/systemd-remount-fs.service.8
+man/systemd-resume.8: man/systemd-resume@.service.8
 man/systemd-shutdown.8: man/systemd-halt.service.8
 man/systemd-shutdownd.8: man/systemd-shutdownd.service.8
 man/systemd-shutdownd.socket.8: man/systemd-shutdownd.service.8
@@ -592,6 +595,9 @@ man/systemd-reboot.service.html: 
man/systemd-halt.service.html
 man/systemd-remount-fs.html: man/systemd-remount-fs.service.html
$(html-alias)
 
+man/systemd-resume.html: man/systemd-res...@.service.html
+   $(html-alias)
+
 man/systemd-shutdown.html: man/systemd-halt.service.html
$(html-alias)
 
@@ -1626,6 +1632,7 @@ EXTRA_DIST += \
man/systemd-readahead-replay.service.xml \
man/systemd-remount-fs.service.xml \
man/systemd-resolved.service.xml \
+   man/systemd-res...@.service.xml \
man/systemd-rfk...@.service.xml \
man/systemd-run.xml \
man/systemd-shutdownd.service.xml \
diff --git a/Makefile.am b/Makefile.am
index e238cde..c4327ca 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -371,7 +371,8 @@ rootlibexec_PROGRAMS = \
systemd-sleep \
systemd-bus-proxyd \
systemd-socket-proxyd \
-   systemd-update-done
+   systemd-update-done \
+   systemd-resume
 
 systemgenerator_PROGRAMS = \
systemd-getty-generator \
@@ -509,7 +510,8 @@ nodist_systemunit_DATA = \
units/initrd-udevadm-cleanup-db.service \
units/initrd-switch-root.service \
units/systemd-nspawn@.service \
-   units/systemd-update-done.service
+   units/systemd-update-done.service \
+   units/systemd-resume@.service
 
 dist_userunit_DATA = \
units/user/basic.target \
@@ -556,7 +558,8 @@ EXTRA_DIST += \
units/initrd-udevadm-cleanup-db.service.in \
units/initrd-switch-root.service.in \
units/systemd-nsp...@.service.in \
-   units/systemd-update-done.service.in
+   units/systemd-update-done.service.in \
+   units/systemd-res...@.service.in
 
 CLEANFILES += \
units/console-shell.service.m4 \
@@ -1930,6 +1933,14 @@ systemd_delta_LDADD = \
libsystemd-shared.la
 
 # 
--
+systemd_resume_SOURCES = \
+   src/resume/resume.c
+
+systemd_resume_LDADD = \
+   libsystemd-internal.la \
+   libsystemd-shared.la
+
+# 
--
 systemd_getty_generator_SOURCES = \
src/getty-generator/getty-generator.c
 
diff --git a/man/systemd-res...@.service.xml b/man/systemd-res...@.service.xml
new file mode 100644
index 000..b7d28fb
--- /dev/null
+++ b/man/systemd-res...@.service.xml
@@ -0,0 +1,81 @@
+?xml version=1.0?
+!--*-nxml-*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+!--
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful

[systemd-devel] [PATCHv4 3/3] resume-generator: add a generator for instantiating the resume unit.

[Ivan Shapovalov]

resume-generator understands resume= kernel command line parameter and
instantiates the systemd-resume@.service accordingly if it is passed.

This enables resume from hibernation using device specified on the kernel
command line, where the device path may point to an arbitrary udev-created
symlink, not only /dev/sdXY which is understood by the in-kernel
implementation.
---
 Makefile-man.am |  2 +
 Makefile.am | 11 +++-
 man/kernel-command-line.xml | 13 -
 man/systemd-resume-generator.xml| 91 +++
 src/resume-generator/Makefile   |  1 +
 src/resume-generator/resume-generator.c | 95 +
 6 files changed, 211 insertions(+), 2 deletions(-)
 create mode 100644 man/systemd-resume-generator.xml
 create mode 12 src/resume-generator/Makefile
 create mode 100644 src/resume-generator/resume-generator.c

diff --git a/Makefile-man.am b/Makefile-man.am
index be19905..00daae2 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -76,6 +76,7 @@ MANPAGES += \
man/systemd-nspawn.1 \
man/systemd-path.1 \
man/systemd-remount-fs.service.8 \
+   man/systemd-resume-generator.8 \
man/systemd-resume@.service.8 \
man/systemd-run.1 \
man/systemd-shutdownd.service.8 \
@@ -1632,6 +1633,7 @@ EXTRA_DIST += \
man/systemd-readahead-replay.service.xml \
man/systemd-remount-fs.service.xml \
man/systemd-resolved.service.xml \
+   man/systemd-resume-generator.xml \
man/systemd-res...@.service.xml \
man/systemd-rfk...@.service.xml \
man/systemd-run.xml \
diff --git a/Makefile.am b/Makefile.am
index c4327ca..820d082 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -378,7 +378,8 @@ systemgenerator_PROGRAMS = \
systemd-getty-generator \
systemd-fstab-generator \
systemd-system-update-generator \
-   systemd-debug-generator
+   systemd-debug-generator \
+   systemd-resume-generator
 
 dist_bashcompletion_DATA = \
shell-completion/bash/busctl \
@@ -1973,6 +1974,14 @@ systemd_system_update_generator_LDADD = \
libsystemd-label.la \
libsystemd-shared.la
 
+# 
--
+systemd_resume_generator_SOURCES = \
+   src/resume-generator/resume-generator.c
+
+systemd_resume_generator_LDADD = \
+   libsystemd-label.la \
+   libsystemd-shared.la
+
 if ENABLE_EFI
 # 
--
 systemgenerator_PROGRAMS +=  \
diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index f244bfc..4bc6cee 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -351,6 +351,16 @@
 /listitem
 /varlistentry
 
+varlistentry
+termvarnameresume=/varname/term
+
+listitem
+paraEnables resume from hibernation
+using the specified device. For
+details, see
+
citerefentryrefentrytitlesystemd-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry./para
+/listitem
+/varlistentry
 /variablelist
 
 /refsect1
@@ -373,7 +383,8 @@
   
citerefentryrefentrytitlesystemd-gpt-auto-generator/refentrytitlemanvolnum8/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd-modules-load.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd-backlight@.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
-  
citerefentryrefentrytitlesystemd-rfkill@.service/refentrytitlemanvolnum8/manvolnum/citerefentry
+  
citerefentryrefentrytitlesystemd-rfkill@.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
+  
citerefentryrefentrytitlesystemd-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry
   /para
 /refsect1
 
diff --git a/man/systemd-resume-generator.xml b/man/systemd-resume-generator.xml
new file mode 100644
index 000..7962534
--- /dev/null
+++ b/man/systemd-resume-generator.xml
@@ -0,0 +1,91 @@
+?xml version=1.0?
+!--*-nxml-*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+!--
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1

Re: [systemd-devel] [PATCHv4 3/3] resume-generator: add a generator for instantiating the resume unit.

[Ivan Shapovalov]

On Tuesday 26 August 2014 at 09:18:30, Dave Reisner wrote:  
 On Tue, Aug 26, 2014 at 04:11:05PM +0400, Ivan Shapovalov wrote:
  resume-generator understands resume= kernel command line parameter and
  instantiates the systemd-resume@.service accordingly if it is passed.
  
  This enables resume from hibernation using device specified on the kernel
  command line, where the device path may point to an arbitrary udev-created
  symlink, not only /dev/sdXY which is understood by the in-kernel
  implementation.
  ---
 
 ...
 
  diff --git a/src/resume-generator/resume-generator.c 
  b/src/resume-generator/resume-generator.c
  new file mode 100644
  index 000..38179ff
  --- /dev/null
  +++ b/src/resume-generator/resume-generator.c
  @@ -0,0 +1,95 @@
 
 ...
 
  +
  +static int parse_proc_cmdline_item(const char *key, const char *value) {
  +if (streq(key, resume)  value) {
  +free(arg_resume_dev);
  +arg_resume_dev = strdup(value);
 
 Shouldn't this be fstab_node_to_udev_node() so that we can support
 things like resume=LABEL=myawesomedevice ?
 
 d

Yeah, indeed, makes sense. Didn't know there was a special function
for that. Done for v5.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [206] Using `systemd --user` to manage user's session -- is it still possible?

[Ivan Shapovalov]

Hello!

With systemd v204 and earlier, I used `systemd --user` to manage my complete 
session, including X server (via xorg-launch-helper) and all related things.

I used a slightly modified user-session@.service unit to start the
`systemd --user` instance in its own session to get PolicyKit working:

[Service]
PAMName=login
TTYPath=/dev/tty7 # Xorg has been configured to start on vt7

That is pretty hackish (especially the hardcoded tty) but it worked: I was 
getting an active tty session in an autologin style; the session leader was 
systemd.

With v206, that stopped working. It seems that `systemd --user` now must be 
launched
1) with PAMName=systemd-shared
2) by logind on a per-user basis
   (IOW, `systemctl start user@1000.service` does not work)

...to have it started (otherwise, `systemd --user` does not start), and

3) with /etc/pam.d/systemd-shared symlinked to system-login or whatever
   (see https://bugs.freedesktop.org/show_bug.cgi?id=68164)

...to have XDG_RUNTIME_DIR=/run/user/%U instead of /run.

With that done, systemd starts successfully, but does not get linked to any 
session (so PolicyKit does not work, audio does not work, etc).

Is it somehow possible with v206 to continue using `systemd --user` as a 
session manager?

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

Re: [systemd-devel] [206] Using `systemd --user` to manage user's session -- is it still possible?

[Ivan Shapovalov]

On Wednesday 28 August 2013 at 16:07:23, Mantas wrote:
 Partial reply:
 
 On Wed, Aug 28, 2013 at 10:15 AM, Ivan Shapovalov intelfx...@gmail.com 
wrote:
  With v206, that stopped working. It seems that `systemd --user` now must 
be
  launched
  1) with PAMName=systemd-shared
  […]
  3) with /etc/pam.d/systemd-shared symlinked to system-login or whatever
 (see https://bugs.freedesktop.org/show_bug.cgi?id=68164)
 
  ...to have XDG_RUNTIME_DIR=/run/user/%U instead of /run.
 
 The only requirement here is that PAM must call pam_systemd.so to set
 up cgroups and XDG_RUNTIME_DIR. It's nothing new to v205/v206.

Seems like it is a distro problem (not having /etc/pam.d/systemd-shared). 
Anybody using Arch, do you have that file?

 
  2) by logind on a per-user basis
 (IOW, `systemctl start user@1000.service` does not work)
 
 It /should/ work, because that's exactly how logind starts it.
 
 

Yes, I see from source... but it doesn't work. Somewhy.

So, does anybody have some hints on this (I mean, the whole question)?

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

[systemd-devel] Make X11 logind session unconditionally active

[Ivan Shapovalov]

Hello!

I'm still trying to make my friendship with logind.

I have a headless server with Xvnc server running on it. Under the server
a logind session is created by the DM.
The session has Type=x11, but VTNr=0 since Xvnc does not bind itself to any 
VT.
Hence the session is always Active=no (there is no VT I can switch to).

So the question is: it is possible to mark a session as always active
or something like that?

Thanks,

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

Re: [systemd-devel] Make X11 logind session unconditionally active

[Ivan Shapovalov]

On Tuesday 05 November 2013 at 03:41:01, Lennart wrote:
 On Tue, 05.11.13 00:51, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  Hello!
  
  I'm still trying to make my friendship with logind.
  
  I have a headless server with Xvnc server running on it. Under the server
  a logind session is created by the DM.
  The session has Type=x11, but VTNr=0 since Xvnc does not bind itself to any 
  VT.
  Hence the session is always Active=no (there is no VT I can switch
  to).
 
 Nah, that's not how this really should work.
 
 Basically, there are sessions which are assigned to seats and sessions
 which aren't. Seats in this case means local, physical seats. Sessions
 without seats are unconditionally active. Only sessions with seats can
 be inactive. Since an xvnc session is not a local one it should not have
 a seat, and hecnce should alway be active.

 
  So the question is: it is possible to mark a session as always active
  or something like that?
 
 Well, that should be the case implicitly if the session is properly
 registered. What does loginctl show-session print for this session?
 
 Lennart
 
 

Yes, I had the session bound to seat0.
Configuring lightdm to use an empty seat made the session Active=yes.

$ loginctl show-session c37
Id=c37
Timestamp=Вт 2013-11-05 12:22:13 MSK
TimestampMonotonic=59464298414
VTNr=0
Display=localhost:10
Remote=no
Service=lightdm
Scope=session-c37.scope
Leader=25926
Audit=0
Type=x11
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
Name=intelfx

However, this still isn't exactly what I want. Now the session has no seat, so
1. udisks does not allow me to mount removables without authentication;
2. I suppose the dynamic device node permission stuff won't work for me either.

So I want that session to be equivalent to a local one in terms of permissions 
etc...
Is it somehow possible?

Thanks,

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

Re: [systemd-devel] Make X11 logind session unconditionally active

[Ivan Shapovalov]

On Tuesday 05 November 2013 at 11:15:30, Lennart wrote:
 On Tue, 05.11.13 12:37, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
So the question is: it is possible to mark a session as always 
active
or something like that?
   
   Well, that should be the case implicitly if the session is properly
   registered. What does loginctl show-session print for this session?
   
   Lennart
   
   
  
  Yes, I had the session bound to seat0.
  Configuring lightdm to use an empty seat made the session Active=yes.
  
  $ loginctl show-session c37
  Id=c37
  Timestamp=Вт 2013-11-05 12:22:13 MSK
  TimestampMonotonic=59464298414
  VTNr=0
  Display=localhost:10
  Remote=no
  Service=lightdm
  Scope=session-c37.scope
  Leader=25926
  Audit=0
  Type=x11
  Class=user
  Active=yes
  State=active
  IdleHint=no
  IdleSinceHint=0
  IdleSinceHintMonotonic=0
  Name=intelfx
  
  However, this still isn't exactly what I want. Now the session has no 
seat, so
  1. udisks does not allow me to mount removables without authentication;
  2. I suppose the dynamic device node permission stuff won't work for me 
either.
  
  So I want that session to be equivalent to a local one in terms of 
permissions etc...
  Is it somehow possible?
 
 So you want something like a hybrid session, i.e. one that is virtual
 but has access to local devices? That's a special setup that is not
 supported by logind itself. However note that you can express any
 policies you like with polkit, hence you can configure it to grant
 access to the devices to your user even if he is not logged into a
 physical session. But that's something you have to do unrelated to
 logind.
 
 Lennart
 

Yes, I want something like that...
Is it not supported _yet_ or _by design_? I suspect it is a valuable thing to 
have.

Sure, I can try to configure polkit, but will that grant me permissions on 
device nodes (e. g. printers)?

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

Re: [systemd-devel] Make X11 logind session unconditionally active

[Ivan Shapovalov]

On Tuesday 05 November 2013 at 11:33:31, Lennart wrote:
 On Tue, 05.11.13 14:24, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
   So you want something like a hybrid session, i.e. one that is virtual
   but has access to local devices? That's a special setup that is not
   supported by logind itself. However note that you can express any
   policies you like with polkit, hence you can configure it to grant
   access to the devices to your user even if he is not logged into a
   physical session. But that's something you have to do unrelated to
   logind.
   
   Lennart
   
  
  Yes, I want something like that...
  Is it not supported _yet_ or _by design_? I suspect it is a valuable thing 
to 
  have.
 
 By design I guess. The automatic stuff is for the common case. I doubt
 that such a hybrid session is really such a common case, especially
 since it creates a ton of problems when you mix it with normal physical
 sessions on seat0.
 
  Sure, I can try to configure polkit, but will that grant me permissions on 
  device nodes (e. g. printers)?
 
 Printers are a system resource, they are not reassigned to user
 sessions, they are expected to be written to only by system services
 like CUPS.
 
 Lennart
 
 

...or sound devices. After all, I'm asking about the generic case :)

(Actually, when using things like HPLIP, permissions on usb nodes start to 
matter.)

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

Re: [systemd-devel] [PATCHv2] login: Don't stop a running user manager from garbage-collecting the user.

[Ivan Shapovalov]

On Wednesday 18 December 2013 at 11:03:05, Tom wrote:
 On Sun, Dec 15, 2013 at 12:06 PM, Thomas Bächler tho...@archlinux.org wrote:
  With the current logic, a user will never be garbage-collected, since its
  manager will always be around. Change the logic such that a user is
  garbage-collected when it has no sessions and linger is disabled.
  ---
  
   src/login/logind-user.c | 6 --
   1 file changed, 6 deletions(-)
  
  diff --git a/src/login/logind-user.c b/src/login/logind-user.c
  index 6ba8d98..441e086 100644
  --- a/src/login/logind-user.c
  +++ b/src/login/logind-user.c
  @@ -618,12 +618,6 @@ bool user_check_gc(User *u, bool drop_not_started) {
  
   if (u-service_job  manager_job_is_active(u-manager,
   u-service_job))
   
   return true;
  
  -if (u-slice  manager_unit_is_active(u-manager, u-slice) !=  0)
  -return true;
  -
  -if (u-service  manager_unit_is_active(u-manager, u-service) 
  != 0)
  -return true;
  -
  
   return false;
   
   }
  
  --
 
 Applied.
 
 Cheers,
 
 Tom
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

It seems that this patch has been applied to Arch's systemd-208-3, but it did 
not fix
the issue for me. I'm still getting the timeout:

Dec 23 17:26:42 intelfx-laptop systemd[1]: user@1000.service stopping timed 
out. Killing.

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

Re: [systemd-devel] Allow stop jobs to be killed during shutdown

[Ivan Shapovalov]

On Friday 24 January 2014 at 16:15:04, Lennart wrote:
 On Fri, 24.01.14 16:09, Reindl Harald (h.rei...@thelounge.net) wrote:
  Am 24.01.2014 16:03, schrieb Lennart Poettering:
   It is our job to shutdown all services cleanly. A number of services
   needs this, since they need to bring their files into a safe state
   before quitting, and mark them as offline. We cannot just drop that.
   
   Note however, that we add have timeouts on all service shutdown
   commands, so when some service hangs it will be forcibly aborted with
   SIGKILL after 90s.
   
   That all said, you can just shutdown with systemctl poweroff -f
   instead of normal systemctl poweroff. This will still bring the file
   systems in order and things, but wil not bother with shutting down
   system services cleanly, but simply SIGTERM and SIGKILL them after a
   much shorter timeout.
   
   However, something like that can never be the default, we need to give
   services the chance to shut down cleanly and in the right order
  
  then bugs like https://bugzilla.redhat.com/show_bug.cgi?id=1023820
 
 I have so far never encountered this issue, but I fear this is a bug
 where somebody who can reproduce this needs to sit down and debug a
 bit...
 
 Lennart

Any advices on how to do that?
I have both the issue (reproducible on each shutdown) and will to debug.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-208: auto-stopping of user@.service on last session exit

[Ivan Shapovalov]

Hello!

Is it intentional that even with KillUserProcesses=no,
user@.service is stopped as soon as the last user's session ends?

And, in any case, is it possible to avoid that?

To avoid XY problem: I'm trying to run a global per-user tmux server
inside the systemd user instance.

Thanks,

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-208: auto-stopping of user@.service on last session exit

[Ivan Shapovalov]

On Thursday 30 January 2014 at 17:36:29, Lennart wrote:
 On Thu, 30.01.14 20:23, Ivan Shapovalov (intelfx...@gmail.com) wrote:
  Hello!
  
  Is it intentional that even with KillUserProcesses=no,
  user@.service is stopped as soon as the last user's session ends?
  
  And, in any case, is it possible to avoid that?
  
  To avoid XY problem: I'm trying to run a global per-user tmux server
  inside the systemd user instance.
 
 loginctl enable-linger USER...
 
 
 Lennart

Wow.
Sorry for not reading the loginctl(1).

Thanks again.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running systemd --user and creating a new session

[Ivan Shapovalov]

On 08 June 2013 02:41:56 Ivan Shapovalov wrote:
 On 07 June 2013 12:47:28 Kok, Auke-jan H wrote:
  On Fri, Jun 7, 2013 at 3:18 AM, Иван Шаповалов intelfx...@gmail.com 
wrote:
   Hi all,
   
   Recently I've attempted to switch my user session to systemd --user.
   The
   configuration is pretty simple - no multiseat, nothing special.
   I start the user session with provided user@.service with some
   modifications:
   
   --- /usr/lib/systemd/system/user@.service 2013-05-30 16:55:28.0
   +0400
   +++ /etc/systemd/system/user@.service 2013-06-07 03:46:27.158435556
   +0400
   @@ -13,11 +13,14 @@
   
User=%I
PAMName=systemd-shared
# in order to allow MEM_CG features to work, add memory:/ here
   
   -ControlGroup=%R/user/%U.user/shared cpu:/
   +# note to myself: cpu:/ has been removed due to running a -ck kernel
   +ControlGroup=%R/user/%U.user/shared
   
ControlGroupModify=yes
Type=notify
ExecStart=-/usr/lib/systemd/systemd --user
   
   +Environment=XDG_RUNTIME_DIR=/run/user/%U
   
   Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%U/dbus/user_bu
   s_
   socket +Environment=SHELL=%s
   
[Install]
Alias=user@%i.service
   
   --
   
   This modified unit works (almost) as expected, however, everything that
   is
   started under that systemd instance does _not_ get its own session.
   For example, $XDG_SESSION_ID is empty and there are no new records
   in output of 'loginctl list-sessions'.
   
   So, a question: is this the desired behavior, and, if yes, how can I
   create
   a session manually?
  
  This is one of the missing parts - loginctl needs modifications to
  make enable-linger working, and that's not implemented.
  
  Ultimately, the admin should not directly start a user@.service
  instance manually.
  
  Auke
 
 Hm, interesting..
 After an hour of experiments, I changed PAMName to system-login. It
 worked, and then I looked at your user-session@.service just to find out
 that the same thing is done there.
 
 Ivan

So I've succeeded in launching a vt-based session (Type=tty, Class=user) with 
an Xorg instance in it.

Here is another problem: actually, I planned to use this all on a headless 
machine with Xvnc as X server. Obviously, it does not have a tty, so things 
like TTYPath=... can't be applied there. So I want a session with no TTY, but 
still assigned to seat0 and always Active.

Plain omission of TTYPath= from user-session@.service gives me a session of 
Class=background and empty Seat, however it is Active.
If e. g. KDM is used to start a session (configured to use Xvnc), it gives me 
a session of Type=x11 and again an empty Seat (I guess, because there is no 
TTY).

So basically three questions:
1) Is this a correct way to go, or it's easier to configure polkit to be lax 
(allow everything to everyone) and be happy with Class=background and empty 
Seat?
2) Does Type=x11 influence anything? If yes, then how to launch such a 
session using only systemd (without a DM)?
3) How to assign a session to a specific seat, again with systemd only?

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

[systemd-devel] [PATCHv5 1/3] units: order systemd-fsck@.service after local-fs-pre.target.

[Ivan Shapovalov]

With this change, it becomes possible to order a unit to activate before any
modifications to the file systems. This is especially useful for supporting
resume from hibernation.
---
 units/systemd-f...@.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/units/systemd-f...@.service.in b/units/systemd-f...@.service.in
index c12efa8..d2cda6a 100644
--- a/units/systemd-f...@.service.in
+++ b/units/systemd-f...@.service.in
@@ -10,7 +10,7 @@ Description=File System Check on %f
 Documentation=man:systemd-fsck@.service(8)
 DefaultDependencies=no
 BindsTo=%i.device
-After=systemd-readahead-collect.service systemd-readahead-replay.service 
%i.device systemd-fsck-root.service
+After=systemd-readahead-collect.service systemd-readahead-replay.service 
%i.device systemd-fsck-root.service local-fs-pre.target
 Before=shutdown.target
 
 [Service]
-- 
2.1.0

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

[systemd-devel] [PATCHv5 3/3] hibernate-resume-generator: add a generator for instantiating the resume unit.

[Ivan Shapovalov]

-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry
   /para
 /refsect1
 
diff --git a/man/systemd-hibernate-resume-generator.xml 
b/man/systemd-hibernate-resume-generator.xml
new file mode 100644
index 000..1a4b99c
--- /dev/null
+++ b/man/systemd-hibernate-resume-generator.xml
@@ -0,0 +1,93 @@
+?xml version=1.0?
+!--*-nxml-*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+!--
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+--
+refentry id=systemd-hibernate-resume-generator
+
+refentryinfo
+titlesystemd-hibernate-resume-generator/title
+productnamesystemd/productname
+
+authorgroup
+author
+contribDeveloper/contrib
+firstnameIvan/firstname
+surnameShapovalov/surname
+emailintelfx...@gmail.com/email
+/author
+/authorgroup
+/refentryinfo
+
+refmeta
+
refentrytitlesystemd-hibernate-resume-generator/refentrytitle
+manvolnum8/manvolnum
+/refmeta
+
+refnamediv
+refnamesystemd-hibernate-resume-generator/refname
+refpurposeUnit generator for resume= kernel 
parameter/refpurpose
+/refnamediv
+
+refsynopsisdiv
+
parafilename/usr/lib/systemd/system-generators/systemd-hibernate-resume-generator/filename/para
+/refsynopsisdiv
+
+refsect1
+titleDescription/title
+
+parafilenamesystemd-hibernate-resume-generator/filename 
is
+a generator that instantiates
+
citerefentryrefentrytitlesystemd-hibernate-resume@.service/refentrytitlemanvolnum8/manvolnum/citerefentry
+unit according to the value of optionresume=/option
+parameter specified on the kernel command line./para
+/refsect1
+
+refsect1
+titleKernel Command Line/title
+
+parafilenamesystemd-hibernate-resume-generator/filename 
understands
+the following kernel command line parameters:/para
+
+variablelist class='kernel-commandline-options'
+
+varlistentry
+termvarnameresume=/varname/term
+
+listitemparaTakes a path to the resume
+device. Both persistent block device pathes 
like
+filename/dev/disk/by-foo/bar/filename and
+
citerefentryrefentrytitlefstab/refentrytitlemanvolnum5/manvolnum/citerefentry-style
+specifiers like literalFOO=bar/literal
+are supported./para/listitem
+/varlistentry
+
+/variablelist
+/refsect1
+
+refsect1
+titleSee Also/title
+para
+
citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry,
+
citerefentryrefentrytitlesystemd-hibernate-resume@.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
+
citerefentryrefentrytitlekernel-command-line/refentrytitlemanvolnum7/manvolnum/citerefentry
+/para
+/refsect1
+
+/refentry
diff --git a/src/resume-generator/Makefile b/src/resume-generator/Makefile
new file mode 12
index 000..d0b0e8e
--- /dev/null
+++ b/src/resume-generator/Makefile
@@ -0,0 +1 @@
+../Makefile
\ No newline at end of file
diff --git a/src/resume-generator/resume-generator.c 
b/src/resume-generator/resume-generator.c
new file mode 100644
index 000..f407216
--- /dev/null
+++ b/src/resume-generator/resume-generator.c
@@ -0,0 +1,95 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either

[systemd-devel] [PATCHv5 0/3] hibernate-resume: implement support for resuming from hibernation

[Ivan Shapovalov]

This patchset allows systemd to parse resume= kernel command line parameter
and initiate resume from the specified device.

It adds:
- a 'systemd-hibernate-resume' tool which takes path to a device node and
  writes its major:minor to /sys/power/resume;
- a corresponding 'systemd-hibernate-resume@.service' templated unit;
- a 'systemd-hibernate-resume-generator' generator which parses the kernel
  command line and instantiates the unit as necessary.

This functionality already exists in-kernel, but only for /dev/sdXY-style
pathes. Implementing it in userspace allows to use arbitrary udev-created
symlinks, e. g. persistent block device pathes (/dev/disk/by-foo/bar) or
fstab-like specifiers (FOO=bar).

Userspace parsing of resume= kernel command line parameter has been
traditionally done in initramfs via shell scripts (for Arch Linux, this is
resume mkinitcpio hook), so I feel that this feature has its place within
systemd.

Due to the nature of hibernation, the resume unit must be activated before
any modifications to filesystems take place. This can happen only in initramfs
before mounting anything.

So, first patch orders all non-root fsck after local-fs-pre.target, which in
turn allows to order the resume unit before those fsck instances.

Second and third patches add the tool, the unit and the generator.

Thanks for reviewing!

v2: fix issues pointed out by Andrei:
- don't RemainAfterExit because it's useless
- don't attempt to resume outside of initramfs because it's unsafe
  (reiserfs replays journal even if mounted RO)

v3: fix mistakes spotted by Thomas:
- return 0 in main path of resume.c:process_resume()
- fix type and add missing cleanup attribute in resume-generator.c:main()

v4: drop the [RFC] prefix as there are no more issues with this approach;
incorporate feedback from Lennart:
- fix indentation in resume-generator.c:parse_proc_cmdline_item()
- remove overly aggressive 80-column line breaks
- don't Before=usr.mount and After=systemd-udevd.service
  as the respective configurations are deemed broken
- reword the Failed to resume message and downgrade it to log_info()

v5: add the binaries and preprocessed unit to respective .gitignore files
incorporate feedback from Lennart:
- rename systemd-resume-* to systemd-hibernate-resume-*
incorporate feedback from Dave:
- use fstab_node_to_udev_node() in the generator to also handle fstab-like
  specifiers

Ivan Shapovalov (3):
  units: order systemd-fsck@.service after local-fs-pre.target.
  hibernate-resume: add a tool to write a device node's major:minor to 
/sys/power/resume.
  hibernate-resume-generator: add a generator for instantiating the resume unit.

 .gitignore |  2 +
 Makefile-man.am| 21 +++
 Makefile.am| 28 +++--
 man/kernel-command-line.xml| 14 -
 man/systemd-hibernate-resume-generator.xml | 93 +
 man/systemd-hibernate-res...@.service.xml  | 81 +
 src/hibernate-resume/Makefile  |  1 +
 src/hibernate-resume/hibernate-resume.c| 81 +
 src/resume-generator/Makefile  |  1 +
 src/resume-generator/resume-generator.c| 95 ++
 units/.gitignore   |  1 +
 units/systemd-f...@.service.in |  2 +-
 units/systemd-hibernate-res...@.service.in | 20 +++
 13 files changed, 422 insertions(+), 18 deletions(-)
 create mode 100644 man/systemd-hibernate-resume-generator.xml
 create mode 100644 man/systemd-hibernate-res...@.service.xml
 create mode 12 src/hibernate-resume/Makefile
 create mode 100644 src/hibernate-resume/hibernate-resume.c
 create mode 12 src/resume-generator/Makefile
 create mode 100644 src/resume-generator/resume-generator.c
 create mode 100644 units/systemd-hibernate-res...@.service.in

-- 
2.1.0

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

[systemd-devel] [PATCHv5 2/3] hibernate-resume: add a tool to write a device node's major:minor to /sys/power/resume.

[Ivan Shapovalov]

-res...@.service.xml 
b/man/systemd-hibernate-res...@.service.xml
new file mode 100644
index 000..9b188b0
--- /dev/null
+++ b/man/systemd-hibernate-res...@.service.xml
@@ -0,0 +1,81 @@
+?xml version=1.0?
+!--*-nxml-*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+!--
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+--
+refentry id=systemd-hibernate-resume@.service
+
+refentryinfo
+titlesystemd-hibernate-resume@.service/title
+productnamesystemd/productname
+
+authorgroup
+author
+contribDeveloper/contrib
+firstnameIvan/firstname
+surnameShapovalov/surname
+emailintelfx...@gmail.com/email
+/author
+/authorgroup
+/refentryinfo
+
+refmeta
+
refentrytitlesystemd-hibernate-resume@.service/refentrytitle
+manvolnum8/manvolnum
+/refmeta
+
+refnamediv
+refnamesystemd-hibernate-resume@.service/refname
+refnamesystemd-hibernate-resume/refname
+refpurposeResume from hibernation/refpurpose
+/refnamediv
+
+refsynopsisdiv
+
parafilenamesystemd-hibernate-resume@.service/filename/para
+
parafilename/usr/lib/systemd/systemd-hibernate-resume/filename/para
+/refsynopsisdiv
+
+refsect1
+titleDescription/title
+
+parafilenamesystemd-hibernate-resume@.service/filename 
is a
+service that initiates hibernation resume from a device
+containing the resume image. It is instantiated for each
+device that is configured for resuming from./para
+
+parafilenamesystemd-hibernate-resume/filename only 
supports
+the in-kernel hibernation implementation, known as swsusp.
+Internally, it works by writing the major:minor of specified
+device node to filename/sys/power/resume/filename./para
+
+paraFailing to initiate a resume is not an error condition.
+It may mean that there was no resume image (e. g. if the
+system has been simply powered off and not hibernated). In
+such case, the boot is ordinarily continued./para
+/refsect1
+
+refsect1
+titleSee Also/title
+para
+
citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry,
+
citerefentryrefentrytitlesystemd-hibernate-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry
+/para
+/refsect1
+
+/refentry
diff --git a/src/hibernate-resume/Makefile b/src/hibernate-resume/Makefile
new file mode 12
index 000..d0b0e8e
--- /dev/null
+++ b/src/hibernate-resume/Makefile
@@ -0,0 +1 @@
+../Makefile
\ No newline at end of file
diff --git a/src/hibernate-resume/hibernate-resume.c 
b/src/hibernate-resume/hibernate-resume.c
new file mode 100644
index 000..8f68f81
--- /dev/null
+++ b/src/hibernate-resume/hibernate-resume.c
@@ -0,0 +1,81 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include stdio.h
+#include errno.h
+#include sys/types.h
+#include sys/stat.h
+#include unistd.h
+
+#include log.h
+#include util.h
+#include fileio.h
+
+int main(int argc

Re: [systemd-devel] Current status wrt. realtime services (aka jackd)

[Ivan Shapovalov]

On Tuesday 26 August 2014 at 02:48:04, Lennart Poettering wrote:
 On Tue, 26.08.14 02:02, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  Hello all,
  
  is there some replacement of the ControlGroupAttribute=cpu.rt_runtime_us 
  somevalue
  tunable described at 
  http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/
  for allowing services like `jackd -R` to run?
 
 Currently there isn't the rt cgroup attrs still haven't been
 implemented, because the kernel side interface is so awful, and is about
 to get changed.
 
 Best is probably to write these bits out from ExecStartPre= or so, and
 use %r to get the cgroup path. But it's really nasty, since it isn't
 clear what to write in there, and you'd have to iterate it up the tree, 
 manually.

That's pretty unfortunate. Is there any ETA for this or a checklist of what
has to be done?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCHv6 2/3] hibernate-resume: add a tool to write a device node's major:minor to /sys/power/resume.

[Ivan Shapovalov]

-hibernate-res...@.service.xml
new file mode 100644
index 000..9b188b0
--- /dev/null
+++ b/man/systemd-hibernate-res...@.service.xml
@@ -0,0 +1,81 @@
+?xml version=1.0?
+!--*-nxml-*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+!--
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+--
+refentry id=systemd-hibernate-resume@.service
+
+refentryinfo
+titlesystemd-hibernate-resume@.service/title
+productnamesystemd/productname
+
+authorgroup
+author
+contribDeveloper/contrib
+firstnameIvan/firstname
+surnameShapovalov/surname
+emailintelfx...@gmail.com/email
+/author
+/authorgroup
+/refentryinfo
+
+refmeta
+
refentrytitlesystemd-hibernate-resume@.service/refentrytitle
+manvolnum8/manvolnum
+/refmeta
+
+refnamediv
+refnamesystemd-hibernate-resume@.service/refname
+refnamesystemd-hibernate-resume/refname
+refpurposeResume from hibernation/refpurpose
+/refnamediv
+
+refsynopsisdiv
+
parafilenamesystemd-hibernate-resume@.service/filename/para
+
parafilename/usr/lib/systemd/systemd-hibernate-resume/filename/para
+/refsynopsisdiv
+
+refsect1
+titleDescription/title
+
+parafilenamesystemd-hibernate-resume@.service/filename 
is a
+service that initiates hibernation resume from a device
+containing the resume image. It is instantiated for each
+device that is configured for resuming from./para
+
+parafilenamesystemd-hibernate-resume/filename only 
supports
+the in-kernel hibernation implementation, known as swsusp.
+Internally, it works by writing the major:minor of specified
+device node to filename/sys/power/resume/filename./para
+
+paraFailing to initiate a resume is not an error condition.
+It may mean that there was no resume image (e. g. if the
+system has been simply powered off and not hibernated). In
+such case, the boot is ordinarily continued./para
+/refsect1
+
+refsect1
+titleSee Also/title
+para
+
citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry,
+
citerefentryrefentrytitlesystemd-hibernate-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry
+/para
+/refsect1
+
+/refentry
diff --git a/src/hibernate-resume/Makefile b/src/hibernate-resume/Makefile
new file mode 12
index 000..d0b0e8e
--- /dev/null
+++ b/src/hibernate-resume/Makefile
@@ -0,0 +1 @@
+../Makefile
\ No newline at end of file
diff --git a/src/hibernate-resume/hibernate-resume.c 
b/src/hibernate-resume/hibernate-resume.c
new file mode 100644
index 000..8f68f81
--- /dev/null
+++ b/src/hibernate-resume/hibernate-resume.c
@@ -0,0 +1,81 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include stdio.h
+#include errno.h
+#include sys/types.h
+#include sys/stat.h
+#include unistd.h
+
+#include log.h
+#include util.h
+#include fileio.h
+
+int main(int argc, char *argv[]) {
+struct stat st

[systemd-devel] [PATCHv6 1/3] units: order systemd-fsck@.service after local-fs-pre.target.

[Ivan Shapovalov]

With this change, it becomes possible to order a unit to activate before any
modifications to the file systems. This is especially useful for supporting
resume from hibernation.
---
 units/systemd-f...@.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/units/systemd-f...@.service.in b/units/systemd-f...@.service.in
index c12efa8..d2cda6a 100644
--- a/units/systemd-f...@.service.in
+++ b/units/systemd-f...@.service.in
@@ -10,7 +10,7 @@ Description=File System Check on %f
 Documentation=man:systemd-fsck@.service(8)
 DefaultDependencies=no
 BindsTo=%i.device
-After=systemd-readahead-collect.service systemd-readahead-replay.service 
%i.device systemd-fsck-root.service
+After=systemd-readahead-collect.service systemd-readahead-replay.service 
%i.device systemd-fsck-root.service local-fs-pre.target
 Before=shutdown.target
 
 [Service]
-- 
2.1.0

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

[systemd-devel] [PATCHv6 3/3] hibernate-resume-generator: add a generator for instantiating the resume unit.

[Ivan Shapovalov]

-resume-generator/refentrytitlemanvolnum8/manvolnum/citerefentry
   /para
 /refsect1
 
diff --git a/man/systemd-hibernate-resume-generator.xml 
b/man/systemd-hibernate-resume-generator.xml
new file mode 100644
index 000..1a4b99c
--- /dev/null
+++ b/man/systemd-hibernate-resume-generator.xml
@@ -0,0 +1,93 @@
+?xml version=1.0?
+!--*-nxml-*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+!--
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+--
+refentry id=systemd-hibernate-resume-generator
+
+refentryinfo
+titlesystemd-hibernate-resume-generator/title
+productnamesystemd/productname
+
+authorgroup
+author
+contribDeveloper/contrib
+firstnameIvan/firstname
+surnameShapovalov/surname
+emailintelfx...@gmail.com/email
+/author
+/authorgroup
+/refentryinfo
+
+refmeta
+
refentrytitlesystemd-hibernate-resume-generator/refentrytitle
+manvolnum8/manvolnum
+/refmeta
+
+refnamediv
+refnamesystemd-hibernate-resume-generator/refname
+refpurposeUnit generator for resume= kernel 
parameter/refpurpose
+/refnamediv
+
+refsynopsisdiv
+
parafilename/usr/lib/systemd/system-generators/systemd-hibernate-resume-generator/filename/para
+/refsynopsisdiv
+
+refsect1
+titleDescription/title
+
+parafilenamesystemd-hibernate-resume-generator/filename 
is
+a generator that instantiates
+
citerefentryrefentrytitlesystemd-hibernate-resume@.service/refentrytitlemanvolnum8/manvolnum/citerefentry
+unit according to the value of optionresume=/option
+parameter specified on the kernel command line./para
+/refsect1
+
+refsect1
+titleKernel Command Line/title
+
+parafilenamesystemd-hibernate-resume-generator/filename 
understands
+the following kernel command line parameters:/para
+
+variablelist class='kernel-commandline-options'
+
+varlistentry
+termvarnameresume=/varname/term
+
+listitemparaTakes a path to the resume
+device. Both persistent block device pathes 
like
+filename/dev/disk/by-foo/bar/filename and
+
citerefentryrefentrytitlefstab/refentrytitlemanvolnum5/manvolnum/citerefentry-style
+specifiers like literalFOO=bar/literal
+are supported./para/listitem
+/varlistentry
+
+/variablelist
+/refsect1
+
+refsect1
+titleSee Also/title
+para
+
citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry,
+
citerefentryrefentrytitlesystemd-hibernate-resume@.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
+
citerefentryrefentrytitlekernel-command-line/refentrytitlemanvolnum7/manvolnum/citerefentry
+/para
+/refsect1
+
+/refentry
diff --git a/src/resume-generator/Makefile b/src/resume-generator/Makefile
new file mode 12
index 000..d0b0e8e
--- /dev/null
+++ b/src/resume-generator/Makefile
@@ -0,0 +1 @@
+../Makefile
\ No newline at end of file
diff --git a/src/resume-generator/resume-generator.c 
b/src/resume-generator/resume-generator.c
new file mode 100644
index 000..f407216
--- /dev/null
+++ b/src/resume-generator/resume-generator.c
@@ -0,0 +1,95 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright 2014 Ivan Shapovalov
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either

[systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation

[Ivan Shapovalov]

This patchset allows systemd to parse resume= kernel command line parameter
and initiate resume from the specified device.

It adds:
- a 'systemd-hibernate-resume' tool which takes path to a device node and
  writes its major:minor to /sys/power/resume;
- a corresponding 'systemd-hibernate-resume@.service' templated unit;
- a 'systemd-hibernate-resume-generator' generator which parses the kernel
  command line and instantiates the unit as necessary.

This functionality already exists in-kernel, but only for /dev/sdXY-style
pathes. Implementing it in userspace allows to use arbitrary udev-created
symlinks, e. g. persistent block device pathes (/dev/disk/by-foo/bar) or
fstab-like specifiers (FOO=bar).

Userspace parsing of resume= kernel command line parameter has been
traditionally done in initramfs via shell scripts (for Arch Linux, this is
resume mkinitcpio hook), so I feel that this feature has its place within
systemd.

Due to the nature of hibernation, the resume unit must be activated before
any modifications to filesystems take place. This can happen only in initramfs
before mounting anything.

So, first patch orders all non-root fsck after local-fs-pre.target, which in
turn allows to order the resume unit before those fsck instances.

Second and third patches add the tool, the unit and the generator.

Thanks for reviewing!

v2: fix issues pointed out by Andrei:
- don't RemainAfterExit because it's useless
- don't attempt to resume outside of initramfs because it's unsafe
  (reiserfs replays journal even if mounted RO)

v3: fix mistakes spotted by Thomas:
- return 0 in main path of resume.c:process_resume()
- fix type and add missing cleanup attribute in resume-generator.c:main()

v4: drop the [RFC] prefix as there are no more issues with this approach;
incorporate feedback from Lennart:
- fix indentation in resume-generator.c:parse_proc_cmdline_item()
- remove overly aggressive 80-column line breaks
- don't Before=usr.mount and After=systemd-udevd.service
  as the respective configurations are deemed broken
- reword the Failed to resume message and downgrade it to log_info()

v5: add the binaries and preprocessed unit to respective .gitignore files
incorporate feedback from Lennart:
- rename systemd-resume-* to systemd-hibernate-resume-*
incorporate feedback from Dave:
- use fstab_node_to_udev_node() in the generator to also handle fstab-like
  specifiers

v6: rebase against master

Ivan Shapovalov (3):
  units: order systemd-fsck@.service after local-fs-pre.target.
  hibernate-resume: add a tool to write a device node's major:minor to 
/sys/power/resume.
  hibernate-resume-generator: add a generator for instantiating the resume unit.

 .gitignore |  2 +
 Makefile-man.am|  9 +++
 Makefile.am| 28 +++--
 man/kernel-command-line.xml| 14 -
 man/systemd-hibernate-resume-generator.xml | 93 +
 man/systemd-hibernate-res...@.service.xml  | 81 +
 src/hibernate-resume/Makefile  |  1 +
 src/hibernate-resume/hibernate-resume.c| 81 +
 src/resume-generator/Makefile  |  1 +
 src/resume-generator/resume-generator.c| 95 ++
 units/.gitignore   |  1 +
 units/systemd-f...@.service.in |  2 +-
 units/systemd-hibernate-res...@.service.in | 20 +++
 13 files changed, 422 insertions(+), 6 deletions(-)
 create mode 100644 man/systemd-hibernate-resume-generator.xml
 create mode 100644 man/systemd-hibernate-res...@.service.xml
 create mode 12 src/hibernate-resume/Makefile
 create mode 100644 src/hibernate-resume/hibernate-resume.c
 create mode 12 src/resume-generator/Makefile
 create mode 100644 src/resume-generator/resume-generator.c
 create mode 100644 units/systemd-hibernate-res...@.service.in

-- 
2.1.0

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

Re: [systemd-devel] [PATCHv5 0/3] hibernate-resume: implement support for resuming from hibernation

[Ivan Shapovalov]

On Tuesday 26 August 2014 at 22:02:32, Lennart Poettering wrote:
 On Tue, 26.08.14 23:53, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
 Looks great, wanted to commit. But the series doesn't apply to current
 git. Could you please rebase?

Sorry, I've been writing against v215 which is current in arch. Just sent
the v6 against current master.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCHv6 2/3] hibernate-resume: add a tool to write a device node's major:minor to /sys/power/resume.

[Ivan Shapovalov]

On Wednesday 27 August 2014 at 08:18:38, Thomas Bächler wrote:  
 Am 26.08.2014 um 22:17 schrieb Ivan Shapovalov:
  This can be used to initiate a resume from hibernation by path to a swap
  device containing the hibernation image.
  
  The respective templated unit is also added. It is instantiated using
  path to the desired resume device.
 
 Really great stuff, this was really missing from systemd initrd. I only
 saw this because of your posting to the arch-projects list, so I am late
 to the party. Anyway, although this is commited to systemd.git, there's
 no reason it can't still be improved.
 
  diff --git a/units/systemd-hibernate-res...@.service.in 
  b/units/systemd-hibernate-res...@.service.in
  new file mode 100644
  index 000..6db584d
  --- /dev/null
  +++ b/units/systemd-hibernate-res...@.service.in
  @@ -0,0 +1,20 @@
  +#  This file is part of systemd.
  +#
  +#  systemd is free software; you can redistribute it and/or modify it
  +#  under the terms of the GNU Lesser General Public License as published by
  +#  the Free Software Foundation; either version 2.1 of the License, or
  +#  (at your option) any later version.
  +
  +[Unit]
  +Description=Resume from hibernation using device %f
  +Documentation=man:systemd-hibernate-resume@.service(8)
  +DefaultDependencies=no
  +BindsTo=%i.device
 
 What's the purpose of BindsTo= as opposed to Requires= here. They are
 both the same for a oneshot service, but the former is more confusing.

This is just because systemd-fsck@.service does the same. Seems like it's
the established usage, as Andrei says.

 
  +Wants=local-fs-pre.target
  +After=%i.device
  +Before=local-fs-pre.target systemd-remount-fs.service 
  systemd-fsck-root.service
 
 The part of ordering this Before=local-fs-pre.target is so crucial, it
 can't be stressed enough. If _anything_ writes to _any_ file system
 before this service runs, your system is broken and your data is lost.
 That said, are you sure that all services are properly ordered against
 the target?

I've spent quite some time verifying this. The only thing not covered
is usr.mount (not sysroot-usr.mount), but Lennart says any configuration
with initramfs's /usr split off is broken.

(Yes, I assume that lvm2, mdadm/mdmon, dm-event and so on don't write
to filesystems. If I'm wrong -- this needs to be fixed...)

 
 What's the purpose of ordering this against systemd-fsck-root.service?
 This service is not run in initrd ever, because it checks
 'ConditionPathIsReadWrite=!/', which always fails in initrd.

Just a leftover, indeed. These services do not exist in initramfs.
They probably should be removed in a separate commit.

 
  +ConditionPathExists=/etc/initrd-release
 
 We should have and use ConditionInitrd=. I am surprised that this
 doesn't exist, but it really should.

Would you accept a patch adding that (using in_initrd()) and converting
all uses of ConditionPathExists=/etc/initrd-release to this new
condition statement?

Thanks for review!

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation

[Ivan Shapovalov]

On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: 
 On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote:
  On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx...@gmail.com) wrote:
   This patchset allows systemd to parse resume= kernel command line 
   parameter
   and initiate resume from the specified device.
 What about swap files with the resume_offset= parameter? Are they still
 being used?

I don't know if somebody uses that, but for now it's missing functionality.

After a cursory search, I could not find a mechanism to initiate a resume with
offset from userspace. In Arch, it was never implemented even if possible.

--
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 1/2] units: add ConditionInitrd=

[Ivan Shapovalov]

---
 man/systemd.unit.xml  | 13 +
 src/core/condition.c  | 17 +
 src/core/load-fragment-gperf.gperf.m4 |  1 +
 src/shared/condition-util.c   |  1 +
 src/shared/condition-util.h   |  1 +
 5 files changed, 33 insertions(+)

diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index c8d9300..4cd5201 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -919,6 +919,7 @@
 
termvarnameConditionACPower=/varname/term
 
termvarnameConditionNeedsUpdate=/varname/term
 
termvarnameConditionFirstBoot=/varname/term
+
termvarnameConditionInitrd=/varname/term
 
termvarnameConditionPathExists=/varname/term
 
termvarnameConditionPathExistsGlob=/varname/term
 
termvarnameConditionPathIsDirectory=/varname/term
@@ -1132,6 +1133,18 @@
 when a new system instances boots up
 for the first time./para
 
+paravarnameConditionInitrd=/varname
+may be used to check whether the root
+filesystem is an initramfs at the time
+of activation of the unit. It takes a
+boolean argument. If set to
+varnametrue/varname, the condition
+will hold only if the system runs from
+an initramfs. Conversely, if set to
+varnamefalse/varname, the condition
+will hold only if the system runs from
+the real root./para
+
 paraWith
 varnameConditionPathExists=/varname
 a file existence condition is
diff --git a/src/core/condition.c b/src/core/condition.c
index 353e0c9..6be3d58 100644
--- a/src/core/condition.c
+++ b/src/core/condition.c
@@ -134,6 +134,20 @@ static bool condition_test_first_boot(Condition *c) {
 return ((access(/run/systemd/first-boot, F_OK) = 0) == !!r) == 
!c-negate;
 }
 
+static bool condition_test_initrd(Condition *c) {
+int r;
+
+assert(c);
+assert(c-parameter);
+assert(c-type == CONDITION_INITRD);
+
+r = parse_boolean(c-parameter);
+if (r  0)
+return c-negate;
+
+return (in_initrd() == !!r) == !c-negate;
+}
+
 static bool condition_test(Condition *c) {
 assert(c);
 
@@ -219,6 +233,9 @@ static bool condition_test(Condition *c) {
 case CONDITION_FIRST_BOOT:
 return condition_test_first_boot(c);
 
+case CONDITION_INITRD:
+return condition_test_initrd(c);
+
 case CONDITION_NULL:
 return !c-negate;
 
diff --git a/src/core/load-fragment-gperf.gperf.m4 
b/src/core/load-fragment-gperf.gperf.m4
index 24aa80d..698f81f 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -170,6 +170,7 @@ Unit.ConditionSecurity,  
config_parse_unit_condition_string, CONDITION_S
 Unit.ConditionCapability,config_parse_unit_condition_string, 
CONDITION_CAPABILITY,  0
 Unit.ConditionHost,  config_parse_unit_condition_string, 
CONDITION_HOST,0
 Unit.ConditionACPower,   config_parse_unit_condition_string, 
CONDITION_AC_POWER,0
+Unit.ConditionInitrd,config_parse_unit_condition_string, 
CONDITION_INITRD,  0
 Unit.ConditionNull,  config_parse_unit_condition_null,   0,
 0
 m4_dnl
 Service.PIDFile, config_parse_unit_path_printf,  0,
 offsetof(Service, pid_file)
diff --git a/src/shared/condition-util.c b/src/shared/condition-util.c
index ff4a8ec..e5779ce 100644
--- a/src/shared/condition-util.c
+++ b/src/shared/condition-util.c
@@ -261,6 +261,7 @@ static const char* const 
condition_type_table[_CONDITION_TYPE_MAX] = {
 [CONDITION_ARCHITECTURE] = ConditionArchitecture,
 [CONDITION_NEEDS_UPDATE] = ConditionNeedsUpdate,
 [CONDITION_FIRST_BOOT] = ConditionFirstBoot,
+[CONDITION_INITRD] = ConditionInitrd,
 [CONDITION_NULL] = ConditionNull
 };
 
diff --git a/src/shared/condition-util.h b/src/shared/condition-util.h
index 047fdbf..a78fcd9 100644
--- a/src/shared/condition-util.h
+++ b/src/shared/condition-util.h
@@ -46,6 +46,7 @@ typedef enum ConditionType {
 CONDITION_ARCHITECTURE,
 CONDITION_NEEDS_UPDATE,
 CONDITION_FIRST_BOOT,
+CONDITION_INITRD,
 CONDITION_NULL,
 _CONDITION_TYPE_MAX,
 

[systemd-devel] [PATCH 0/2] units: add and use ConditionInitrd= instead of checking for /etc/initrd-release.

[Ivan Shapovalov]

This is as proposed by Thomas in review of my hibernate-resume patchset.

The objective benefit of this change is that in_initrd() function is used
for checking, which not only checks for /etc/initrd-release, but also verifies
that the rootfs is on a virtual device.

Ivan Shapovalov (2):
  units: add ConditionInitrd=
  units: use ConditionInitrd=true instead of 
ConditionPathExists=/etc/initrd-release

 man/systemd.unit.xml   | 13 +
 src/core/condition.c   | 17 +
 src/core/load-fragment-gperf.gperf.m4  |  1 +
 src/shared/condition-util.c|  1 +
 src/shared/condition-util.h|  1 +
 units/initrd-cleanup.service.in|  2 +-
 units/initrd-fs.target |  2 +-
 units/initrd-parse-etc.service.in  |  2 +-
 units/initrd-root-fs.target|  2 +-
 units/initrd-switch-root.service.in|  2 +-
 units/initrd-switch-root.target|  2 +-
 units/initrd-udevadm-cleanup-db.service.in |  2 +-
 units/initrd.target|  2 +-
 units/systemd-hibernate-res...@.service.in |  2 +-
 14 files changed, 42 insertions(+), 9 deletions(-)

-- 
2.1.0

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

[systemd-devel] [PATCH 2/2] units: use ConditionInitrd=true instead of ConditionPathExists=/etc/initrd-release

[Ivan Shapovalov]

---
 units/initrd-cleanup.service.in| 2 +-
 units/initrd-fs.target | 2 +-
 units/initrd-parse-etc.service.in  | 2 +-
 units/initrd-root-fs.target| 2 +-
 units/initrd-switch-root.service.in| 2 +-
 units/initrd-switch-root.target| 2 +-
 units/initrd-udevadm-cleanup-db.service.in | 2 +-
 units/initrd.target| 2 +-
 units/systemd-hibernate-res...@.service.in | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/units/initrd-cleanup.service.in b/units/initrd-cleanup.service.in
index b1dda16..833c59d 100644
--- a/units/initrd-cleanup.service.in
+++ b/units/initrd-cleanup.service.in
@@ -8,7 +8,7 @@
 [Unit]
 Description=Cleaning Up and Shutting Down Daemons
 DefaultDependencies=no
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 OnFailure=emergency.target
 OnFailureJobMode=replace-irreversibly
 After=initrd-root-fs.target initrd-fs.target initrd.target
diff --git a/units/initrd-fs.target b/units/initrd-fs.target
index 7ec838a..a02a3b4 100644
--- a/units/initrd-fs.target
+++ b/units/initrd-fs.target
@@ -10,7 +10,7 @@ Description=Initrd File Systems
 Documentation=man:systemd.special(7)
 OnFailure=emergency.target
 OnFailureJobMode=replace-irreversibly
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 After=initrd-parse-etc.service
 DefaultDependencies=no
 Conflicts=shutdown.target
diff --git a/units/initrd-parse-etc.service.in 
b/units/initrd-parse-etc.service.in
index c0b2543..22fe8cc 100644
--- a/units/initrd-parse-etc.service.in
+++ b/units/initrd-parse-etc.service.in
@@ -12,7 +12,7 @@ Requires=initrd-root-fs.target
 After=initrd-root-fs.target
 OnFailure=emergency.target
 OnFailureJobMode=replace-irreversibly
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 
 [Service]
 Type=oneshot
diff --git a/units/initrd-root-fs.target b/units/initrd-root-fs.target
index 64f0a92..cabba13 100644
--- a/units/initrd-root-fs.target
+++ b/units/initrd-root-fs.target
@@ -8,7 +8,7 @@
 [Unit]
 Description=Initrd Root File System
 Documentation=man:systemd.special(7)
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 OnFailure=emergency.target
 OnFailureJobMode=replace-irreversibly
 DefaultDependencies=no
diff --git a/units/initrd-switch-root.service.in 
b/units/initrd-switch-root.service.in
index 82893da..b4475aa 100644
--- a/units/initrd-switch-root.service.in
+++ b/units/initrd-switch-root.service.in
@@ -8,7 +8,7 @@
 [Unit]
 Description=Switch Root
 DefaultDependencies=no
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 OnFailure=emergency.target
 OnFailureJobMode=replace-irreversibly
 AllowIsolate=yes
diff --git a/units/initrd-switch-root.target b/units/initrd-switch-root.target
index f347687..fbee5c2 100644
--- a/units/initrd-switch-root.target
+++ b/units/initrd-switch-root.target
@@ -7,7 +7,7 @@
 
 [Unit]
 Description=Switch Root
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 DefaultDependencies=no
 Requires=initrd-switch-root.service
 Before=initrd-switch-root.service
diff --git a/units/initrd-udevadm-cleanup-db.service.in 
b/units/initrd-udevadm-cleanup-db.service.in
index 5c6654e..6b97425 100644
--- a/units/initrd-udevadm-cleanup-db.service.in
+++ b/units/initrd-udevadm-cleanup-db.service.in
@@ -8,7 +8,7 @@
 [Unit]
 Description=Cleanup udevd DB
 DefaultDependencies=no
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 Conflicts=systemd-udevd.service systemd-udevd-control.socket 
systemd-udevd-kernel.socket
 After=systemd-udevd.service systemd-udevd-control.socket 
systemd-udevd-kernel.socket
 Before=initrd-switch-root.target
diff --git a/units/initrd.target b/units/initrd.target
index eae7c70..81af69e 100644
--- a/units/initrd.target
+++ b/units/initrd.target
@@ -10,7 +10,7 @@ Description=Initrd Default Target
 Documentation=man:systemd.special(7)
 OnFailure=emergency.target
 OnFailureJobMode=replace-irreversibly
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 Requires=basic.target
 Wants=initrd-root-fs.target initrd-fs.target initrd-parse-etc.service
 After=initrd-root-fs.target initrd-fs.target basic.target rescue.service 
rescue.target
diff --git a/units/systemd-hibernate-res...@.service.in 
b/units/systemd-hibernate-res...@.service.in
index 6db584d..3e8c2ef 100644
--- a/units/systemd-hibernate-res...@.service.in
+++ b/units/systemd-hibernate-res...@.service.in
@@ -13,7 +13,7 @@ BindsTo=%i.device
 Wants=local-fs-pre.target
 After=%i.device
 Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 
 [Service]
 Type=oneshot
-- 
2.1.0

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

[systemd-devel] [PATCH] units: remove unnecessary ordering dependencies in systemd-hibernate-resume@.service

[Ivan Shapovalov]

They were left from an early review iteration, when hibernate-resume
functionality was intended to work also outside of initramfs.
Now this is not the case, and these dependencies became redundant
as systemd-fsck-root.service can never be part of initramfs, and
systemd-remount-fs.service makes little sense in it.
---

This is per Thomas's post-commit review.

 units/systemd-hibernate-res...@.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/units/systemd-hibernate-res...@.service.in 
b/units/systemd-hibernate-res...@.service.in
index 3e8c2ef..1a4269b 100644
--- a/units/systemd-hibernate-res...@.service.in
+++ b/units/systemd-hibernate-res...@.service.in
@@ -12,7 +12,7 @@ DefaultDependencies=no
 BindsTo=%i.device
 Wants=local-fs-pre.target
 After=%i.device
-Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service
+Before=local-fs-pre.target
 ConditionInitrd=true
 
 [Service]
-- 
2.1.0

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

Re: [systemd-devel] [PATCH 0/2] units: add and use ConditionInitrd= instead of checking for /etc/initrd-release.

[Ivan Shapovalov]

On Wednesday 27 August 2014 at 20:19:45, Lennart Poettering wrote:  
 On Wed, 27.08.14 20:26, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  This is as proposed by Thomas in review of my hibernate-resume patchset.
  
  The objective benefit of this change is that in_initrd() function is used
  for checking, which not only checks for /etc/initrd-release, but also 
  verifies
  that the rootfs is on a virtual device.
 
 If we add a new condition then I want to hear a strong case for it. I
 mean, what's wrong with checking for initrd-release? Why would that not
 suffice?
 
 We should be really careful when it comes to an inflation of conditions...

Let's just cc Thomas Bächler who proposed this. Personally I see only one
benefit (which is described in cover letter)...

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation

[Ivan Shapovalov]

On Thursday 28 August 2014 at 06:25:51, Jan Janssen wrote:  
 Ivan Shapovalov intelfx100 at gmail.com writes:
 
  
  On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: 
   On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote:
On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx100 at gmail.com) 
wrote:
 This patchset allows systemd to parse resume= kernel command line
 parameter
 and initiate resume from the specified device.
   What about swap files with the resume_offset= parameter? Are they still
   being used?
  
  I don't know if somebody uses that, but for now it's missing functionality.
  
  After a cursory search, I could not find a mechanism to initiate a resume 
  with
  offset from userspace. In Arch, it was never implemented even if possible.
  
 
 I'm a heavy user of this myself. It's especially useful because you can just
 have a single luks encrypted ext4 without a lvm in between for a swap
 partition or (even more yuck) using a separate (encrypted) swap partition.
 
 Arch does support this, mostly because as far as I know, the resume_offset=
 is consumed by the kernel, while resume= has to refer to the (unencrypted)
 filesystem (/dev/mapper/root in my case). So, as long as this solution waits
 for the device to show up in /dev/ (and especially /dev/mapper/ for my
 case), this should work out.
 
 Here's information to set this up. Imho more people should be aware this is
 possible:
 https://wiki.archlinux.org/index.php/Suspend#Hibernation_into_swap_file
 
 Jan

Hmm, so is resume_offset= parsed independently of resume=? If that's the
case, and resume_offset= can be parsed by kernel while resume= is parsed
by userspace, then yes, I was wrong and this should work.

Actually, it should work _just like before_, sans tuxonice support.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] build: configure option to disable hibernation

[Ivan Shapovalov]

On Tuesday 02 September 2014 at 12:31:49, Umut Tezduyar Lindskog wrote: 
 ---
  Makefile.am  |   52 
  configure.ac |6 ++
  2 files changed, 38 insertions(+), 20 deletions(-)

Hi,

thanks for doing this (I'm very unfamiliar with autotools).

However, I think that the name you've picked for the switch (and commit msg) is
too broad. We're configuring support for hibernation resume, not hibernation 
itself.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] build-sys: make hibernation support configure option also handle hybrid-sleep; fix indentation

[Ivan Shapovalov]

---
The patch by Umut did miss at least hybrid-sleep -- it involves hibernation
as well (hybrid sleep is a hibernation followed by S3 rather than S4 powerdown).

Also, it messed up indentation a bit (Makefile.am seems to use tabs), which I
fixed as well.

And I wonder, maybe it makes sense to conditionalize sleep (suspend) support as 
well
as hibernation? Or are there use-cases when suspend is possible, but not 
hibernation?

 Makefile.am | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 35c877f..de40043 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -459,7 +459,6 @@ dist_systemunit_DATA = \
units/network-online.target \
units/nss-lookup.target \
units/nss-user-lookup.target \
-   units/hybrid-sleep.target \
units/poweroff.target \
units/reboot.target \
units/rescue.target \
@@ -523,7 +522,6 @@ nodist_systemunit_DATA = \
units/emergency.service \
units/rescue.service \
units/user@.service \
-   units/systemd-hybrid-sleep.service \
units/systemd-suspend.service \
units/systemd-halt.service \
units/systemd-poweroff.service \
@@ -579,7 +577,6 @@ EXTRA_DIST += \
units/systemd-fsck-root.service.in \
units/u...@.service.in \
units/debug-shell.service.in \
-   units/systemd-hybrid-sleep.service.in \
units/systemd-suspend.service.in \
units/quotaon.service.in \
units/initrd-parse-etc.service.in \
@@ -2159,17 +2156,17 @@ systemd_system_update_generator_LDADD = \
 # 
--
 if ENABLE_HIBERNATE
 systemgenerator_PROGRAMS += \
-systemd-hibernate-resume-generator
+   systemd-hibernate-resume-generator
 
 rootlibexec_PROGRAMS += \
-systemd-hibernate-resume
+   systemd-hibernate-resume
 
 systemd_hibernate_resume_SOURCES = \
-src/hibernate-resume/hibernate-resume.c
+   src/hibernate-resume/hibernate-resume.c
 
 systemd_hibernate_resume_LDADD = \
-libsystemd-internal.la \
-libsystemd-shared.la
+   libsystemd-internal.la \
+   libsystemd-shared.la
 
 systemd_hibernate_resume_generator_SOURCES = \
src/hibernate-resume/hibernate-resume-generator.c
@@ -2179,16 +2176,18 @@ systemd_hibernate_resume_generator_LDADD = \
libsystemd-shared.la
 
 EXTRA_DIST += \
-units/systemd-hibernate.service.in \
-units/systemd-hibernate-res...@.service.in
+   units/systemd-hibernate.service.in \
+   units/systemd-hibernate-res...@.service.in \
+   units/systemd-hybrid-sleep.service.in
 
 dist_systemunit_DATA += \
-units/hibernate.target
+   units/hibernate.target \
+   units/hybrid-sleep.target
 
 nodist_systemunit_DATA += \
-units/systemd-hibernate.service \
-units/systemd-hibernate-resume@.service
-
+   units/systemd-hibernate.service \
+   units/systemd-hibernate-resume@.service \
+   units/systemd-hybrid-sleep.service
 endif
 
 # 
--
-- 
2.1.0

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

Re: [systemd-devel] [PATCH] build-sys: make hibernation support configure option also handle hybrid-sleep; fix indentation

[Ivan Shapovalov]

On Tuesday 09 September 2014 at 01:40:51, Ivan Shapovalov wrote:
 ---
 The patch by Umut did miss at least hybrid-sleep -- it involves hibernation
 as well (hybrid sleep is a hibernation followed by S3 rather than S4 
 powerdown).
 
 Also, it messed up indentation a bit (Makefile.am seems to use tabs), which I
 fixed as well.
 
 And I wonder, maybe it makes sense to conditionalize sleep (suspend) support 
 as well
 as hibernation? Or are there use-cases when suspend is possible, but not 
 hibernation?
 
  Makefile.am | 27 +--
  1 file changed, 13 insertions(+), 14 deletions(-)
 
 diff --git a/Makefile.am b/Makefile.am
 [...]

Ping.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] journalctl: allow customizable output formats

[Ivan Shapovalov]

On Monday 22 September 2014 at 12:43:28, Daurnimator wrote: 
 On 22 September 2014 11:33, Daniel P. Berrange berra...@redhat.com wrote:
 
  The current '--output FORMAT' argument defines a number of
  common output formats, but there are some useful cases it
  does cover. In particular when reading application logs it
  is often desirable to display the code file name, line number
  and function name. Rather than defining yet more fixed output
  formats, this patch introduces user defined output formats.
 
  The format string is an arbitrary string which contains a
  mixture of literal text and variable subsistitions. Each
  variable name corresponds to a journal field name. A variable
  name can be optionally followed by a data type, and in the
  case of string types, a length limit.
 
 
 As an opposing point of view, I've been accomplishing this by piping output
 through a script that parses and displays JSON.
 I rather this style of composability than passing format strings to
 journalctl itself.

I think that using dedicated ad-hoc JSON parser for customizing output
is an overkill. For that matter, Git has support for custom output format
in its log command, and I've found it useful many times.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unicode support in console after boot

[Ivan Shapovalov]

On Monday 13 October 2014 at 15:36:00, Zbigniew Jędrzejewski-Szmek wrote:   
 On Mon, Oct 13, 2014 at 03:13:50PM +0200, Jan Synacek wrote:
  Andrei Borzenkov arvidj...@gmail.com writes:
   [...]
  
   Does booting with plymouth.enable=0 change anything?
  
  Nope, that doesn't help. After loadkeys cz, I still see white
  rectangles instead of proper characters.
 Could be a kernel bug too, don't rule this out. IIRC, some settings do
 not get propagated from the foreground console to other consoles, or they
 get reset at some point, or something like that (should be the ML archives).

It is also possible that settings get reset after the framebuffer driver is 
changed
(e. g. i915 module is loaded)... BTW, I'm still seeking for a correct method to
handle this.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] udev hwdb: Support shipping pre-compiled database in system images

[Ivan Shapovalov]

On Friday 17 October 2014 at 15:44:51, Martin Pitt wrote:   
 Hello again,
 
 the previous patch had a typo in the manpage (it said /lib/udev
 instead of /usr/lib/udev at one place), and also forgot to adjust
 systemd-udev-hwdb-update.service.in. Both done now.
 
 However, the latter currently has a gotcha:
 
   +ConditionPathExists=!@udevlibexecdir@/hwdb.bin
 
 This works correctly if you use this with the factory reset
 semantics, i. e. start with an empty /etc. But it would not work if
 you update /usr and have an already existing /etc/udev/hwdb.d/*. So
 ideally the condition would be
 
   ConditionPathExists=!@udevlibexecdir@/hwdb.bin OR
   ConditionDirectoryNotEmpty=/etc/udev/hwdb.d/

 
 but this isn't possible AFAIK. The alternative would be to change the
 Exec= to call hdwb --update --vendor iff /etc/udev/hwdb.d/ is empty.

I'm just an innocent bystander, but isn't it possible with these two
lines?

ConditionPathExists=|!@udevlibexecdir@/hwdb.bin
ConditionDirectoryNotEmpty=|/etc/udev/hwdb.d/

This will succeed if EITHER @udevlibexecdir@/hwdb.bin does not exist
OR /etc/udev/hwdb.d/ is not empty.

Or have I misunderstood you?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] udev hwdb: Support shipping pre-compiled database in system images

[Ivan Shapovalov]

On Sunday 19 October 2014 at 05:42:28, Ivan Shapovalov wrote:   
 On Friday 17 October 2014 at 15:44:51, Martin Pitt wrote: 
  Hello again,
  
  the previous patch had a typo in the manpage (it said /lib/udev
  instead of /usr/lib/udev at one place), and also forgot to adjust
  systemd-udev-hwdb-update.service.in. Both done now.
  
  However, the latter currently has a gotcha:
  
+ConditionPathExists=!@udevlibexecdir@/hwdb.bin
  
  This works correctly if you use this with the factory reset
  semantics, i. e. start with an empty /etc. But it would not work if
  you update /usr and have an already existing /etc/udev/hwdb.d/*. So
  ideally the condition would be
  
ConditionPathExists=!@udevlibexecdir@/hwdb.bin OR
ConditionDirectoryNotEmpty=/etc/udev/hwdb.d/
 
  
  but this isn't possible AFAIK. The alternative would be to change the
  Exec= to call hdwb --update --vendor iff /etc/udev/hwdb.d/ is empty.
 
 I'm just an innocent bystander, but isn't it possible with these two
 lines?
 
 ConditionPathExists=|!@udevlibexecdir@/hwdb.bin
 ConditionDirectoryNotEmpty=|/etc/udev/hwdb.d/
 
 This will succeed if EITHER @udevlibexecdir@/hwdb.bin does not exist
 OR /etc/udev/hwdb.d/ is not empty.
 
 Or have I misunderstood you?

Ugh, I haven't seen your second message. There's something strange with
mail delivery -- I could swear that I've fetched everything before replying...

Sorry for the noise.
-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unicode support in console after boot

[Ivan Shapovalov]

On Tuesday 21 October 2014 at 19:03:17, Michal Sekletar wrote:  
 On Tue, Oct 14, 2014 at 09:04:56AM +0200, Jan Synacek wrote:
  Michal Sekletar msekl...@redhat.com writes:
   On Mon, Oct 13, 2014 at 09:36:16AM +0200, Jan Synacek wrote:
   Hello,
   
   currently, unicode characters are not correctly displayed in the
   console. After login, when I run /usr/bin/unicode_start, unicode works
   fine. I tried to create a service file that runs this script, linking
   tty to stdout and stderr, but that didn't work. Is there a way how to
   turn on unicode support in console after boot using a service file? Or
   any other type of unit? Or is this something that has to be patched in
   the source (logind perhaps?)?
  
   Please try editing /usr/lib/systemd/system/systemd-vconsole-setup.service 
   and
   remove RemainAfterExit=yes, then regenerate your initramfs image by 
   running
   dracut command. Add back RemainAfterExit=yes to service file. Reboot.
  
  Yep, this helped. Could you please explain why? Also, I believe this
  should be fixed in all Fedora versions.
 
 I must admit I'm not sure why this workaround works. Maybe there is some race
 condition with some kernel initialization or settings get unapplied because of
 switch-root.
 
 Also, if we go with workaround in Fedora I think dracut needs to fixed to
 include version on unit file *without* RemainAfterExit=yes.

IIUC, this makes unit to be re-run outside of initramfs, so the VT is set up 
twice,
second time after switching the framebuffer driver.

And the latter condition is not mandated by anything, it's just a coincidence...

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unicode support in console after boot

[Ivan Shapovalov]

On Tuesday 21 October 2014 at 21:57:09, Michal Sekletar wrote:  
 On Tue, Oct 21, 2014 at 09:39:46PM +0400, Ivan Shapovalov wrote:
  On Tuesday 21 October 2014 at 19:03:17, Michal Sekletar wrote:  
   On Tue, Oct 14, 2014 at 09:04:56AM +0200, Jan Synacek wrote:
Michal Sekletar msekl...@redhat.com writes:
 On Mon, Oct 13, 2014 at 09:36:16AM +0200, Jan Synacek wrote:
 Hello,
 
 currently, unicode characters are not correctly displayed in the
 console. After login, when I run /usr/bin/unicode_start, unicode 
 works
 fine. I tried to create a service file that runs this script, linking
 tty to stdout and stderr, but that didn't work. Is there a way how to
 turn on unicode support in console after boot using a service file? 
 Or
 any other type of unit? Or is this something that has to be patched 
 in
 the source (logind perhaps?)?

 Please try editing 
 /usr/lib/systemd/system/systemd-vconsole-setup.service and
 remove RemainAfterExit=yes, then regenerate your initramfs image by 
 running
 dracut command. Add back RemainAfterExit=yes to service file. Reboot.

Yep, this helped. Could you please explain why? Also, I believe this
should be fixed in all Fedora versions.
   
   I must admit I'm not sure why this workaround works. Maybe there is some 
   race
   condition with some kernel initialization or settings get unapplied 
   because of
   switch-root.
   
   Also, if we go with workaround in Fedora I think dracut needs to fixed to
   include version on unit file *without* RemainAfterExit=yes.
  
  IIUC, this makes unit to be re-run outside of initramfs, so the VT is set 
  up twice,
  second time after switching the framebuffer driver.
  
  And the latter condition is not mandated by anything, it's just a
  coincidence...
 
 I guess that what you are saying pretty much summarizes the situation here. 
 Can
 we make something about framebuffer driver, thus settings applied in initramfs
 are not thrashed?

I don't know if there is a valid solution. Maybe someone familiar with the VT
subsystem knows...

Personally I've worked around this problem as follows: the fb driver
(i915) is included into the initramfs, while systemd-vconsole-setup is ran
only in the real root.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted

[Ivan Shapovalov]

On Wednesday 22 October 2014 at 10:26:49, Jóhann B. Guðmundsson wrote:  
 
 On 10/22/2014 09:44 AM, Lennart Poettering wrote:
  So, I thought myself a couple of times about adding a cron generator
  upstream
 
 As far as I can tell generators serve only one purpose and that is to 
 bridge an gap to allow users of consumers of systemd to migrate to it's 
 native format

I don't think this is correct. Take, for example, gpt-auto-generator,
efi-boot-generator, hibernate-resume-generator...

Also, systemd.mount(5) page states: In general, configuring mount points
through /etc/fstab is the preferred approach.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Timers without matching units?

[Ivan Shapovalov]

Hi,

The systemd.timer(5) manpage states:

For each timer file, a matching unit file must exist, describing the unit to
activate when the timer elapses.

However, if I need the timer unit just to wake up the machine (e. g. I have a
GUI alarm which does everything except configuring the wakealarm), I don't
need the timer unit to start something else. Does this sound like a valid
reason to make timers' Unit= optional?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
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?

[Ivan Shapovalov]

On Thursday 23 October 2014 at 07:06:18, Mantas Mikulėnas wrote:
 On Oct 23, 2014 1:54 AM, Lennart Poettering lenn...@poettering.net
 wrote:
 
  On Wed, 22.10.14 12:44, Damien Robert (
 damien.olivier.robert+gm...@gmail.com) wrote:
 
  [...]
 
  policykit really should get fixed there. it shouldn't try to do access
  control for individual sessions but for users on specific
  sessions.
 
 Wasn't this already fixed in polkit.git recently?

Oh, if this indeed was, then... does it mean that the last significant
blocker for widely using `systemd --user` has gone away?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd in initramfs: /etc/passwd, /etc/group, emergency.service and sulogin

[Ivan Shapovalov]

Hi,

A few questions regarding usage of systemd+udev in initramfs. Before all,
this is what I want to achieve (to prevent XY-problems): working
emergency.service in initramfs.

The questions are a bit Arch-specific and possibly lame, but well...

- is /etc/passwd still[1] needed in initramfs due to libdbus1?
- how to pass '--resolve-names=never' to udevd in initramfs, will it work this
  way and will it allow to exclude /etc/group[2] from initramfs?
- is it possible to use 'sulogin -e' instead of 'sulogin'[3] security-wise?

[1]: 
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/initcpio-install-systemd?h=packages/systemd#n141
[2]: 
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/initcpio-install-systemd?h=packages/systemd#n147
[3]: 
http://cgit.freedesktop.org/systemd/systemd/tree/units/emergency.service.in#n21

Thanks,
-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind static, want enabled

[Ivan Shapovalov]

On Thursday 23 October 2014 at 16:19:28, Felix Miata wrote: 

[cut]
 
 Those are not things I know how or wish to pursue. I found a workaround, no 
 thanks
 to the systemctl 216-10.fc22 man page, which says:
 
   enable NAME...
 
 Enable one or more unit files or unit file instances, as specified on the 
 command line
 
 That's invalid WRT rpcbind. In order to enable rpcbind I found the following
 produces satisfactory results:
 
   systemctl add-wants multi-user.target rpcbind
 
 The question remains how and why 13 of 26 (I miscounted in my original thread 
 post)
 installations were set to static instead of enabled in the first place, and 
 whether
 the workaround amounts to an optimal solution.

Because rpcbind.service is designed by the upstream to be static, not 
enabled.
It is designed to be socket-activatable and so it should not be enabled in the
sense of unconditionally started on boot. The man-page isn't wrong or invalid.

What you are experiencing seems to be a bug in rpcbind and/or statd, and what 
you
have done is a workaround. If you have done this, then you should also disable
rpcbind.socket and make sure everything that needs rpcbind is ordered after
rpcbind.service.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] man: fix typos in description of SELinuxContextFromNet=

[Ivan Shapovalov]

---
 man/systemd.socket.xml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index ce04b0b..57f769f 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -678,7 +678,7 @@
 varlistentry
   
termvarnameSELinuxContextFromNet=/varname/term
  listitemparaTakes a boolean
- argument. When true systemd will attempt
+ argument. When true, systemd will attempt
  to figure out the SELinux label used
  for the instantiated service from the
  information handed by the peer over the
@@ -688,9 +688,9 @@
  the resulting SELinux context originate
  from either the target binary that is
  effectively triggered by socket unit
- are taken from the value of the
+ or from the value of the
  varnameSELinuxContext=/varname
- option.This configuration option only
+ option. This configuration option only
  affects sockets with
  varnameAccept=/varname mode set to
  literaltrue/literal. Also note that
-- 
2.1.2

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

Re: [systemd-devel] [PATCH] Bootchart: allow parse LABEL, UUID, PARTUUID for svg info

[Ivan Shapovalov]

On Tuesday 28 October 2014 at 03:30:13, Timofey Titovets wrote: 
 Good time of day, list.
 I try to fix Fixme in svg.c:
 /* FIXME: this works only in the simple case */
 
 By default function try to get root=/dev/*
 I write small function to determine block device name by specified 
 LABEL, UUID, PARTUUID.
 
 Please check code, its working, but i think it can look more pretty.
 May be i missed(reimplemented) some internal functional of systemd?
 
 [...]

Hi,

there is at least function fstab_node_to_udev_node() in shared/util.c
which converts TAG=value to /dev/disk/by-tag/value,
and also function canonicalize_file_name() in glibc which resolves
symlinks and (hopefully) returns /dev/sdXY.

I'm not the one to judge, but your code seems pretty messy, esp. with
extensive use of magic constants and numbers...

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd and power management

[Ivan Shapovalov]

On Wednesday 29 October 2014 at 13:00:42, Daniel Hollocher wrote:   
 Hey folks,
 I'm a not expert here, so please forgive the low quality/interest of my
 question.
 
 I'm curious what the ideal systemd way is to set various power management
 settings in the /sys tree.  For me personally, I'm looking to set
 sampling_down_factor as without it, ondemand has terrible performance on my
 particular computer (a 10-30% loss compared to performance or conservative).
 
 Currently, Ubuntu uses a sysv init script to set ondemand after boot, and I
 could edit that.  It would be cool to know the ideal systemd way, that
 could also be aware of power saving stuff.
 
 From googling, it seems that tempfiles or sysctrl is not the way to go,
 since those only happen at boot.  Udev?  The examples I've found seem to
 make basic usage of udev to detect power changes, and then drop to a script
 to do the bulk of the work.  Is that it?

You could write a bunch of units pulled in by a target... well, two targets,
one for power-saving and second for performance mode. And then just start the
targets from an udev rule. Just remember to use `--no-block` as udev kills
workers after some time.

I've already done something along these lines for my own purposes, see
https://github.com/intelfx/power-management

However, I still want to know if I this is OK wrt systemd spirit.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] rules: rerun vconsole-setup when switching from vgacon to fbcon

[Ivan Shapovalov]

On Thursday 06 November 2014 at 11:02:44, David Herrmann wrote: 
 Hi Ray
 
 On Thu, Nov 6, 2014 at 10:40 AM, David Herrmann dh.herrm...@gmail.com wrote:
  On Wed, Nov 5, 2014 at 4:11 PM, Ray Strode halfl...@gmail.com wrote:
  So if you have no idea how to make that rule be generated only if
  ENABLE_VCONSOLE is set by configure, then we probably should take my
  patch below.
  Your patch seems far better than the options above, but I think it
  needs a dracut patch to make sure the new rules file gets in the
  initrd too, or it won't work.
 
  I will push the patch to systemd and let Harald know. I'm not really
  familiar with dracut..
 
 Pushed.

Isn't it ugly to re-runn systemd-vconsole-setup straight from an udev rule?
I mean, udev has a tendency to kill long-running RUN processes, and I've seen
systemd-vconsole-setup.service to take 5 seconds on some systems...
Also, these additional systemd-vconsole-setup instances aren't supervised by
systemd...

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] remote-fs ordering, iSCSI and _netdev

[Ivan Shapovalov]

On Tuesday 28 October 2014 at 06:41:32, Andrei Borzenkov wrote: 
 В Mon, 27 Oct 2014 14:10:47 -0700
 Chris Leech cle...@redhat.com пишет:
 
  
  At boot fstab-generator is picking up on the _netdev option in fstab,
  and the generated mount units are ordered against remote-fs properly.
  If I leave a filesystem mounted at shutdown, it will be unmounted before
  the iSCSI session is destroyed or the network is shut down and
  everything works as expected.
  
  But there are two cases that are problematic, adding entries to fstab at
  runtime and manually mounting without adding to fstab (while still using
  the _netdev option, some hint is needed).  The first case actually ends
  up being the second, with the possible work-around of always remembering
  to run a daemon-reload after editing fstab to run fstab-generator again.
 
 
 Even known network filesystems still have a problem. If network
 filesystem is mounted on boot, it pulls in network-online.target which
 (hopefully) serves as synchronization point on shutdown. If there is no
 network filesystem to mount at boot, network-online.target is not
 started. If you mount NFS manually later there is nothing to wait for
 on shutdown so network could be teared down before filesystem is
 unmounted.

Isn't this (unmount before teardown) achieved by After=network.target? That
target is passive, so it is pulled in by a provider, and all should work
even in case of manually mounted filesystems.

Am I wrong somewhere?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] unit-name: fix escaping logic in unit_name_mangle_with_suffix().

[Ivan Shapovalov]

Make screened character set consistent with unit_name_mangle() by splitting off
the escaping loop into a separate function.

Before this fix, unit names such as `foo@bar.target` would get transformed
into `foo\x40bar.target` when unit_name_mangle_with_suffix() is used.

https://bugs.freedesktop.org/show_bug.cgi?id=86711
---
 src/shared/unit-name.c | 51 +-
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/src/shared/unit-name.c b/src/shared/unit-name.c
index 2ef8545..6c6d7f4 100644
--- a/src/shared/unit-name.c
+++ b/src/shared/unit-name.c
@@ -243,6 +243,30 @@ static char *do_escape(const char *f, char *t) {
 return t;
 }
 
+static char *do_escape_mangle(const char *f, enum unit_name_mangle 
allow_globs, char *t) {
+const char *valid_chars;
+
+assert(f);
+assert(IN_SET(allow_globs, MANGLE_GLOB, MANGLE_NOGLOB));
+assert(t);
+
+/* We'll only escape the obvious characters here, to play
+ * safe. */
+
+valid_chars = allow_globs == MANGLE_GLOB ? @ VALID_CHARS []!-*? : 
@ VALID_CHARS;
+
+for (; *f; f++) {
+if (*f == '/')
+*(t++) = '-';
+else if (!strchr(valid_chars, *f))
+t = do_escape_char(*f, t);
+else
+*(t++) = *f;
+}
+
+return t;
+}
+
 char *unit_name_escape(const char *f) {
 char *r, *t;
 
@@ -482,11 +506,9 @@ int unit_name_from_dbus_path(const char *path, char 
**name) {
  *  sensible unit name.
  */
 char *unit_name_mangle(const char *name, enum unit_name_mangle allow_globs) {
-const char *valid_chars, *f;
 char *r, *t;
 
 assert(name);
-assert(IN_SET(allow_globs, MANGLE_GLOB, MANGLE_NOGLOB));
 
 if (is_device_path(name))
 return unit_name_from_path(name, .device);
@@ -494,23 +516,11 @@ char *unit_name_mangle(const char *name, enum 
unit_name_mangle allow_globs) {
 if (path_is_absolute(name))
 return unit_name_from_path(name, .mount);
 
-/* We'll only escape the obvious characters here, to play
- * safe. */
-
-valid_chars = allow_globs == MANGLE_GLOB ? @ VALID_CHARS []!-*? : 
@ VALID_CHARS;
-
 r = new(char, strlen(name) * 4 + strlen(.service) + 1);
 if (!r)
 return NULL;
 
-for (f = name, t = r; *f; f++) {
-if (*f == '/')
-*(t++) = '-';
-else if (!strchr(valid_chars, *f))
-t = do_escape_char(*f, t);
-else
-*(t++) = *f;
-}
+t = do_escape_mangle(name, allow_globs, r);
 
 if (unit_name_to_type(name)  0)
 strcpy(t, .service);
@@ -526,10 +536,8 @@ char *unit_name_mangle(const char *name, enum 
unit_name_mangle allow_globs) {
  */
 char *unit_name_mangle_with_suffix(const char *name, enum unit_name_mangle 
allow_globs, const char *suffix) {
 char *r, *t;
-const char *f;
 
 assert(name);
-assert(IN_SET(allow_globs, MANGLE_GLOB, MANGLE_NOGLOB));
 assert(suffix);
 assert(suffix[0] == '.');
 
@@ -537,14 +545,7 @@ char *unit_name_mangle_with_suffix(const char *name, enum 
unit_name_mangle allow
 if (!r)
 return NULL;
 
-for (f = name, t = r; *f; f++) {
-if (*f == '/')
-*(t++) = '-';
-else if (!strchr(VALID_CHARS, *f))
-t = do_escape_char(*f, t);
-else
-*(t++) = *f;
-}
+t = do_escape_mangle(name, allow_globs, r);
 
 if (!endswith(name, suffix))
 strcpy(t, suffix);
-- 
2.1.3

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

Re: [systemd-devel] [PATCH] rules: rerun vconsole-setup when switching from vgacon to fbcon

[Ivan Shapovalov]

On Friday 07 November 2014 at 16:45:02, Lennart Poettering wrote:   
 On Fri, 07.11.14 17:45, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  On Thursday 06 November 2014 at 11:02:44, David Herrmann wrote: 
   Hi Ray
   
   On Thu, Nov 6, 2014 at 10:40 AM, David Herrmann dh.herrm...@gmail.com 
   wrote:
On Wed, Nov 5, 2014 at 4:11 PM, Ray Strode halfl...@gmail.com wrote:
So if you have no idea how to make that rule be generated only if
ENABLE_VCONSOLE is set by configure, then we probably should take my
patch below.
Your patch seems far better than the options above, but I think it
needs a dracut patch to make sure the new rules file gets in the
initrd too, or it won't work.
   
I will push the patch to systemd and let Harald know. I'm not really
familiar with dracut..
   
   Pushed.
  
  Isn't it ugly to re-runn systemd-vconsole-setup straight from an udev rule?
  I mean, udev has a tendency to kill long-running RUN processes, and I've 
  seen
  systemd-vconsole-setup.service to take 5 seconds on some systems...
  Also, these additional systemd-vconsole-setup instances aren't supervised by
  systemd...
 
 Is systemd-vconsole-setup really long-running? Why would it need that
 long?
 
 To me it appears to be quite OK to be run inside a udev rule.

Well, maybe it is OK to be run from an udev rule, but it is still an
inconsistency between running that binary on boot (via a unit) and
running the same binary when a framebuffer console is added (directly)...

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Option fail mentioned in systemd.mount(5)

[Ivan Shapovalov]

Hi all,

The systemd.mount(5) man page mentions an inexistent mount option fail in the
following context:

nofail, fail
With nofail this mount will be only wanted, not required, by the
local-fs.target. This means that the boot will continue even if this
mount point is not mounted successfully. Option fail has the opposite
meaning and is the default.

Specifying the option fail in fstab produces following message in the log:

kernel: EXT4-fs (sdc1): Unrecognized mount option fail or missing value

So the man page contradicts actual behavior. Should this statement be removed,
or what?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel