On Mon, Jun 30, 2014 at 01:54:57AM +0100, Djalal Harouni wrote:
> On Sun, Jun 29, 2014 at 07:59:38PM -0400, Luke Shumaker wrote:
> > At Sun, 29 Jun 2014 12:31:13 +0100,
> > Djalal Harouni wrote:
> > > On Sat, Jun 28, 2014 at 12:09:56PM -0400, Luke Shumaker wrote:
> > > > This is accomplished by hav
On Sun, Jun 29, 2014 at 07:59:38PM -0400, Luke Shumaker wrote:
> At Sun, 29 Jun 2014 12:31:13 +0100,
> Djalal Harouni wrote:
> > On Sat, Jun 28, 2014 at 12:09:56PM -0400, Luke Shumaker wrote:
> > > This is accomplished by having wait_for_container() return a positive
> > > error
> > > code when we
Commit 113cea8 introduced a bug that caused the exit code of systemd-nspawn
to not reflect the exit code of the program executed in the container.
---
src/nspawn/nspawn.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/src/nspawn/nspawn.c b/src/nsp
This is at the suggestion of Djalal Harouni on the mailing list, and
reflects the behavior of shared/util.c:wait_for_terminate_and_warn().
---
src/nspawn/nspawn.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index be0e6b5..8fb72d6
---
src/shared/util.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/shared/util.c b/src/shared/util.c
index e7ff0f8..32358e5 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -3474,6 +3474,17 @@ int wait_for_terminate(pid_t pid, siginfo_t *status) {
}
}
+
Kai Krakow gmail.com> writes:
>
> To check this, I've just pulled the original source from git and built it.
> This is original upstream behavior, no special Gentoo thing. The fsck.btrfs
> utility is just a shell script. It seems to originate from xfs-progs:
>
> https://github.com/josefbacik/b
At Sun, 29 Jun 2014 12:31:13 +0100,
Djalal Harouni wrote:
> On Sat, Jun 28, 2014 at 12:09:56PM -0400, Luke Shumaker wrote:
> > This is accomplished by having wait_for_container() return a positive error
> > code when we would like that error code to make its way to the user. This
> > is at odds wi
On Mon, Jun 30, 2014 at 01:17:47AM +0200, Kai Krakow wrote:
> Zbigniew Jędrzejewski-Szmek schrieb:
>
> >> IMHO both xfs and btrfs should just not ship a fsck helper at all, not
> >> even as a symlink. This workaround made sense at some point, but now I
> >> believe both systemd _and_ fsck itself
Zbigniew Jędrzejewski-Szmek schrieb:
>> IMHO both xfs and btrfs should just not ship a fsck helper at all, not
>> even as a symlink. This workaround made sense at some point, but now I
>> believe both systemd _and_ fsck itself can deal gracefully with a
>> missing fsck helper.
> IMHO, this shows
Stefan G. Weichinger schrieb:
> Am 29.06.2014 23:52, schrieb Tom Gundersen:
>> On Sun, Jun 29, 2014 at 11:31 PM, Stefan G. Weichinger
>> wrote:
>>
>>> This is how gentoo currently implements things. So the devs there
>>> should link it to /bin/true ? We could open a bug for that at
>>> bugs.gen
Lennart Poettering schrieb:
> On Sun, 29.06.14 21:51, Kai Krakow (hurikha...@gmail.com) wrote:
>
>> > This sounds really unnecessary, no? We already have fsck_exists() in
>> > place that since a very recent commit of mine even detects a per-fstype
>> > fsck implementation being linked to /bin/t
Hey, Tom.
I'm glad to you for fixing this issue. Really worked for me. Now, no
errors/warning.
Thank you for feedback.
Regards.
Att,
Luis Mauricio Costa.
Cientista da Computação.
On Sun, Jun 29, 2014 at 3:48 PM, Tom Gundersen wrote:
> On Fri, Jun 20, 2014 at 10:17 PM, Luis Mauricio Costa
On Mon, Jun 30, 2014 at 12:10 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Sun, Jun 29, 2014 at 08:46:32PM +0200, Lennart Poettering wrote:
>> This sounds really unnecessary, no? We already have fsck_exists() in
>> place that since a very recent commit of mine even detects a per-fstype
>> fsck imp
On Sun, Jun 29, 2014 at 08:46:32PM +0200, Lennart Poettering wrote:
> This sounds really unnecessary, no? We already have fsck_exists() in
> place that since a very recent commit of mine even detects a per-fstype
> fsck implementation being linked to /bin/true... I also downgraded all
> warnings f
On Wed, Jun 25, 2014 at 12:12 PM, Michael Olbrich
wrote:
> Commit 58e027023b47b32e42cf93dd4a629b869ee1ef25 'units: order
> network-online.target after network.target' added "Before=network.target"
> dependency to systemd-networkd-wait-online.service. Is that correct? If I
> understand the document
Am 29.06.2014 23:52, schrieb Tom Gundersen:
> On Sun, Jun 29, 2014 at 11:31 PM, Stefan G. Weichinger
> wrote:
>
>> This is how gentoo currently implements things. So the devs there
>> should link it to /bin/true ? We could open a bug for that at
>> bugs.gentoo.org ...
>
> IMHO both xfs and btrfs
On Sun, Jun 29, 2014 at 11:31 PM, Stefan G. Weichinger wrote:
> Am 29.06.2014 23:24, schrieb Lennart Poettering:
>> On Sun, 29.06.14 21:51, Kai Krakow (hurikha...@gmail.com) wrote:
>>> # /sbin/fsck.btrfs /dev/sdb3
>>> If you wish to check the consistency of a BTRFS filesystem or
>>> repair a damag
Hi,
I am seeing the following messages in my syslog on each boot:
--
$ grep "link config " /var/log/errors.log
2014-06-29T09:31:39.000-04:00 hermes systemd-udevd[246]: Could not apply link
config to br0
2014-06-29T09:31:40.000-04:00 hermes systemd-udevd[246]: Could not apply link
con
On Fri, Jun 27, 2014 at 8:09 PM, Marcel Holtmann wrote:
> Hi Lennart,
>
I am tempted to say that we should try to apply as much information from
DHCP as we can by default, but make sure it doesn't become a security
problem. i.e. we should probably use metrics or so so that manual ro
On Fri, Jun 27, 2014 at 7:58 PM, Lennart Poettering
wrote:
> On Thu, 26.06.14 12:49, Eugene Yakubovich (eyakubov...@gmail.com) wrote:
>
>>
>> On Thu, Jun 26, 2014 at 11:17 AM, Lennart Poettering
>> wrote:
>>
>> > I am tempted to say that we should try to apply as much information from
>> > DHCP a
On Wed, 28.05.14 00:39, WaLyong Cho (walyong@samsung.com) wrote:
Sorry for the late response!
> I'm not sure this could be patch for below TODO.
>
> * enabling an instance unit creates a pointless link, and
> the unit will be started with getty@getty.service:
> $ systemctl enable getty
Am 29.06.2014 23:24, schrieb Lennart Poettering:
> On Sun, 29.06.14 21:51, Kai Krakow (hurikha...@gmail.com) wrote:
>> # /sbin/fsck.btrfs /dev/sdb3
>> If you wish to check the consistency of a BTRFS filesystem or
>> repair a damaged filesystem, see btrfs(8) subcommand 'check'.
>
> Is this an upstr
On Sun, 29.06.14 21:51, Kai Krakow (hurikha...@gmail.com) wrote:
> > This sounds really unnecessary, no? We already have fsck_exists() in
> > place that since a very recent commit of mine even detects a per-fstype
> > fsck implementation being linked to /bin/true... I also downgraded all
> > warn
On Sun, Jun 29, 2014 at 9:21 PM, Lennart Poettering
wrote:
> On Sun, 29.06.14 07:25, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:
>
>> +
>> +FOREACH_WORD(word, len, string, state) {
>> +/* WORD FORMAT: dst_ip/dst_prefixlen,gw_ip */
>> +_cleanup_free
Lennart Poettering schrieb:
> On Sat, 28.06.14 19:49, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
> wrote:
>
>> fsck.btrfs and fsck.xfs are documented to return immediately, so there is
>> little sense in running them. Avoids some user confusion and a few lines
>> in the logs.
>>
>> +stati
On Sun, 29.06.14 07:25, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:
> +
> +FOREACH_WORD(word, len, string, state) {
> +/* WORD FORMAT: dst_ip/dst_prefixlen,gw_ip */
> +_cleanup_free_ char* entry;
missing initialization to NULL.
> +
On Sat, Jun 28, 2014 at 12:00 AM, Eugene Yakubovich
wrote:
> This adds support for DHCP options 33 and 121: Static Route and
> Classless Static Route. To enable this feature, set UseRoutes=true
> in .network file. Returned routes are added to the routing table.
Applied. Thanks!
Tom
> ---
> man
Hi Camilo,
Sorry for taking some time to get back to you.
On Sat, Jun 21, 2014 at 9:08 PM, Camilo Aguilar
wrote:
> This is another reason why I previously suggested to expose a directive to
> allow administrators to enable/disable the broadcast flag. I have seen DHCP
> servers ignoring the flag
On Fri, Jun 20, 2014 at 10:17 PM, Luis Mauricio Costa
wrote:
> When i try to start systemd-networkd "systemctl start systemd-networkd" with
> conf file (pasted), service/daemon works, but returns this warning/error in
> status:
Hi Luis,
Sorry for the delay in getting back to you.
This should ha
On Sat, 28.06.14 19:49, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> fsck.btrfs and fsck.xfs are documented to return immediately, so there is
> little sense in running them. Avoids some user confusion and a few lines
> in the logs.
>
> +static bool mount_skip_fsck(const char *fstype
On Sat, Jun 28, 2014 at 7:49 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> fsck.btrfs and fsck.xfs are documented to return immediately, so there is
> little sense in running them. Avoids some user confusion and a few lines
> in the logs.
Is this special-casing really worth it? In general we don't kno
On Sun, Jun 29, 2014 at 6:08 PM, Andrey Borzenkov wrote:
> This sounds far too specific for a generic tool. If I read this bug
> report correctly, the primary complain was that systemd tries to
> install fsck service even though fstab says skip fsck. This appears to
> be the actual bug; I do not s
В Sat, 28 Jun 2014 19:49:07 +0200
Zbigniew Jędrzejewski-Szmek пишет:
> fsck.btrfs and fsck.xfs are documented to return immediately, so there is
> little sense in running them. Avoids some user confusion and a few lines
> in the logs.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1098799
This
On Sat, Jun 28, 2014 at 11:29 AM, Tom Gundersen wrote:
> Your analysis is correct. networkd is not updating the lft.
>
> We should change two things: dracut (or whatever is being used on your
> machine) should set an infinite lifetime when using NFS root (IMHO),
> and networkd should update the lf
On Sat, Jun 28, 2014 at 6:36 AM, Gerardo Exequiel Pozzi
wrote:
> Looks like this commit also changes a unrelated file
> (units/local-fs.target) reverting the commit 40f862e3 (filesystem
> targets: disable default dependencies)
>
> The side effect, at least in my case is that the "nofail" option in
On Fri, Jun 27, 2014 at 01:02:19PM +0200, Daniel Mack wrote:
> On 06/27/2014 12:46 PM, Kay Sievers wrote:
> > On Fri, Jun 27, 2014 at 12:32 PM, Djalal Harouni wrote:
> >> For connections with the KDBUS_HELLO_CACHE_META flag dup the
> >> metadata/credentials from handle or from the HELLO cmd, and u
Ping?
On Tue, Jun 03, 2014 at 08:47:37PM +0200, Lennart Poettering wrote:
> On Sun, 01.06.14 20:53, Rico Sagner (sag...@b1-systems.de) wrote:
>
> >
> > +static int property_get_machineid(
> > +sd_bus *bus,
> > +const char *path,
> > +const char *i
Hi,
You are right, commit 113cea8 introduced this regression, we guarantee
that nspawn returns the exit code of the program executed in the
container in case nspwan wont fail. My bad, I missed this point...
sorry!
Ok will comment on this patch, the other one is wrong, since we mix
-errno with exi
On Thu, Jun 26, 2014 at 11:01:30AM +0530, Susant Sahani wrote:
> >>Name=em1 <==interface name
> >
> > After putting in interface name tunnel is still not created:
>
>
> could send do ip link output.
Hi, just to recollect, current configuration:
he.netdev:
--
[NetDev]
Name=h
Right, sorry, I was probably thinking about something different.
Speaking about marking `.Lock` non-privileged, I'd like to point out that
there is also `.Unlock` and so, by making one of them non-privileged and
the other one privileged, we kind of introduce asymmetry.
On the other hand, making `.
A session manager is *not necessary* for this; the screensaver or
screenlocker itself could easily listen to the relevant DBus signals (e.g.
cinnamon-screensaver does this). See also: xss-lock, systemd-lock-handler.
--
Mantas Mikulėnas
// sent from phone
On Jun 29, 2014 1:02 PM, "Kirill Elagin"
If you don't have a DE you don't have a session manager either, so
systemd-logind can't help you anyway.
Indeed, you should just run your screenlocker.
--
Кирилл Елагин
On Sun, Jun 29, 2014 at 9:57 AM, Ivan Shapovalov
wrote:
> >> 27 июня 2014 г., в 21:54, Lennart Poettering
> написал(а):
> >
42 matches
Mail list logo
