Re: [systemd-devel] Regression: loop device detach errors in 220
Thanks for the report. This should hopefully be fixed by https://github.com/systemd/systemd/pull/65 Cheers, Tom On Wed, Jun 3, 2015 at 5:34 PM, Jan Janssen medhe...@web.de wrote: Hi, systemd-shutdown in 220 has errors when detaching loop devices: systemd-shutdown[1]: Failed to detach loop devices: Invalid argument cgroup: option or name mismatch, new: 0x0 , old: 0x4 systemd systemd-shutdown[1]: Failed to detach loop devices: Invalid argument systemd-shutdown[1]: Failed to detach loop devices: Invalid argument systemd-shutdown[1]: Failed to finalize _ loop devices, ignoring https://bugs.archlinux.org/task/45111 c32eb440bab953a0169cd207dfef5cad16dfb340 is the first bad commit Author: Tom Gundersen t...@jklm.no Date: Tue Apr 14 16:25:06 2015 +0200 libudev: make libudev-enumerate a thin wrapper around sd-device :100644 100644 837fd36381315029171562b344dca8620528d327 68d8252b84c13591cf8e0b0e15a99780f5dd0309 M Makefile.am :04 04 c54e32bc21e34cc28693fbf653c4128a0383d3d7 11e1eeec94338e9294e25e720007c35f229d24cf M src Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
Hi Greg, On 05/28/2015 03:30 PM, Greg KH wrote: On Thu, May 28, 2015 at 01:53:57PM -0500, Mario Limonciello wrote: On 05/28/2015 01:46 PM, Greg KH wrote: You can't guarantee that there is another GPU to display things on. Yes you can. Wait, what? No, you can't. 1) Not everyone has multiple monitors plugged into multiple GPU's. True. 2) The system ships with a dGPU and supports an xGPU. If you remove the dGPU from the chassis, all you have is the xGPU. If you unplug xGPU, there's nothing left.. And how does other operating systems handle this? Hint, I don't imagine they reboot the box... greg k-h Sorry for taking so long to respond to this, I had clarified with HW marketing the expected experience on Win10 with the graphics amplifier on this hardware. Hot dock and undock is NOT supported. User must reboot for the internal dGPU to be used after a surprise unplug. If the cable was replugged after a surprise unplug there is no expectation that it continues to function. If no other GPUs are on the system (such as dGPU not installed) then the system will need to be turned off and back on. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
On 05/29/2015 04:22 AM, Lennart Poettering wrote: On Thu, 28.05.15 13:53, Mario Limonciello (mario_limoncie...@dell.com) wrote: On 05/28/2015 01:46 PM, Greg KH wrote: You can't guarantee that there is another GPU to display things on. Yes you can. Wait, what? No, you can't. 1) Not everyone has multiple monitors plugged into multiple GPU's. 2) The system ships with a dGPU and supports an xGPU. If you remove the dGPU from the chassis, all you have is the xGPU. If you unplug xGPU, there's nothing left.. gdm has multi seat support btw: it will spawn X servers on all seats capable of graphics. if you unplug all graphics cards than this simply means that your number of graphics-capable seats went from 0 to 0. That's all. And if you plug in a graphics card then, then it goes from 0 to 1 again and you get a fresh new login prompt on it. Lennart Lennart, The kernel bits and discussion around hot unplug aside, can you please add support to systemd to map the scan codes? For the other scenarios such as the cable being connected and the disconnect button being pressed userspace will need to provide a notification to the user what to do next. I've added the details (and a proposed patch) to bug 90689. If these are also controversial, I'd like to know what else you have in mind. Thanks, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
Hello Krzesimir, Krzesimir Nowak [2015-06-03 10:39 +0200]: I see that some patches from mailing list were imported as issues to github.com (like this one - https://github.com/systemd/systemd/pull/16). There's a problem with that - I can't update the PR anymore with followup fixes and whatnot. What's the workflow in this case? File a new PR and ask nicely for old one to be deleted? That will do indeed; we already cleaned up some duplicates, it's not a big deal. This is just a transitional issue to mop up the pending patches on the ML, so nothing that will cause this kind of paperwork for a long time. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Mon, Jun 1, 2015 at 8:12 PM, David Herrmann dh.herrm...@gmail.com wrote: Hi As of today we've disabled git-push to fd.o. The official development git repository is now at github [1]. The old repository will still be back-synced, but we had to disable push-access to avoid getting out-of-sync with github. In recent months, keeping up with the mailing-list has become more and more cumbersome, with many of us missing mails or unable to keep up with the traffic. To make sure all community requests and patches will get handled in time, we're now trying out the github infrastructure. We encourage everyone in the development community to switch over now, even though the old fd.o infrastructure will still be maintained. Distributions are free to wait until the next release announcement before updating anything. If github does not work out, we will see what else we can try out. But lets give it at least a try. Thanks David Hi, I see that some patches from mailing list were imported as issues to github.com (like this one - https://github.com/systemd/systemd/pull/16). There's a problem with that - I can't update the PR anymore with followup fixes and whatnot. What's the workflow in this case? File a new PR and ask nicely for old one to be deleted? Thanks, Krzesimir [1] https://github.com/systemd-devs/systemd ___ 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] nss-myhostname: why don't loopback interfaces appear?
On 3 June 2015 at 16:01, Lennart Poettering lenn...@poettering.net wrote: On Wed, 03.06.15 15:40, Daurnimator (q...@daurnimator.com) wrote: I was playing around with nss, and found that my loopback interface ip doesn't appear from nss-myhostname. Rather, my other ones do. Furthermore, unless I request IPv4, link-local IPv6 addresses are returned. Is this expected? We order the returned addresses by scope. Global addresses are placed first, local ones last. Then why are link local IPv6 addresses returned first? If this was the case, I would expect to see: 192.168.2.229 192.168.2.21 fe80::aed1:b8ff:fec0:d113 fe80::9eeb:e8ff:fe1b:f42d 127.0.0.1 ::1 We return addresses on the loopback device only when there's no other address known. What's the rationale for this? (i.e. why not always just include 127.0.0.1 and ::1 last?) And even then we'll return 127.0.0.2 rather than 127.0.0.1, to avoid confusing software that expects localhost mapping only to 127.0.0.1 and vice versa. Also see nss-myhostname(8). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
Hi, On Tue, Jun 2, 2015 at 7:58 AM, Dimitri John Ledkov dimitri.j.led...@intel.com wrote: And I think this is _good_, because the submitter's commit ids will be preserved (together with the signed gpg commits) [...] This, signed gpg commits, is actually the first reasonable argument I see for merging and not rebasing commits. TL;DR: GitHub model sucks, but I think we can live with it. I think, though, in general, the GitHub way of focusing on PRs and not commits tends to generate poorer git commits and git histories in general. I too often see broken PRs being ammended with second or third commits to fix the bugs, which makes git bisect hit and miss in lots of projects. And many projects have commit descriptions that are totally meaningless (that's not just a GitHub thing, but I think GitHub makes it a lot easier to get sloppy on those.) I actually think who gets it right is Gerrit which is focused on individual commits and not in PRs with sets of commits. Even if you upload 3 or 4 commits in a row, they'll be reviewed one by one and submitted as they're approved. It's easy to merge the first two but send the last two back for rework. With GitHub, you'd have to do that manually. I'm not saying Gerrit is perfect, far from it, but I think at least they got it right in being commit-centric rather than PR-centric. GitHub also makes it hard to look at the individual commits and commit messages. By default, they just give you the blurb the author typed on the PR description (which ends up nowhere in git) and show you a consolidated diff for the whole PR, so it's quite possible that the first commit in the series doesn't even compile and you won't really get to know about that as you merge it. I always make a point to first thing reviewing a PR go to the commits tab and look at each commit on its own, most of the time I don't even look at the consolidated diff since I think it's mostly meaningless. I'm of course counting on our maintainers here to make a good job of weeding out bad commits. I think one model that helps is that of the Commit Queue, in which whenever a commit (or PR) is ready to be merged, it still goes through a queue that tries to build it and possibly run some smoke tests to ensure nothing is badly broken before actually merging it to git. Such a system would most likely rebase, producing a linear history. Oh, and I'm all for merges of feature branches, for an actual *feature* as in something that takes 15 commits to implement and needs to be developed in a separate branch. But those will most likely be merged manually since I don't expect they won't have conflicts anyways, so the PR merge feature of GitHub will be mostly useless then... Anyways, excuse the rant... I think we can live with GitHub and in the end, everything will be alright :-) Cheers, Filipe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] mount: use libmount to monitor mountinfo utab
The current implementation directly monitor /proc/self/mountinfo and
/run/mount/utab files. It's really not optimal because utab file is
private libmount stuff without any official guaranteed semantic.
The libmount since v2.26 provides API to monitor mount kernel
userspace changes. This patch replaces the current implementation with
libmount based solution.
Now the manager.h includes libmount.h, so $MOUNT_CFLAGS has been
necessary to add to many tests CFLAGS.
Note that mnt_monitor_event_cleanup() in v2.26 is broken, so the patch
uses mnt_monitor_next_change(). It's exactly the same solution which
uses the current libmount HEAD (mnt_monitor_event_cleanup() is API
shorcut only).
---
V2:
- update README
- add missing (void)
Makefile.am| 33 --
README | 2 +-
configure.ac | 2 +-
src/core/manager.c | 2 +-
src/core/manager.h | 5 ++-
src/core/mount.c | 100 -
6 files changed, 50 insertions(+), 94 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 64038a5..c1a97de 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1329,7 +1329,8 @@ systemd_SOURCES = \
systemd_CFLAGS = \
$(AM_CFLAGS) \
- $(SECCOMP_CFLAGS)
+ $(SECCOMP_CFLAGS) \
+ $(MOUNT_CFLAGS)
systemd_LDADD = \
libsystemd-core.la \
@@ -1532,7 +1533,8 @@ test_engine_SOURCES = \
test_engine_CFLAGS = \
$(AM_CFLAGS) \
- $(SECCOMP_CFLAGS)
+ $(SECCOMP_CFLAGS) \
+ $(MOUNT_CFLAGS)
test_engine_LDADD = \
libsystemd-core.la \
@@ -1543,7 +1545,8 @@ test_job_type_SOURCES = \
test_job_type_CFLAGS = \
$(AM_CFLAGS) \
- $(SECCOMP_CFLAGS)
+ $(SECCOMP_CFLAGS) \
+ $(MOUNT_CFLAGS)
test_job_type_LDADD = \
libsystemd-core.la \
@@ -1587,7 +1590,8 @@ test_unit_name_SOURCES = \
test_unit_name_CFLAGS = \
$(AM_CFLAGS) \
- $(SECCOMP_CFLAGS)
+ $(SECCOMP_CFLAGS) \
+ $(MOUNT_CFLAGS)
test_unit_name_LDADD = \
libsystemd-core.la \
@@ -1598,7 +1602,8 @@ test_unit_file_SOURCES = \
test_unit_file_CFLAGS = \
$(AM_CFLAGS) \
- $(SECCOMP_CFLAGS)
+ $(SECCOMP_CFLAGS) \
+ $(MOUNT_CFLAGS)
test_unit_file_LDADD = \
libsystemd-core.la \
@@ -1811,7 +1816,8 @@ test_tables_CPPFLAGS = \
test_tables_CFLAGS = \
$(AM_CFLAGS) \
- $(SECCOMP_CFLAGS)
+ $(SECCOMP_CFLAGS) \
+ $(MOUNT_CFLAGS)
test_tables_LDADD = \
libsystemd-logs.la \
@@ -1944,7 +1950,8 @@ test_cgroup_mask_SOURCES = \
src/test/test-cgroup-mask.c
test_cgroup_mask_CPPFLAGS = \
- $(AM_CPPFLAGS)
+ $(AM_CPPFLAGS) \
+ $(MOUNT_CFLAGS)
test_cgroup_mask_CFLAGS = \
$(AM_CFLAGS) \
@@ -1990,7 +1997,8 @@ test_path_SOURCES = \
src/test/test-path.c
test_path_CFLAGS = \
- $(AM_CFLAGS)
+ $(AM_CFLAGS) \
+ $(MOUNT_CFLAGS)
test_path_LDADD = \
libsystemd-core.la
@@ -1999,7 +2007,8 @@ test_execute_SOURCES = \
src/test/test-execute.c
test_execute_CFLAGS = \
- $(AM_CFLAGS)
+ $(AM_CFLAGS) \
+ $(MOUNT_CFLAGS)
test_execute_LDADD = \
libsystemd-core.la
@@ -2027,7 +2036,8 @@ test_sched_prio_SOURCES = \
src/test/test-sched-prio.c
test_sched_prio_CPPFLAGS = \
- $(AM_CPPFLAGS)
+ $(AM_CPPFLAGS) \
+ $(MOUNT_CFLAGS)
test_sched_prio_CFLAGS = \
$(AM_CFLAGS) \
@@ -2104,7 +2114,8 @@ systemd_analyze_SOURCES = \
systemd_analyze_CFLAGS = \
$(AM_CFLAGS) \
- $(SECCOMP_CFLAGS)
+ $(SECCOMP_CFLAGS) \
+ $(MOUNT_CFLAGS)
systemd_analyze_LDADD = \
libsystemd-core.la \
diff --git a/README b/README
index b810044..19abeb2 100644
--- a/README
+++ b/README
@@ -114,7 +114,7 @@ REQUIREMENTS:
glibc = 2.16
libcap
-libmount = 2.20 (from util-linux)
+libmount = 2.26 (from util-linux)
libseccomp = 1.0.0 (optional)
libblkid = 2.24 (from util-linux) (optional)
libkmod = 15 (optional)
diff --git a/configure.ac b/configure.ac
index 0532c54..61f9a0f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -438,7 +438,7 @@ AM_CONDITIONAL(HAVE_BLKID, [test $have_blkid = yes])
#
--
have_libmount=no
-PKG_CHECK_MODULES(MOUNT, [ mount = 2.20 ],
+PKG_CHECK_MODULES(MOUNT, [ mount = 2.26 ],
[AC_DEFINE(HAVE_LIBMOUNT, 1, [Define if libmount is available])
have_libmount=yes], have_libmount=no)
if test x$have_libmount = xno; then
AC_MSG_ERROR([*** libmount support required but libraries not found])
diff --git a/src/core/manager.c b/src/core/manager.c
index ae473d0..10ab83a 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -568,7 +568,7 @@ int manager_new(ManagerRunningAs running_as, bool test_run,
Manager **_m) {
m-idle_pipe[0] = m-idle_pipe[1] = m-idle_pipe[2] = m-idle_pipe[3]
= -1;
-m-pin_cgroupfs_fd
Re: [systemd-devel] [PATCH] mount: use libmount to monitor mountinfo utab
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:146366-7016-1-git-send-email-kzak%40redhat.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
Abdó Roig-Maranges wrote on 02/06/15 17:03: Daniel Mack writes: On 06/02/2015 04:34 PM, Martin Pitt wrote: Merging manually is quite a bit of work, as you have to add a new remote every time, fetch that, and pull from it. But it does keep a cleaner git log history. Btw, Harald pointed me to this simple alias that makes checking out a pending pull request a one-liner: https://gist.github.com/gnarf/5406589 Hi, I saw this thread and I can't stop from advertising a tool I recently discovered for dealings with github. https://github.com/sociomantic/git-hub You can do things like: $ git hub clone -t systemd/systemd To clone and fork into my account in one go $ git hub pull list [33] cgtop: add options to format memory, IO usage in raw bytes (haraldh) https://github.com/systemd/systemd/pull/33 [32] Ensure that /run/systemd/network exists (haraldh) https://github.com/systemd/systemd/pull/32 [31] cgtop: raw output option (disable conversion to human-readable units) (haraldh) https://github.com/systemd/systemd/pull/31 [30] More cgtop enhancements (haraldh) https://github.com/systemd/systemd/pull/30 [...] $ git hub pull checkout 33 To checkout a pull request, in detached HEAD (no new remote, nor branch...) $ git hub pull rebase 33 To rebase a pull request, update it on github and close it. It is also very easy to create new issues / pull requests, or add comments directly from the command line. This looks very useful indeed. Mostly replying so hopefully more people will see it :) Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Partially revert ma-setup: simplify
On Wed, 2015-06-03 at 06:50 +0200, Lennart Poettering wrote: On Tue, 02.06.15 11:55, Mimi Zohar (zo...@linux.vnet.ibm.com) wrote: We could add another parameter to copy_bytes(), but in this case it's cleaner to call fstat() and loop_write(). Right. copy_bytes has no concept of rules/records. So either another parameter is added to copy_bytes to indicate skip try_sendfile and write the entire policy, or [partially] revert the patch to calll loop_write() to write the entire policy directly. In which way does sendfile() fail here? I mean, the code currently understands ENOSYS and EINVAL as indications that sendfile() is not supported on an fd. What does sendfile() on the IMA device return? Most likely we can just check for that error code, and then try the loop as fallback. After the sendfile failure, in addition to resetting the file position to the beginning of the file, the file would also need to be closed and re-opened. Otherwise, IMA assumes the policy was malformed and fails the policy update. Mimi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Regression: loop device detach errors in 220
Hi, systemd-shutdown in 220 has errors when detaching loop devices: systemd-shutdown[1]: Failed to detach loop devices: Invalid argument cgroup: option or name mismatch, new: 0x0 , old: 0x4 systemd systemd-shutdown[1]: Failed to detach loop devices: Invalid argument systemd-shutdown[1]: Failed to detach loop devices: Invalid argument systemd-shutdown[1]: Failed to finalize _ loop devices, ignoring https://bugs.archlinux.org/task/45111 c32eb440bab953a0169cd207dfef5cad16dfb340 is the first bad commit Author: Tom Gundersen t...@jklm.no Date: Tue Apr 14 16:25:06 2015 +0200 libudev: make libudev-enumerate a thin wrapper around sd-device :100644 100644 837fd36381315029171562b344dca8620528d327 68d8252b84c13591cf8e0b0e15a99780f5dd0309 M Makefile.am :04 04 c54e32bc21e34cc28693fbf653c4128a0383d3d7 11e1eeec94338e9294e25e720007c35f229d24cf M src Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On 6/3/15, 7:14 AM, Filipe Brandenburger filbran...@google.com wrote: I think, though, in general, the GitHub way of focusing on PRs and not commits tends to generate poorer git commits and git histories in general. I too often see broken PRs being ammended with second or third commits to fix the bugs, which makes git bisect hit and miss in lots of projects. It is what the project makes it. If the project demands people to rewrite the PR history instead of tacking on fix commits, then this problem is avoided. And many projects have commit descriptions that are totally meaningless (that's not just a GitHub thing, but I think GitHub makes it a lot easier to get sloppy on those.) The project is responsible for enforcing quality. If a project has a lazy maintainer, the project will reflect it. I actually think who gets it right is Gerrit which is focused on individual commits and not in PRs with sets of commits. Even if you upload 3 or 4 commits in a row, they'll be reviewed one by one and submitted as they're approved. It's easy to merge the first two but send the last two back for rework. With GitHub, you'd have to do that manually. I'm not saying Gerrit is perfect, far from it, but I think at least they got it right in being commit-centric rather than PR-centric. I use Gerrit at work and Github at home. You can be hard nosed about it either way. I actually find Gerrit more trouble in the sense that people who are not comfortable with Git can really screw up Gerrit and make it tedious to abandon a bunch of commits. On github a force push usually makes all badness a figment of your imagination. Maybe it is just work though, it is much easier to be hard nosed to strangers. GitHub also makes it hard to look at the individual commits and commit messages. By default, they just give you the blurb the author typed on the PR description (which ends up nowhere in git) and show you a consolidated diff for the whole PR, so it's quite possible that the first commit in the series doesn't even compile and you won't really get to know about that as you merge it. I always make a point to first thing reviewing a PR go to the commits tab and look at each commit on its own, most of the time I don't even look at the consolidated diff since I think it's mostly meaningless. As you should IMO. I'm of course counting on our maintainers here to make a good job of weeding out bad commits. A good project starts with good maintainers. Long live good maintainers. - Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Creating timers using D-Bus
Hello,
My name is Jakub Skořepa and I'm working on GSoC project: Cockpit UI
for Systemd Timers.
For that I need to create and modify systemd unit files. Cockpit uses D
-Bus for everything so I need D-Bus API for that. I think that it would
be beneficial if systemd was able to create unit files on-the-fly using
through D-Bus method call.
I plan creating simple server for doing this task but long-term it
would be better if systemd was capable of doing this.
I propose methods with following signatures:
# CreateUnit:
Creates specified unit
sa{sa{ss}}
| | ||
Name | |Value
Section name |
Key
# ModifyUnit: (same signature)
If section/key is not then section/key is left intact.
If Value= then key is erased.
# CreateUnits:
Creates multiple units. Same as CreateUnit called for each top-level
array element.
a{sa{sa{ss}}}
| | ||
Name | |Value
Section name |
Key
# ModifyUnits: (same signature as CreateUnits)
Modifies multiple units. Same as ModifyUnit called for each top-level
array element.
Regards,
Jakub
signature.asc
Description: This is a digitally signed message part
smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to create a user instance service that requires a network connection?
On Wed, Jun 3, 2015 at 6:32 PM, Will S wsha.code+syst...@gmail.com wrote: My understanding is that the system and user instances of systemd are completely isolated from each other. So I can not create a user unit file with the option Requires=network-online.target. Is there any way for a user instance service to get this functionality of waiting for the network to be online before starting? From what I can tell, the systemd user instance is relatively new. If it is not possible now, is there any planned feature that would allow this functionality in the future that I should watch for? No. And there are no plans. Better make your application network aware and adjust to the environment during runtime. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to create a user instance service that requires a network connection?
2015-06-03 18:39 GMT+02:00 Kay Sievers k...@vrfy.org: On Wed, Jun 3, 2015 at 6:32 PM, Will S wsha.code+syst...@gmail.com wrote: My understanding is that the system and user instances of systemd are completely isolated from each other. So I can not create a user unit file with the option Requires=network-online.target. Is there any way for a user instance service to get this functionality of waiting for the network to be online before starting? From what I can tell, the systemd user instance is relatively new. If it is not possible now, is there any planned feature that would allow this functionality in the future that I should watch for? No. And there are no plans. Better make your application network aware and adjust to the environment during runtime. For desktop/user applications, you could use something like glib's GNetworkMonitor https://developer.gnome.org/gio/stable/GNetworkMonitor.html -- 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
[systemd-devel] How to create a user instance service that requires a network connection?
My understanding is that the system and user instances of systemd are completely isolated from each other. So I can not create a user unit file with the option Requires=network-online.target. Is there any way for a user instance service to get this functionality of waiting for the network to be online before starting? From what I can tell, the systemd user instance is relatively new. If it is not possible now, is there any planned feature that would allow this functionality in the future that I should watch for? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, Jun 2, 2015 at 5:03 PM Kay Sievers k...@vrfy.org wrote: Could you please check your old repos at: https://github.com/systemd and move or delete them if they are no longer needed. One of them at least has a comment like This is old. Actual repo is on my davidstrauss account. Will clean up soon. (2012) We should only keep repos here for code that we actually host. Cloned repos should only be there if they are supposed to be shared by multiple people to work on them at the same time, everything else should be done in a user repo. This is now done. The only remaining forked repository is the Linux kernel, which appears to be for kdbus work. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Wed, Jun 3, 2015 at 7:06 PM, David Timothy Strauss da...@davidstrauss.net wrote: On Tue, Jun 2, 2015 at 5:03 PM Kay Sievers k...@vrfy.org wrote: Could you please check your old repos at: https://github.com/systemd and move or delete them if they are no longer needed. One of them at least has a comment like This is old. Actual repo is on my davidstrauss account. Will clean up soon. (2012) We should only keep repos here for code that we actually host. Cloned repos should only be there if they are supposed to be shared by multiple people to work on them at the same time, everything else should be done in a user repo. This is now done. Great. The only remaining forked repository is the Linux kernel, which appears to be for kdbus work. Yeah, for now we use that as the public interface for the kdbus work, for people to pull our changes from. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bogus issue/50 branch on systemd git at GitHub
В Wed, 3 Jun 2015 18:43:31 -0700 Filipe Brandenburger filbran...@google.com пишет: I don't think it should be there... https://github.com/systemd/systemd/branches Otherwise everyone doing git fetch will get a copy of this branch... I think the main git should only expose a single master branch. Would you care to delete it and be careful not to push extraneous branches to the main repo? It was by accident. I apologize for confusion. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] load-fragment: use unquote_first_word in config_parse_exec
В Wed, 3 Jun 2015 20:34:53 -0700 Filipe Brandenburger filbran...@google.com пишет: - We do something different for empty string (clear the command list) than we do for just whitespace. This is pre-existing. Maybe we need to fix that? I put a comment on that case, that branch is triggered both in the just whitespace case as well as right after a semicolon command separator. Not sure I understand what you mean. Do you suggest that ExecStart=/usr/bin/foo ; ; /usr/bin/bar should discard /usr/bin/foo? Or that it does it already? I added a test case to cover two semicolons in a row. With the new code it breaks as it thinks ; is a new command name, I think that's appropriate enough, let me know if you think otherwise. I cannot think where this would be useful, so I guess it is OK as long as error is clear enough. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] mount-setup: create /run/systemd/netif/links/ before accessing
Hi Tom, On Tue, Jun 02, 2015 at 05:43:46PM +0200, Tom Gundersen wrote: On Mon, Jun 1, 2015 at 9:16 PM, Robert Schwebel r.schwe...@pengutronix.de wrote: systemd-timesyncd breaks with Starting Network Time Synchronization... [FAILED] Failed to start Network Time Synchronization. when we have timesyncd activated and systemd-networkd not. Create directory before using it. Hm, this is surely the wrong fix. PID1 should not know about networkd/timesyncd. Either this should be created by a tmpfiles fragment, or timesyncd should learn not to care about missing networkd. Michael has sent a github pull request for this. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Bogus issue/50 branch on systemd git at GitHub
I don't think it should be there... https://github.com/systemd/systemd/branches Otherwise everyone doing git fetch will get a copy of this branch... I think the main git should only expose a single master branch. Would you care to delete it and be careful not to push extraneous branches to the main repo? Cheers, Filipe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] load-fragment: use unquote_first_word in config_parse_exec
Hi, This commit was not moved to GitHub, it's under review here: https://github.com/systemd/systemd/pull/44 On Sun, May 31, 2015 at 12:06 AM, Andrei Borzenkov arvidj...@gmail.com wrote: В Sat, 30 May 2015 23:29:29 -0700 Filipe Brandenburger filbran...@google.com пишет: - Handling a \; is ugly, it looks like a hack... unquote_first_word is not equipped to recognize that sequence, so I had to move it outside unquote_first_word looking for those two characters followed by whitespace explicitly. But then, something like ';' or ; will be recognized as a command separator, is that OK? I do not think it's OK. Having quoted string act like a separator is definitely unexpected and confusing. Addressed. Now ; or ';' will turn into a literal semicolon, so will \; only when it's on its own, and only a single ; on its own will be recognized as a command separator. - We do something different for empty string (clear the command list) than we do for just whitespace. This is pre-existing. Maybe we need to fix that? I put a comment on that case, that branch is triggered both in the just whitespace case as well as right after a semicolon command separator. Not sure I understand what you mean. Do you suggest that ExecStart=/usr/bin/foo ; ; /usr/bin/bar should discard /usr/bin/foo? Or that it does it already? I added a test case to cover two semicolons in a row. With the new code it breaks as it thinks ; is a new command name, I think that's appropriate enough, let me know if you think otherwise. Cheers! Filipe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nss-myhostname: why don't loopback interfaces appear?
On Wed, 03.06.15 15:40, Daurnimator (q...@daurnimator.com) wrote: I was playing around with nss, and found that my loopback interface ip doesn't appear from nss-myhostname. Rather, my other ones do. Furthermore, unless I request IPv4, link-local IPv6 addresses are returned. Is this expected? We order the returned addresses by scope. Global addresses are placed first, local ones last. We return addresses on the loopback device only when there's no other address known. And even then we'll return 127.0.0.2 rather than 127.0.0.1, to avoid confusing software that expects localhost mapping only to 127.0.0.1 and vice versa. Also see nss-myhostname(8). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd: IPForward with ipv6
Hello, Since systemd v220, IPForward= parameter in [Network] set kernel parameters by interface (/proc/sys/net/ipv[46]/conf/*/forwarding). This is nice and works perfectly for ipv4. Unfortunately, ipv6 forwarding doesn't works until we manually set /proc/sys/net/ipv6/conf/all/forwarding to 1. In term of user experience, IPforward=ipv6 doesn't enable ipv6 forwarding on the interface. That's tricked me. From: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt conf/all/forwarding - BOOLEAN Enable global IPv6 forwarding between all interfaces. IPv4 and IPv6 work differently here; e.g. netfilter must be used to control which interfaces may forward packets and which not. An maybe better explained here: http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/proc-sys-net-ipv6..html This enables global IPv6 forwarding between all interfaces. In IPv6 you can't control forwarding per device, forwarding controlhas to be done using IPv6-netfilter (controlled with ip6tables)rulesets and specify input and output devices (see Firewalling/Netfilter6for more).This is different to IPv4, where you are able to control forwarding perdevice (decision is made on interface where packet came in). In others words, IPForward by interface for ipv6 as no sense. So, should we consider:- systemd-networkd have to set /proc/sys/net/ipv6/conf/all/forwarding to 1 when an IPForward=true or IpForward=ipv6- IPForward=ipv6 is nonsense and administrators have to enable ipv6 forwarding somewhere else Cheers, -- Sébastien Seblu Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A 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] [ANNOUNCE] Git development moved to github
On Tue, Jun 2, 2015 at 11:53 AM, Kay Sievers k...@vrfy.org wrote: On Tue, Jun 2, 2015 at 4:34 PM, Martin Pitt martin.p...@ubuntu.com wrote: David Herrmann [2015-06-02 13:06 +0200]: Our preferred way to send future patches is the github way. This means sending pull-requests to the github repo. Furthermore, all feature patches should go through pull-requests and should get reviewed pre-commit. This applies to everyone. Exceptions are non-controversial patches like typos and obvious bug-fixes. Makes sense. On the operational level, should we use the automatically merge feature of git hub once approving? On the plus side it's very convenient, but you'll get one Merge commit for every PR (which is often just one commit), so we'd almost double the entries in git log. Or can github be told to not do that? Merging manually is quite a bit of work, as you have to add a new remote every time, fetch that, and pull from it. But it does keep a cleaner git log history. Use github. With the decision to move to github, we need to accept the github model and with that accept possible cosmetic issues. Have you guys found a way to preserve the comments on pull requests? I don't see it as a cosmetic issue but this was rather the reason I moved projects away from github in the past. As a maintainer of other projects I need to point to a discussion on a single patch and be able to see the previous iterations of a patch. And also check what was the conclusion on a patch set that was accepted in the repository. It's also nice for developers to check if there was any attempt already in implementing some feature and it was denied by any reason. Last time I checked this is impossible with github because you lose the comments on each patch when a second version arrives. Of course this is a non-issue for several projects in github which don't have proper commit review. It's not the case of systemd and it seems it's even the reason why you are moving to github. So I'm just curious if anything changed in this regard or you solved it in another way. thanks -- Lucas De Marchi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
