date:20130304

On Sat, 02.03.13 15:00, Michal Sekletar (sekleta...@gmail.com) wrote:

 
 On Mar 1, 2013, at 3:16 PM, Lennart Poettering lenn...@poettering.net wrote:
 
  On Wed, 20.02.13 14:50, Michal Sekletar (msekl...@redhat.com) wrote:
  
  All Execs within the service, will get mounted the same /tmp and /var/tmp
  directories, if service is configured with PrivateTmp=yes. Temporary
  directories are cleaned up by service itself, rather than relying on
  systemd-tmpfiles. Same logic applies also to inaccessible directories.
  
  Hmm, looks good in principle, but I am don't grok why we need
  ExecContext.bind_mounts? Can you elaborate?
 
 Hi Lennart,
 
 Originally we determined what bind mounts should be done in a child
 process each time we forked of a new process, and it was done after
 fork() in the child before executing target binary.
 
 Now, I've moved this computation to systemd itself and results are
 stored in ExecContext.bind_mounts set. Another reason was that, using
 former approach it was impossible to determine in pid 1, if we need to
 create tmpdir to be mounted as inaccessible for a child.

Not following really? Which bind mounts are these? For the inaccessible
dir stuff? But those are only visible in the per-service namespace, and
go away automatically of the service dies (because if all processes of a
service dies the namespace dies too). So I don't really understand why
we would have to keep track of this?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] DBus service name encoding

On Sun, 03.03.13 19:06, David Strauss (da...@davidstrauss.net) wrote:

 I can't find any documentation on how service names get encoded for
 DBus. It looks pretty close to URL encoding with underscores instead
 of percent signs.
 
 If I can get a definitive answer, I'll update the wiki. If I can't, I
 can, of course, dive into the source.

This hasn't been documented since it so far wasn't part of the official
ABI. So far you were supposed to invoke GetUnit() with an unescaped unit
name, and it would return you the (escaped) bus path for it. Now, a
while back systemctl was updated to simply do the escaping on the client
side, to get rid of this roundtrip. systemctl of course is shipped with
systemd, so it's not a problem for it to make use of this undocumented
behaviour. That said, we could (and probably should) just open this up
for external users too.

So here's how to do this, it's very simple: every char outside of the
A-Za-z0-9 range is escaped as _XY where XY is the numeric code of the
char, as 2 char lower-case hex value. Note that _ itself is also
escaped, to _5f.

This is implemented in bus_path_escape() in src/shared/util.c. 

If you want to make use of it, please update the wiki dbus docs for the
PID 1 interfaces, and document this there to make this official ABI, and
refer to the sources (and maybe this mail). Please also add a comment
line to the sources referring back to the wiki, so that people who
change bus_path_escape() are aware that this is something that is part
of the documented ABI.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-commits] 2 commits - Makefile.am src/fstab-generator units/initrd-cleanup.service units/initrd-parse-etc.service units/initrd-switch-root.service units/initrd-switch-root.

On Sat, 02.03.13 00:31, Tom Gundersen (t...@jklm.no) wrote:

 On Fri, Mar 1, 2013 at 11:23 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  Hi Tom,
 
  just to clarify:
 
  On Fri, Mar 01, 2013 at 01:49:53PM -0800, Tom Gundersen wrote:
  +ExecStart=/usr/bin/systemctl --no-block --force switch-root /sysroot
 
  In some other units @SYSTEMCTL@ is used. Is it because it is in
  initramfs?
 
  +ExecStart=-/usr/bin/udevadm info --cleanup-db
  ...and the same question about udevadm.
 
 Well, we could use SYSTEMCTL here too, but there is really no point in
 making this configurable in the initramfs (as it will be regenerated
 from scratch each time doing the usr-move is not a problem). I'd be
 happy to change it though.

I'd prefer if we'd always use @SYSTEMCTL@ here... Not because it would
matter technically, but because I know that people use copy/paste, and
I'd rather have the same code everywhere, than assume that people think
about whether they need it here or not...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Binary launched in ExecStartPre gets killed...

2013-03-04 Thread Belal, Awais

Hi,

I have a unit file which does something like this:
In ExecStartPre - Start A
In ExecStart - Start B

Now the thing is B depends on A to function correctly and A is a binary itself. 
The behavior I am seeing is a little obvious but still I thought there might be 
a way around this. When the unit is started A is launched correctly but then 
after some time it gets killed with a term signal 15 and this happens before B 
is started and hence when B is launched it fails. Here's what my unit file 
looks like...

[Unit]
Description=B
After=xyz.service

[Service]
EnvironmentFile=-/tmp/my.env
ExecStartPre=/bin/sh -c 'echo ADDRESS=`A --print-path`  /tmp/my.env'
ExecStart=/usr/bin/B

[Install]
WantedBy=graphical.target

Any suggestions here would be highly appreciated.

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

[systemd-devel] [HEADS-UP] When you commit something...

Heya,

if you commit something and it was previously posted on this ML, then
please please make sure to reply to the mail on the ML that you commited
it -- even if the original mail was your own! A short reply just saying
Commited. is totally sufficient. For patch series make clear if you
committed only individual bits, or all of them.

I am currently fighting against the backlog of unreviewed patches on
the ML, and it would help me greatly if I could easily determine if
something is already committed anyway.

[ For those wondering, our general patch application policy is the
  following: there are 16 people now with commit access. They are
  welcome to commit what they see fit, but should be careful, of
  course. In general we have some generalists who are welcome to commit
  anything they want, and some folks who focus on some areas. If you do
  not have commit access please send your patches for review to this
  ML. If you have commit access but you are unsure about something,
  please also post this to the ML. Alternatively post your patches to fdo
  bz or to rhbz (the latter only if your work has direct relevance to
  fedora/rhel or you are a fedora/rhel user). Usually sending things to
  the ML will give you quicker reviews, though. There are a few folks
  who scan the ML for unreviewed patches, especially before we prepare
  releases. Patches tend to get two or three reviews in our process:
  firstly when it is posted on the ML, if it is. Then, generalists such
  as Kay and Lennart are subscribed to the commit ML, and review
  whatever comes through there, and sometimes revert things (this
  happens, and it happens to the best, so don't be put off by that. I
  have myself reverted a couple of my own patches this way...). Shortly
  before a release I will scan the commits since the last release again,
  reviewing the final time, while preparing the NEWS file.

  This scheme currently works quite well, though I must admit that the
  number of unreviewed patches is a bit too long right now... ]

And that's all for now, please get hacking again!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Binary launched in ExecStartPre gets killed...

2013-03-04 Thread Zbigniew Jędrzejewski-Szmek

On Mon, Mar 04, 2013 at 11:02:36AM +, Belal, Awais wrote:
 Hi,
 
 I have a unit file which does something like this:
 In ExecStartPre - Start A
 In ExecStart - Start B
 
 Now the thing is B depends on A to function correctly and A is a binary 
 itself. The behavior I am seeing is a little obvious but still I thought 
 there might be a way around this. When the unit is started A is launched 
 correctly but then after some time it gets killed with a term signal 15 and 
 this happens before B is started and hence when B is launched it fails. 
 Here's what my unit file looks like...

Hi Awais,
things started from ExecStartPre are supposed to be short lived, and
everything remaining after ExecStartPre is done is killed.  If B
depends on A, then A and B should be separate units.

 [Unit]
 Description=B
 After=xyz.service
 
 [Service]
 EnvironmentFile=-/tmp/my.env
 ExecStartPre=/bin/sh -c 'echo ADDRESS=`A --print-path`  /tmp/my.env'
Security hole BTW.

 ExecStart=/usr/bin/B
 
 [Install]
 WantedBy=graphical.target
 
 Any suggestions here would be highly appreciated.
 
 BR,
 Awais

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

Re: [systemd-devel] Binary launched in ExecStartPre gets killed...

2013-03-04 Thread Kay Sievers

On Mon, Mar 4, 2013 at 12:02 PM, Belal, Awais awais_be...@mentor.com wrote:
 I have a unit file which does something like this:
 In ExecStartPre - Start A
 In ExecStart - Start B

 Now the thing is B depends on A to function correctly and A is a binary
 itself. The behavior I am seeing is a little obvious but still I thought
 there might be a way around this. When the unit is started A is launched
 correctly but then after some time it gets killed with a term signal 15 and
 this happens before B is started and hence when B is launched it fails.
 Here's what my unit file looks like...

 [Unit]
 Description=B
 After=xyz.service

 [Service]
 EnvironmentFile=-/tmp/my.env
 ExecStartPre=/bin/sh -c 'echo ADDRESS=`A --print-path`  /tmp/my.env'
 ExecStart=/usr/bin/B

 [Install]
 WantedBy=graphical.target

 Any suggestions here would be highly appreciated.

You cannot start any longer running services in Pre, we will clean
them up forcefully. If you have two services, use two service files
and express the dependencies between them.

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

Re: [systemd-devel] Binary launched in ExecStartPre gets killed...

2013-03-04 Thread Belal, Awais

Hi,

So how do i write such a service i.e. when A starts B should be started first 
and when A is stopped B should be stopped as well. I am really new to this so 
any pointers here would be really helpful. I understand that this is a very 
basic question but I am very new to this...

Regards

Awais

From: Kay Sievers [k...@vrfy.org]
Sent: Monday, March 04, 2013 7:54 PM
To: Belal, Awais
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] Binary launched in ExecStartPre gets killed...

On Mon, Mar 4, 2013 at 12:02 PM, Belal, Awais awais_be...@mentor.com wrote:
 I have a unit file which does something like this:
 In ExecStartPre - Start A
 In ExecStart - Start B

 Now the thing is B depends on A to function correctly and A is a binary
 itself. The behavior I am seeing is a little obvious but still I thought
 there might be a way around this. When the unit is started A is launched
 correctly but then after some time it gets killed with a term signal 15 and
 this happens before B is started and hence when B is launched it fails.
 Here's what my unit file looks like...

 [Unit]
 Description=B
 After=xyz.service

 [Service]
 EnvironmentFile=-/tmp/my.env
 ExecStartPre=/bin/sh -c 'echo ADDRESS=`A --print-path`  /tmp/my.env'
 ExecStart=/usr/bin/B

 [Install]
 WantedBy=graphical.target

 Any suggestions here would be highly appreciated.

You cannot start any longer running services in Pre, we will clean
them up forcefully. If you have two services, use two service files
and express the dependencies between them.

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

Re: [systemd-devel] [PATCH] bash-completion: split completions and move to new location

2013-03-04 Thread Michael Biebl

2013/3/4 Kay Sievers k...@vrfy.org:
 On Mon, Mar 4, 2013 at 12:18 AM, Michael Biebl mbi...@gmail.com wrote:
 2013/3/3 Michael Biebl mbi...@gmail.com:
 2013/3/3 Kay Sievers k...@vrfy.org:
 On Sat, Mar 2, 2013 at 10:46 PM, Michael Biebl mbi...@gmail.com wrote:
 That said, I can prep a follow-up patch, which makes that configurable
 and uses pkg-config --variable=completionsdir bash-completion.
 Pretty much
 what we do for --with-dbus*dir.

 Let me know if you also want the latter bits.

 Sounds good to me.

 Ok, will have a look then. Should be mostly CP from what is already
 in configure.ac.


 See attached patches.
 First one replaced pkg-config with $PKG_CONFIG (which we also
 recommend in man 7 daemon).
 The second makes bashcompletiondir configurable via
 --with-bashcompletiondir=DIR.

 If not specified, it will try $PKG_CONFIG --variable=completionsdir
 bash-completion.
 Since we don't want a hard build dependency on bash-completion, it
 will fall-back to ${datadir}/bash-completion/completions if
 bash-completion.pc is not installed.

 Ok to commit?

 Sure. Works fine here.


Ok, committed (with a few other, minor build system cleanups).

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] bash-completion: split completions and move to new location

2013-03-04 Thread Michael Biebl

2013/3/2 Michael Biebl mbi...@gmail.com:
 2013/3/2 Michael Biebl mbi...@gmail.com:
 I decided to split up the large completion file instead of using symlinks.
 The duplication is minimal and by splitting up, the files become much
 more readable and we only need to actually install those bits which
 are enabled via --config.

 One odd thing I noticed: Is it intentional that systemd-coredumpctl is
 built even when you use --disable-coredump? I would have expected that
 this binary would be built conditionally.

After a quick discussion on IRC we concluded, that building
systemd-coredumpctl conditionally is probably the correct thing to do.
So I'll move the binary along with the completion file inside the if
ENABLE_COREDUMP .. fi section.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Binary launched in ExecStartPre gets killed...

On Mon, 04.03.13 15:25, Belal, Awais (awais_be...@mentor.com) wrote:

 
 Hi,
 
 So how do i write such a service i.e. when A starts B should be
 started first and when A is stopped B should be stopped as well. I am
 really new to this so any pointers here would be really helpful. I
 understand that this is a very basic question but I am very new to
 this...

In this case write two normal .service files for these services. Then,
to link them together Add BindTo= to their [Unit] sections, pointing
to the other unit. This would then make sure, that if one is started,
the other is too, and if one is stopped the other is too, and both would
be equivalent (are they really? usually they aren't, but you description
above suggests two services where one cannot exist without the other,
and vice versa...). In addition to that add After=B.service to
A.service. (or, alternatively, Before=A.service to B.service, which
would be equivalent.) Please note that ordering deps are orthogonal to
requirement deps. That means that BindTo= does not imply ordering, and
hence you need both 'BindTo=' and 'After=' (or 'Before=') in the [Unit]
sections...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] encrypted swap

On Sat, 02.03.13 11:06, Stefan G. Weichinger (li...@xunil.at) wrote:

 
 Am 01.03.2013 19:39, schrieb Lennart Poettering:
 
  Can you provide the log where this happens? Boot with
  systemd.log_level=debug and provide us with the journalctl output around
  where this problem happens.
 
 I put up the output of journalctl -b here:
 
 https://dl.dropbox.com/u/24516209/systemd-bootlog.txt
 
 Maybe this -
 
 Mär 02 10:58:53 enzo.weichinger.name systemd-udevd[1827]: conflicting
 device node '/dev/mapper/swap' found, link to '/dev/dm-0' will not be
 created

This looks like your LVM/DM implementation is borked (compiled without
udev support?).

Please reporting this to the LVM/DM folks, this is something they need
to fix.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] DBus service name encoding

2013-03-04 Thread Simon McVittie

On 04/03/13 14:31, Lennart Poettering wrote:
 So here's how to do this, it's very simple: every char outside of the
 A-Za-z0-9 range is escaped as _XY where XY is the numeric code of the
 char, as 2 char lower-case hex value. Note that _ itself is also
 escaped, to _5f.

This sounds a lot like Telepathy's tp_escape_as_identifier(). Before
freezing this as ABI, you might want to consider a couple of the more
subtle points from that function:

* we also escape any leading digit in the same way, so that a name
  starting with a digit is escaped as a valid bus name component
  (123.service - _3123_2eservice, because the D-Bus specification
  says Only elements that are part of a unique connection name may
  begin with a digit)

* for completeness, we also escape  into _ (because a zero-length
  string is not a valid D-Bus name component)

This results in its output being a valid D-Bus bus-name element,
interface-name element, member, and object-path element, and also a
valid C identifier.

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

Re: [systemd-devel] encrypted swap

2013-03-04 Thread Stefan G. Weichinger

Am 04.03.2013 19:05, schrieb Lennart Poettering:

 This looks like your LVM/DM implementation is borked (compiled without
 udev support?).

lvm2-2.02.98 with udev-197 compiled in ... recompiled right now, still
waiting for timeout at boot.

 Please reporting this to the LVM/DM folks, this is something they need
 to fix.

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

Re: [systemd-devel] [PATCH 1/2] core: keep mountinfo .mounts until late shutdown

2013-03-04 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Feb 14, 2013 at 09:15:28PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, Feb 04, 2013 at 05:27:24PM +0100, Umut Tezduyar wrote:
  Hi
  
  On Mon, Feb 4, 2013 at 4:23 PM, Zbigniew Jędrzejewski-Szmek 
  zbys...@in.waw.pl wrote:
  
   Hi,
  
   On Mon, Feb 04, 2013 at 03:03:59PM +0100, Umut Tezduyar wrote:
Downside of this patch is, mountinfo mounts stick around as 
inactive-dead
even when the file system they represent is unmounted.
   
   
On Mon, Feb 4, 2013 at 3:00 PM, Umut Tezduyar u...@tezduyar.com wrote:
   
 .mount units coming from /proc/self/mountinfo file are
 unmounted after local-fs.target is reached during shutdown.

 Problem: .mount units popping up in mountinfo file are
 added to systemd without any dependency. For that reason,
   Hm, what do you mean exactly by that? Mount units I see have dependencies
   on mount points higher in the hierarchy. E.g.
   Requires=systemd-journald.socket -.mount home.mount
   After=systemd-journald.socket -.mount home.mount
   Description=/home/zbyszek/debian-x32/home
   SourcePath=/proc/self/mountinfo
  
  
  Mount units have dependencies on higher mount points but they do not have
  default dependencies like local-fs-pre.target, local-fs.target,
  umount.target. You can compare a mount unit coming from /etc/fstab with one
  /proc/self/mountinfo.
 Hi,
 
 I think that an addition of relationships with other units is necessary.
 But adding RequiredBy=local-fs.target,Before=local-fs.target doesn't
 seem to be the right combination.
 
 Before=local-fs.target - OK.
 RequiredBy=local-fs.target - This one doesn't seem to be necessary. In
practice there's little difference since alread-mounted mounts can't
fail, but it's better to keep the dependency graph sparse.
 Conflicts=umount.target - I think that we want this one. Without this,
mounts added by hand will be left till the very end, but there's
no reason to make them special like this.
Ping?

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

Re: [systemd-devel] Binary launched in ExecStartPre gets killed...

2013-03-04 Thread Tomasz Torcz

On Mon, Mar 04, 2013 at 07:01:01PM +0100, Lennart Poettering wrote:
 On Mon, 04.03.13 15:25, Belal, Awais (awais_be...@mentor.com) wrote:
 
  
  Hi,
  
  So how do i write such a service i.e. when A starts B should be
  started first and when A is stopped B should be stopped as well. I am
  really new to this so any pointers here would be really helpful. I
  understand that this is a very basic question but I am very new to
  this...
 
 In this case write two normal .service files for these services. Then,
 to link them together Add BindTo= to their [Unit] sections, pointing
 to the other unit. This would then make sure, that if one is started,
 the other is too, and if one is stopped the other is too, and both would
 be equivalent (are they really? usually they aren't, but you description
 above suggests two services where one cannot exist without the other,
 and vice versa...). In addition to that add After=B.service to
 A.service. (or, alternatively, Before=A.service to B.service, which
 would be equivalent.) Please note that ordering deps are orthogonal to
 requirement deps. That means that BindTo= does not imply ordering, and
 hence you need both 'BindTo=' and 'After=' (or 'Before=') in the [Unit]
 sections...

  Lennart, I think we need a blog entry with clear description how to handle
situations when service consist of multiple units.  Some clear recommendation
when to use BindTo=, PartOf=, targets and such.  Pretty please :)


-- 
Tomasz Torcz   RIP is irrevelant. Spoofing is futile.
xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev

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

Re: [systemd-devel] [systemd-commits] 3 commits - Makefile.am src/core src/fstab-generator units/initrd-cleanup.service units/initrd-fs-pre.target units/initrd-fs.target units/initrd-parse-etc.service

On Mon, 04.03.13 10:43, Harald Hoyer (har...@kemper.freedesktop.org) wrote:

 +if (initrd) {
 +char _cleanup_free_ *mu = NULL, *name = NULL;
 +/* Skip generation, if unit already exists */
 +name = unit_name_from_path(where, .mount);
 +if (!name)
 +return log_oom();
 +mu = strjoin(arg_dest, /, name, NULL);
 +if (!mu)
 +return log_oom();
 +
 +k = access(mu, R_OK);
 +if (k == 0)
 +continue;
 +}

Ahum. I can't say I like invocations to access() like this one. There
are very few cases where access() is the right syscall to invoke, and I
am pretty sure this is not one of them, due to its inherent
raciness. There might be other generators running in parallel to this
one, so the existance of the mount unit might have already changed by
the time you then go on and actually create the unit file. So, your
test here doesn't work and is pointless.

Please folks, be very careful with access()! Uses like this are broken,
you want to rely on O_EXCL (or fopen's x) instead, to ensure the file
is only created if it doesn't exist yet, and that is atomic.

Quite frankly, the majority of the uses of access()es I have seen in my
life are misuses, people really should keep the atomicity of things in mind. 

  static int parse_new_root_from_proc_cmdline(void) {
  char *w, *state;
 -_cleanup_free_ char *what = NULL, *type = NULL, *opts = NULL, *line 
 = NULL;
 +_cleanup_free_ char *what = NULL, *type = NULL, *opts = NULL, *line 
 = NULL, *mu = NULL;
  int r;
  size_t l;
  
 +/* Skip generation, if sysroot.mount already exists */
 +mu = strjoin(arg_dest, /, sysroot.mount, NULL);
 +if (!mu)
 +return log_oom();
 +
 +r = access(mu, R_OK);
 +if (r == 0)
 +return 0;
 +

Same here. Also: indentation is borked.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] initrd-fs.target

On Mon, 04.03.13 20:09, Harald Hoyer (harald.ho...@gmail.com) wrote:

 http://cgit.freedesktop.org/systemd/systemd/commit/?id=8330847e949fc0c26b16910e5240eef1fe2c330a

I would have preferred if this patch had been posted on the ML first
before it was commited.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] DBus service name encoding

2013-03-04 Thread David Strauss

On Mon, Mar 4, 2013 at 11:00 AM, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
 Before freezing this as ABI, you might want to consider a couple of the more
 subtle points from that function

Considering that those two suggestions cover cases not yet handled by
systemd's still-informal specification, I see no reason to object.

-- 
David Strauss
   | da...@davidstrauss.net
   | +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] initrd-fs.target

Hi Harald,

On Tue, Mar 5, 2013 at 4:09 AM, Harald Hoyer harald.ho...@gmail.com wrote:
 please review

Could you comment on why this is necessary? It would be nice if we
could reuse as much as possible from the real root rather than making
initrd-spcific files, but perhaps it is not possible in this case?

I am aware of one problem that your patch solves (at least for this
particular case).

When we switch root we use JOB_REPLACE to default.target. This means
that units which are pulled in by default.target, but already active
in the initrd (such as local-fs.target) will not be pulled in again,
so if they get new dependencies (in this case the entries from the
real /etc/fstab) these are not started. I was going to suggest solving
this by using JOB_ISOLATE when switching root, but didn't yet have the
chance to check if this causes any problems. Did you consider this, or
did you have a different reason for the patch?

 http://cgit.freedesktop.org/systemd/systemd/commit/?id=39b83cdab37623a546344622db9bbbc784c15df5

The new target references the systemd.special manpag, but does not update it.

 http://cgit.freedesktop.org/systemd/systemd/commit/?id=7d89ce303fb59743a4392eeb3110c00f100172ca

Why is it necessary to start initrd-fs.target in addition to Require it?

 http://cgit.freedesktop.org/systemd/systemd/commit/?id=8330847e949fc0c26b16910e5240eef1fe2c330a

Hm, wouldn't this mean that any other storage related service we might
want to include in the initrd would have to be special-cased to deal
with initrd-fs rather than local-fs?

Why do you need the 'skip generation of sysroot.mount if exists'
logic? Shouldn't we just generate it in the correct generator
directory?

I think you changed the priority order of /proc/cmdline, /etc/fstab
and /sysroot/etc/fstab, could you comment on why it is the way it is?

I think /sysroot/etc/fstab should have the highest priority, as that
what will be used to remount the filesystems in the real root (I have
patches to do the remounting in the initrd to avoid doing any mounting
twice, but that's a separate issue), and that /etc/fstab should have
the lowest as it has to be set at initrd generation time. What do you
think?

Cheers,

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

[systemd-devel] Python wrappers for the DBus API

2013-03-04 Thread David Strauss

We're about to code a Python wrapper for systemd's DBus functionality.
Initially, it will be non-comprehensive and satisfy our internal
Pantheon goal of reading fields on a service and manipulating services
without forking and parsing systemctl output to do either.

But, a clean, incomplete implementation is a great way to kick off
more barn-raising [1] in the community, so we're aiming for upstream
integration. It's been awesome to see the journal wrappers evolve well
beyond the initial, bare-bones send-to-the-journal code [2].

Does anyone have in mind any brilliantly Pythonic way to expose the
DBus unit and systemd core APIs?

Should there be a Python class model that mirrors the systemd unit
abstract class and litany of concrete classes (like mount,
service, etc.)? Or is it better to keep the Python code minimal to
ease long-term maintenance as new unit types emerge?

Unlike the journal wrappers, this code will probably be 100% regular
Python. DBus Python support is a well-maintained part of many major
distros, and it's great to leverage that.

[1] http://meatballwiki.org/wiki/BarnRaising
[2] https://github.com/systemd/python-systemd

--
David Strauss
   | da...@davidstrauss.net
   | +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] initrd-fs.target

Am 05.03.2013 06:26, schrieb Tom Gundersen:
Hi Harald,

On Tue, Mar 5, 2013 at 4:09 AM, Harald Hoyer harald.ho...@gmail.com wrote:
please review

Could you comment on why this is necessary? It would be nice if we
could reuse as much as possible from the real root rather than making
initrd-spcific files, but perhaps it is not possible in this case?

I am aware of one problem that your patch solves (at least for this
particular case).

When we switch root we use JOB_REPLACE to default.target. This means
that units which are pulled in by default.target, but already active
in the initrd (such as local-fs.target) will not be pulled in again,
so if they get new dependencies (in this case the entries from the
real /etc/fstab) these are not started. I was going to suggest solving
this by using JOB_ISOLATE when switching root, but didn't yet have the
chance to check if this causes any problems. Did you consider this, or
did you have a different reason for the patch?

Yes, this is the problem. local-fs.target would be already active and e.g.
systemd-remount-fs.service is never started,

http://cgit.freedesktop.org/systemd/systemd/commit/?id=39b83cdab37623a546344622db9bbbc784c15df5

The new target references the systemd.special manpag, but does not update it.

True... will fix.

http://cgit.freedesktop.org/systemd/systemd/commit/?id=7d89ce303fb59743a4392eeb3110c00f100172ca

Why is it necessary to start initrd-fs.target in addition to Require it?

All the newly generated mount units are not started, because initrd-fs.target is
already active.

http://cgit.freedesktop.org/systemd/systemd/commit/?id=8330847e949fc0c26b16910e5240eef1fe2c330a

Hm, wouldn't this mean that any other storage related service we might
want to include in the initrd would have to be special-cased to deal
with initrd-fs rather than local-fs?

Yes, but local-fs is still active in the initrd. Of course, if there is a
possibility to avoid this, I am all for it.

Why do you need the 'skip generation of sysroot.mount if exists'
logic? Shouldn't we just generate it in the correct generator
directory?

This was for the /run/systemd/generator/*.mount units, that the fstab-generator
already generated itsself.

/run/systemd/generator/ is emptied anyway on daemon-reload.

I think you changed the priority order of /proc/cmdline, /etc/fstab
and /sysroot/etc/fstab, could you comment on why it is the way it is?

Ok, I started to write my arguments five times now and every time I find my
arguments are flawed... I'll revert this patch.

I think /sysroot/etc/fstab should have the highest priority, as that
what will be used to remount the filesystems in the real root (I have
patches to do the remounting in the initrd to avoid doing any mounting
twice, but that's a separate issue), and that /etc/fstab should have
the lowest as it has to be set at initrd generation time. What do you
think?

Yes, that would be the ideal way (as we do in dracut now).

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

[systemd-devel] [PATCH 2/4] fstab-generator: skip generation, if sysroot.mount already exists

2013-03-04 Thread harald

From: Harald Hoyer har...@redhat.com

---
 src/fstab-generator/fstab-generator.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/fstab-generator/fstab-generator.c 
b/src/fstab-generator/fstab-generator.c
index fade192..3b8329b 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -450,10 +450,19 @@ finish:
 
 static int parse_new_root_from_proc_cmdline(void) {
 char *w, *state;
-_cleanup_free_ char *what = NULL, *type = NULL, *opts = NULL, *line = 
NULL;
+_cleanup_free_ char *what = NULL, *type = NULL, *opts = NULL, *line = 
NULL, *mu = NULL;
 int r;
 size_t l;
 
+/* Skip generation, if sysroot.mount already exists */
+mu = strjoin(arg_dest, /, sysroot.mount, NULL);
+if (!mu)
+return log_oom();
+
+r = access(mu, R_OK);
+if (r == 0)
+return 0;
+
 r = read_one_line_file(/proc/cmdline, line);
 if (r  0) {
 log_error(Failed to read /proc/cmdline, ignoring: %s, 
strerror(-r));
-- 
1.8.1

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

[systemd-devel] [PATCH 4/4] -removed-

... was the change in the priority ordering.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [RFC][PATCH] main: ISOLATE rather than REPLACE default.target

This allows switch-root to work correctly if a unit is active both before and
after the switch-root, but its dependencies change. Before the patch, any
dependencies added to active units by switch-root will not be pulled, in
particular filesystems configured in /etc/fstab would not be activated if
local-fs.target was active in the initrd.

It is not clear to me if there is a bug in the REPLACE handling, or if it is
working as expected and that we really want to use ISOLATE instead as this patch
does.

Comments?

Cc: Harald Hoyer harald.ho...@gmail.com
---
 src/core/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/core/main.c b/src/core/main.c
index 71e0a6c..2bbea7e 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1720,7 +1720,7 @@ int main(int argc, char *argv[]) {
 manager_dump_units(m, stdout, \t);
 }
 
-r = manager_add_job(m, JOB_START, target, JOB_REPLACE, false, 
error, default_unit_job);
+r = manager_add_job(m, JOB_START, target, JOB_ISOLATE, false, 
error, default_unit_job);
 if (r  0) {
 log_error(Failed to start default target: %s, 
bus_error(error, r));
 dbus_error_free(error);
-- 
1.8.1.5

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

Re: [systemd-devel] initrd-fs.target

On Tue, Mar 5, 2013 at 3:22 PM, Harald Hoyer harald.ho...@gmail.com wrote:
Am 05.03.2013 06:26, schrieb Tom Gundersen:
When we switch root we use JOB_REPLACE to default.target. This means
that units which are pulled in by default.target, but already active
in the initrd (such as local-fs.target) will not be pulled in again,
so if they get new dependencies (in this case the entries from the
real /etc/fstab) these are not started. I was going to suggest solving
this by using JOB_ISOLATE when switching root, but didn't yet have the
chance to check if this causes any problems. Did you consider this, or
did you have a different reason for the patch?

Yes, this is the problem. local-fs.target would be already active and e.g.
systemd-remount-fs.service is never started,

I posted the alternative fix that I have been using locally. What do
you think of that?

http://cgit.freedesktop.org/systemd/systemd/commit/?id=7d89ce303fb59743a4392eeb3110c00f100172ca

Why is it necessary to start initrd-fs.target in addition to Require it?

All the newly generated mount units are not started, because initrd-fs.target
is
already active.

Hm, for me this works because the initrd-switch-root.target pulls in
the fs.target and is isolated. Having another look at these units I
think we can probably drop initrd-cleanup.service (merge it into
initrd-parse-etc.service), which should make things a bit clearer...

Why do you need the 'skip generation of sysroot.mount if exists'
logic? Shouldn't we just generate it in the correct generator
directory?

This was for the /run/systemd/generator/*.mount units, that the
fstab-generator
already generated itsself.

/run/systemd/generator/ is emptied anyway on daemon-reload.

Right, but if we call these functions in the right order, and
sysroot.mount is configured more than once (in both /proc/cmdline and
/etc/fstab), then the one from /proc/cmdline will be used and the
generation of the second unit will simply fail, won't it?

Yes, that would be the ideal way (as we do in dracut now).

Ok, I'll implement this when I get a chance (unless you beat me to it).

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

Re: [systemd-devel] [RFC][PATCH] main: ISOLATE rather than REPLACE default.target

Am 05.03.2013 07:56, schrieb Tom Gundersen:
 This allows switch-root to work correctly if a unit is active both before and
 after the switch-root, but its dependencies change. Before the patch, any
 dependencies added to active units by switch-root will not be pulled, in
 particular filesystems configured in /etc/fstab would not be activated if
 local-fs.target was active in the initrd.
 
 It is not clear to me if there is a bug in the REPLACE handling, or if it is
 working as expected and that we really want to use ISOLATE instead as this 
 patch
 does.
 
 Comments?
 
 Cc: Harald Hoyer harald.ho...@gmail.com
 ---
  src/core/main.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/core/main.c b/src/core/main.c
 index 71e0a6c..2bbea7e 100644
 --- a/src/core/main.c
 +++ b/src/core/main.c
 @@ -1720,7 +1720,7 @@ int main(int argc, char *argv[]) {
  manager_dump_units(m, stdout, \t);
  }
  
 -r = manager_add_job(m, JOB_START, target, JOB_REPLACE, 
 false, error, default_unit_job);
 +r = manager_add_job(m, JOB_START, target, JOB_ISOLATE, 
 false, error, default_unit_job);
  if (r  0) {
  log_error(Failed to start default target: %s, 
 bus_error(error, r));
  dbus_error_free(error);
 

I think the idea was to allow service to be started in the initramfs and be
active even until the pivot() shutdown.

Now, that I think of it, such services can have IgnoreOnIsolate=yes.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Python wrappers for the DBus API

2013-03-04 Thread Holger Winkelmann

I Like the idea as well to have direct DBus access to systemd.

Regarding your example of the journal wrapper. Anybody knows the API to write 
to the journal without using the C library? Is this DBus transport as well? Or 
is there a special journal socket to write to?

--
Holger

### Sent from a mobile device. Sorry for brevity and typos... ###

On 05.03.2013, at 06:41, David Strauss da...@davidstrauss.net wrote:

 We're about to code a Python wrapper for systemd's DBus functionality.
 Initially, it will be non-comprehensive and satisfy our internal
 Pantheon goal of reading fields on a service and manipulating services
 without forking and parsing systemctl output to do either.
 
 But, a clean, incomplete implementation is a great way to kick off
 more barn-raising [1] in the community, so we're aiming for upstream
 integration. It's been awesome to see the journal wrappers evolve well
 beyond the initial, bare-bones send-to-the-journal code [2].
 
 Does anyone have in mind any brilliantly Pythonic way to expose the
 DBus unit and systemd core APIs?
 
 Should there be a Python class model that mirrors the systemd unit
 abstract class and litany of concrete classes (like mount,
 service, etc.)? Or is it better to keep the Python code minimal to
 ease long-term maintenance as new unit types emerge?
 
 Unlike the journal wrappers, this code will probably be 100% regular
 Python. DBus Python support is a well-maintained part of many major
 distros, and it's great to leverage that.
 
 [1] http://meatballwiki.org/wiki/BarnRaising
 [2] https://github.com/systemd/python-systemd
 
 --
 David Strauss
   | da...@davidstrauss.net
   | +1 512 577 5827 [mobile]
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC][PATCH] main: ISOLATE rather than REPLACE default.target

On Tue, Mar 5, 2013 at 4:14 PM, Harald Hoyer harald.ho...@gmail.com wrote:
 Am 05.03.2013 07:56, schrieb Tom Gundersen:
 This allows switch-root to work correctly if a unit is active both before and
 after the switch-root, but its dependencies change. Before the patch, any
 dependencies added to active units by switch-root will not be pulled, in
 particular filesystems configured in /etc/fstab would not be activated if
 local-fs.target was active in the initrd.

 It is not clear to me if there is a bug in the REPLACE handling, or if it is
 working as expected and that we really want to use ISOLATE instead as this 
 patch
 does.

 I think the idea was to allow service to be started in the initramfs and be
 active even until the pivot() shutdown.

 Now, that I think of it, such services can have IgnoreOnIsolate=yes.

That, or they could simply be enabled in the real root. Depends on the
service I guess.

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

Re: [systemd-devel] initrd-fs.target