[systemd-devel] OSTree mount integration
So I have this "boot into chroot" system that I wrote for GNOME: https://live.gnome.org/OSTree/ Where the two interesting aspects here are: 1) I want the ability to allow people to try GNOME builds natively without destroying their root partition - hence, chroots. 2) This allows for fully atomic upgrades. Now, basically right now systemd doesn't understand the fact that it's in a chroot, and fails to do things like remount the rootfs read-only when rebooting, etc. https://live.gnome.org/OSTree/MultipleRoots Is there any opposition to having systemd support this setup? It already detects virtualization and containers at the moment, so it seems like it'd make sense. I'm totally willing to change around the bind mount setup, but I think the most basic support is going to be basically just looking for the root filesystem on /sysroot instead of /. If there's no objections I'll be looking at doing some patches for the GNOME 3.8 cycle. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd segfaulting after commit 877d54e9b09e093c2102f519a84e2a52637ae035
On Sun, 23 Sep 2012, Colin Walters wrote: On Sat, 2012-09-22 at 16:34 -0700, Khem Raj wrote: git bisect tells me that its happening due to commit 877d54e9b09e093c2102f519a84e2a52637ae035 Author: Lennart Poettering Date: Fri Aug 24 22:21:20 2012 +0200 journal: generate structured journal messages for a number of events I am using gcc 4.7.2 + glibc 2.16 + binutils 2.22 + kernel 3.4.10 I get this too in GNOME-OSTree (fork of Poky edison, gcc 4.6, eglibc 2.13). I had been thinking it was http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47025 [...] I think it's https://bugs.freedesktop.org/show_bug.cgi?id=55213 The reporter explains clearly that the new journald code invokes undefined behavior in relation to vsnprintf() and vasprintf(): it may work on some systems but in general cannot be relied upon to work, and it segfaults on some systems. The reporter also provides a patch. -- Allin Cottrell Department of Economics Wake Forest University, NC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Best way of configuring service
Dear all,
I porting the start scripts of cruisecontrol system to the native systemd
service configuration. It goes quiet well, the only "trouble" I have with the
options configuration.
Since cruisecontrol is written in Java, there are two ways of how to configure
the daemon (and CC use them both): -D java properties and "classic" command
line options passed to the main jar.
I want to have the whole service highly configurable, So I have decided to
define Environment= item for each particular option. The result looks like:
Environment=cc.prop.item1="-Dcc.XXX=value1"
Environment=cc.prop.item2="-Dcc.XXX=value1"
Environment=cc.prop.item3="-Dcc.XXX=value1"
Environment=cc.prop.item4=
Environment=cc.prop.item5=
Environment=cc.opt.item1=-opt1 val1
Environment=cc.opt.item2=-opt2 val2
Environment=cc.opt.item3=-opt3 val3
Environment=cc.opt.item4=
Environment=cc.opt.item4=
Environment=cc.install.dir=/usr/shared/cruisecontrol
Where those undefined are left for user to be able to override the
configuration, since they MUST appear in the ExecStart= item which looks like:
ExecStart=/usr/bin/java -Dcc.install.dir=-Dcc.install.dir${cc.install.dir} -cp
${cc.install.dir}/dist $cc.prop.item1 $cc.prop.item2 ... $cc.prop.item5
-jar cruisecontrol-launcher.jar $cc.opt.item1
$cc.opt.item2 ... $cc.opt.item5
In this way, the user should be able to customize everything in
/etc/systemd/system/ configuration, simply re-defining the appropriate
Environment definitions.
However, there are two issues Iike to clarify:
1)
As you could see, one variable is used in two cases - particularly it is:
-Dcc.install.dir=-Dcc.install.dir${cc.install.dir} -cp ${cc.install.dir}/dist
I have observed that the env must be used in form ${XXX} when it is the part
of larger string (despite the form ${XXX} having its "special" meaning).
So the question is: do I it right? Is the concept I have chosen correct?
2)
The second issue is that (if I understand it right) everything I define by
Environment= will appear in ENV variables of the process started. Is is true?
What If I don't want to export those variables to the service? I would guess
that it is the reason why -D properties are used instead of "raw" ENV
variables (which could simply be used as well)
Also, I have found the inability to resolve env definitions in other env
definitions being quiet limiting (although I suppose that some others are
complaining as well :-)) ).
So, I would like to ask you for your advice - what is the best way of handling
those two issues? What do you recommend to daemon upstream developers?
It seems to me that the purpose of ENV variables is slightly bit different from
using as constant definitions for ExecStart= command simplification (even shell
does not export them unless explicitly told, doesn't it). Although I may be
completely wrong.
Thank you and I wish you many happy system admins (anyway, I see systemd as
the best init system with the highest potential).
Best regards,
Dan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd segfaulting after commit 877d54e9b09e093c2102f519a84e2a52637ae035
On Sat, 2012-09-22 at 16:34 -0700, Khem Raj wrote: > git bisect tells me that its happening due to > > commit 877d54e9b09e093c2102f519a84e2a52637ae035 > Author: Lennart Poettering > Date: Fri Aug 24 22:21:20 2012 +0200 > > journal: generate structured journal messages for a number of events > > > I am using gcc 4.7.2 + glibc 2.16 + binutils 2.22 + kernel 3.4.10 I get this too in GNOME-OSTree (fork of Poky edison, gcc 4.6, eglibc 2.13). I had been thinking it was http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47025 I was going to rebase to a newer toolchain after GNOME 3.6, but that theory seems out because you have 4.7 which should have that fix. Does this test program also fail for you? http://people.gnome.org/~walters/systemd-vsnprintf-test.c It does for me, which implies it's a toolchain bug. Where exactly though is the question... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
I responded too early, mdadm has caused its own set of problems: - During the boot process, the mdXpX.device don't get marked as active automatically causing X.mount based on those devices to fail. Once I get to the emergency shell, simply calling 'systemctl daemon-reload' reloads the mdXpX.device items which are now marked as active (why?). I have worked around this problem by building a new oneshot service which calls 'systemctl daemon-reload' before attempting to use the X.mount items. I also had to move the offending partitions to 'noauto,comment=systemd.automount' so that a suitable delay was put in between the mdadm setup and reloading the modules otherwise systemd-remount-fs.service wouldn't get started (for some reason)! - Cryptsetup on the mdXpX device still fails when it is called, though this time I get a more useful response other than 'timeout': Sep 23 18:06:29 alipc-desktop-ex sudo[3636]: ali : TTY=pts/4 ; PWD=/home/ali ; USER=root ; COMMAND=/usr/bin/systemctl start home-ali-m Sep 23 18:06:29 alipc-desktop-ex sudo[3636]: pam_unix(sudo:session): session opened for user root by (uid=0) Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Starting Cryptography Setup for cryptmedia... Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Expecting device dev-mapper-cryptmedia.device... Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Starting Forward Password Requests to Wall... Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Starting Dispatch Password Requests to Console... Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Started Dispatch Password Requests to Console. Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Stopping Dispatch Password Requests to Console Directory Watch. Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Stopped Dispatch Password Requests to Console Directory Watch. Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Stopping Dispatch Password Requests to Console... Sep 23 18:06:29 alipc-desktop-ex systemctl[3641]: Failed to issue method call: Unit systemd-ask-password-plymouth.path not loaded. Sep 23 18:06:29 alipc-desktop-ex systemctl[3641]: Failed to issue method call: Unit systemd-ask-password-plymouth.service not loaded. Sep 23 18:06:38 alipc-desktop-ex systemd-cryptsetup[3640]: Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/md Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Started Cryptography Setup for cryptmedia. Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Dependency failed for /home/ali/media. Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Job home-ali-media.mount/start failed with result 'dependency'. Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Unmounted /home/ali/media. Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Stopped dev-mapper-cryptmedia.device. Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Stopping Cryptography Setup for cryptmedia... Sep 23 18:06:39 alipc-desktop-ex sudo[3636]: pam_unix(sudo:session): session closed for user root Sep 23 18:06:39 alipc-desktop-ex systemd-udevd[3644]: conflicting device node '/dev/mapper/cryptmedia' found, link to '/dev/dm-0' will Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Found device /dev/disk/by-uuid/df808cdc-73c2-4bd0-8fdc-53a5251a8030. Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Found device /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-1aca68ec78a8433081cfc1c3510fe8df-cryptme Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Found device /dev/disk/by-id/dm-name-cryptmedia. Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Found device /dev/dm-0. Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Found device /sys/devices/virtual/block/dm-0. Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Expecting device /dev/md1p5... The 'conflicting device node' is an interesting message, since I don't see how it can be conflicting with anything... Thanks. Ali On 22 September 2012 12:43, Ali Lown wrote: > I waited until the weekend so I could take down the devices briefly. > After converting to use md instead, I can confirm that systemd is > working fine with automounting the luks partition and correctly asking > for a passphrase. > > The migration I used was: > dmraid -an #disable dmraid devices > mdadm --create /dev/md0 --level=1 --raid-devices=2 --metadata=0.90 > /dev/sdb /dev/sdc > I chose to use v0.9 since I wanted kernel autodetect with needing to > maintain an initramfs as well. > > Currently the disks are resyncing (and will be for the next few hours). > > Shall I take this as a sign that dmraid is being deprecated in the linux > world? > > On 17 September 2012 13:57, Alexander E. Patrakov wrote: >> 2012/9/17 Ali Lown : >>> I am unable to get systemd to mount a LUKS partition on boot. This >>> LUKS partition (pdc_bhjchdjgaep5) sits on top of a fakeraid mirror set >>> (pdc_bhjchdjgae) of 2TB disks (sdd,sde). >> >> Disclaimer: what I am proposing below is not a solution, just a workaround. >> >> Now that a normal "md" raid is able to assemble fake RAIDs perviously >> handled by dmraid, could you please try to migrate? Just try to >> assemble md raid as usual, obv
[systemd-devel] Hang when mounting NFS via systemd
Hi all, (Hopefully this list is appropriate for this -- please let me know if there's a more appropriate one.) I'm having a little trouble with NFS mounts when starting them via systemd, but I'm hoping that I may have missed something obvious. Here's the snippet from /etc/fstab: 192.168.0.1:/srv/vg0p-data /data nfs \ defaults,proto=tcp,nfsvers=4,vers=4,noauto 0 1 (Line split here for readability, it's a single line in the actual file.) When I run # systemctl --version systemd 189 arch +PAM -LIBWRAP -AUDIT -SELINUX -IMA -SYSVINIT \ +LIBCRYPTSETUP +GCRYPT +ACL +XZ # systemctl start data.mount I get the output A dependency job failed. See system journal for details. after a longish timeout (guessing it's the default 90s). In the journal I get: Sep 23 17:08:45 gwendolyn systemd[1]: Job 192.168.0.1:-srv-vg0p\x2ddata.device/start timed out. Sep 23 17:08:45 gwendolyn systemd[1]: Job data.mount/start failed with result 'dependency'. Sep 23 17:08:45 gwendolyn systemd[1]: Job systemd-fsck@192.168.0.1:-srv-vg0p\x2ddata.service/start failed with result 'dependency'. Sep 23 17:08:45 gwendolyn systemd[1]: Job 192.168.0.1:-srv-vg0p\x2ddata.device/start failed with result 'timeout'. (The exact same thing happens on first access if I use automounting, or if remove "noauto" -- the hang just happens during first access and at boot time respectively.) The weird thing is that the mount works perfectly if I just mount normally: # mount /data # ls -l /data total 696 drwx-- 2 root root 4096 Jul 15 2011 lost+found ... (other content omitted for privacy reasons.) Any hints/ideas as to what might be wrong? I mean it *should* work, right? Cheers, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Various bug fixes
n Fri, Sep 21, 2012 at 4:30 PM, Lennart Poettering wrote: > On Fri, 21.09.12 15:25, Václav Pavlín (vpav...@redhat.com) wrote: > >> You can find few patches for various bugs in attachement. > > Thanks! > > I'll let Kay merge the udev related patches. The rest I merged, with a > few exceptions: Václav, please check: http://cgit.freedesktop.org/systemd/systemd/commit/?id=0820a4f0f6d6c264339a501a4352c22af26c5300 For some reason 0010 had: rules->dirs_ts_usec = calloc(strv_length(rules->dirs), sizeof(long long)); duplicated and I just removed it. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can't get systemd-cryptsetup to automount my /home
On Sun, Sep 23, 2012 at 01:33:52PM +0200, Dennis Ek wrote: > First of all: I'm running the latest Arch Linux (complete with the latest > systemd and everything else) and I've encrypted both my / and /home. > > Now, the problem is that I can't get my /home to automount once I've > mounted my /. My /etc/crypttab looks like this: > home /dev/sda3 /etc/homepwd > > I've created /etc/homepwd using > echo password > /etc/homepwd Just guessing here, but "The third field, key file, describes the file to use as a key for decrypting the data of the source device. Note that the entire key file will be used as the passphase; the passphase must not be followed by a newline character." Does it work with 'echo -n ...'? Also, you should put something in the fourth field. According to the manpage the fourth field is mandatory. In the log below it says that the options used were aes, xts-plain, key size 512 bits. Is that correct? > And yes, I've entered the correct password. > > When I boot I get dropped to a rescue shell because I can't mount /home. > Here's my journalctl output: > systemd-cryptsetup[293]: Invalid passphrase. > systemd-cryptsetup[293]: Set cipher aes, mode xts-plain, key size 512 bits > for device /dev/sda3. > systemd-cryptsetup[293]: Invalid passphrase. > systemd-cryptsetup[293]: Too many attempts. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Can't get systemd-cryptsetup to automount my /home
First of all: I'm running the latest Arch Linux (complete with the latest systemd and everything else) and I've encrypted both my / and /home. Now, the problem is that I can't get my /home to automount once I've mounted my /. My /etc/crypttab looks like this: home /dev/sda3 /etc/homepwd I've created /etc/homepwd using echo password > /etc/homepwd And yes, I've entered the correct password. When I boot I get dropped to a rescue shell because I can't mount /home. Here's my journalctl output: systemd-cryptsetup[293]: Invalid passphrase. systemd-cryptsetup[293]: Set cipher aes, mode xts-plain, key size 512 bits for device /dev/sda3. systemd-cryptsetup[293]: Invalid passphrase. systemd-cryptsetup[293]: Too many attempts. I've tried playing with the permissions (even did a chmod 777), but I still can't get systemd-cryptsetup to realize that the file contains the correct password. So, what to do? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
