On 12/21/2015 04:02 PM, Michael Biebl wrote:
2015-12-21 17:00 GMT+01:00 Jóhann B. Guðmundsson :
No what's obvious is it does not add any value not et all
Well, I can reiterate the points, but I suggest you just read this thread again.
and not all
daemons and service support addit
On 12/21/2015 04:36 PM, Michael Biebl wrote:
2015-12-21 17:30 GMT+01:00 Jóhann B. Guðmundsson :
It's an added work to add the environmental line to begin with and it's an
That would be done once, by upstream ideally. The work would be negligible.
Still an added work eithe
On 12/23/2015 12:43 AM, Lennart Poettering wrote:
Just to clarify that. I think EnvironmentFile= was a mistake, and I
explained why. But then again, I am not planning to remove it, and I
never suggested that.
What usescases do you see for it's existence.
FYI the longer you take fixing your m
On 12/23/2015 07:30 PM, Alex Crawford wrote:
I like this model and I'm not sure how I would solve this if EnvironmentFile
didn't exist.
The usual underlying cause of usage of Environment or EnvironmentFile in
type units is more or less always due to the fact that the
daemon/service cannot re
On 12/23/2015 07:48 PM, Lennart Poettering wrote:
I see no reason why systemd should be involved with this. Just make
etcd a proper daemon, and read its config data directly, rather then
serializing it into the command line.
In sys v initscript it started out as variable options, placed on to
On 12/23/2015 08:18 PM, Reindl Harald wrote:
Am 23.12.2015 um 21:12 schrieb Jóhann B. Guðmundsson:
On 12/23/2015 07:30 PM, Alex Crawford wrote:
I like this model and I'm not sure how I would solve this if
EnvironmentFile
didn't exist.
The usual underlying cause of usage of Envi
On 12/30/2015 11:24 AM, Marco d'Itri wrote:
Does anybody know about something actually using /dev/core or is it yet
another instance of cargo cult sysadmining?
A Debian code search shows only two packages using it. In tests.
Wrongly.
https://codesearch.debian.net/results/%22%2Fdev%2Fcore%22/pa
On 12/30/2015 11:44 AM, Marco d'Itri wrote:
On Dec 30, "Jóhann B. Guðmundsson" wrote:
You should ask that question on the kernel mailinglist and or on the Debian
devel list if they want to remove that symbolic link to /proc/kcore
I am already dealing with the Debian side (
Use the existing fields as in
NAME=
VERSION=
ID=
VERSION_ID=
PRETTY_NAME=
VARIANT=
VARIANT_ID=
Adding additional codename field serves no purpose or value which the
previous fields do not already cover.
___
systemd-devel mailing list
systemd-devel@li
On 01/14/2016 03:01 PM, Lennart Poettering wrote:
We currently do not show runtime generated unit files among the output
of "systemctl list-unit-files", but it would probably make sense
Aren't these files auto generated on each bootup/reload/restart thus
exposing them is likely to cause conf
On 02/11/2016 04:50 PM, Lennart Poettering wrote:
Heya!
I just tagged the v229 release of systemd. Enjoy!
CHANGES WITH 229:
* The coredump collection logic has been reworked: when a coredump is
collected it is now written to disk, compressed and processed
(incl
On 02/11/2016 05:47 PM, Lennart Poettering wrote:
On Thu, 11.02.16 17:32, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
I just tagged the v229 release of systemd. Enjoy!
CHANGES WITH 229:
* The coredump collection logic has been reworked: when a coredump is
On 02/11/2016 05:06 PM, Lennart Poettering wrote:
Heya!
So I am thinking about some spring cleaning, and would love to remove
the following bits from the systemd package:
All seem to be very sound choice to make.
Arguably you should chop away the environment files support in the
process si
On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:
>2) compat support for libsystemd-login.so and friends (these were
>merged into a single libsystemd.so a long time ago). We are still
>building compat libraries to ease the transition, but that was a
>long time ago, hence I'
On 02/11/2016 08:41 PM, Armin K. wrote:
On 11.02.2016 21:04, Jóhann B. Guðmundsson wrote:
On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:
2) compat support for libsystemd-login.so and friends (these were
merged into a single libsystemd.so a long time ago). We are still
On 02/11/2016 09:44 PM, Andrew Bartlett wrote:
On Thu, 2016-02-11 at 20:04 +, Jóhann B. Guðmundsson wrote:
On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:
2) compat support for libsystemd-login.so and friends (these
were
merged into a single libsystemd.so a long time ago
On 02/17/2016 04:51 PM, Daniel Mack wrote:
Hey,
[I've put all people in Cc who have had more than one commit related to
systemd-bootchart in the past]
As part of our spring cleaning, we've been thinking about giving
systemd-bootchart a new home, in a new repository of its own. I've been
worki
On 02/18/2016 08:01 AM, Martin Pitt wrote:
So please don't put too much attention to these results yet. I want to
to enable them to see how the testing and communication holds up in
practice, but before this we definitively need to sort out [2] first.
Will failed tests or false positives start
On 02/18/2016 10:22 AM, Daniel Mack wrote:
I disagree. All sorts of testing is good for us, and if a PR is breaking
downstream Ubuntu, and we recognize that before merging, that's really
great.
I'm all for more testing the better but due to downstream fragmentation
all these have the same fund
On 02/18/2016 10:43 AM, Martin Pitt wrote:
I'd actually turn it the other way around and claim that if Fedora,
Arch, etc. have downstream tests, then please trigger them too. After
all, failures of them don't block anything (right now, anyway), and
having the extra information in the PRs can onl
On 02/18/2016 11:26 AM, Daniel Mack wrote:
On 02/18/2016 12:19 PM, Jóhann B. Guðmundsson wrote:
>On 02/18/2016 10:22 AM, Daniel Mack wrote:
>>I disagree. All sorts of testing is good for us, and if a PR is breaking
>>downstream Ubuntu, and we recognize that before merging
On 03/30/2016 03:49 PM, Michal Sekletar wrote:
On Mon, Mar 21, 2016 at 1:42 PM, Vasiliy Tolstov wrote:
Now i want to have two entries and assign priority to it via systemd,
in my use-case i want to know last succeseful boot entry and use it.
After upgrade i want to boot from new antry and if
On 03/31/2016 02:31 PM, Michal Sekletar wrote:
We don't need to extend the kernel in order to implement this
particular mechanism. After new kernel is installed, you make it
default and mark as "tentative". Then, after first successful boot of
newly added bootloader entry you just remove the fl
On 04/01/2016 10:11 AM, Vasiliy Tolstov wrote:
2016-04-01 13:08 GMT+03:00 Jóhann B. Guðmundsson :
I dont see how you plan on implement this if not with either a secondary
program loader which stores an redundant environment or an kernel support
that does the similar/same thing I mean you need
On 04/01/2016 10:52 AM, Vasiliy Tolstov wrote:
2016-04-01 13:50 GMT+03:00 Jóhann B. Guðmundsson :
AFAIK the android boot process fires an standard broadcasting action
"ACTION_BOOT_COMPLETED" once system services are up and running in memory,
which is the time when it considered the
On 04/01/2016 12:44 PM, Tobias Hunger wrote:
Hi Jóhann and Vasiliy,
IIRC both coreos and chormeOS only mark a boot as successful after
talking to their respective update servers. The assumption apparently
is that the OS can fix itself when it is able to communicate properly
with its own update s
On 04/01/2016 03:15 PM, Alex Crawford wrote:
On 04/01, Jóhann B. Guðmundsson wrote:
That makes no sense that an boot is not market completed until it manage
to contact it's update servers but inline with other hacks coreOS is
doing in relation with systemd.
To what hacks, exactly, ar
On 04/01/2016 03:15 PM, Tobias Hunger wrote:
On Fri, Apr 1, 2016 at 4:59 PM, Jóhann B. Guðmundsson
wrote:
That makes no sense that an boot is not market completed until it manage to
contact it's update servers but inline with other hacks coreOS is doing in
relation with systemd.
I se
On 04/05/2016 08:40 AM, Lennart Poettering wrote:
one day of hands-on
training sessions.
Who will be training what exactly?
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/system
On 04/06/2016 09:15 AM, Łukasz Stelmach wrote:
Hi,
I've hit a problem caused by a mix of: automounting + glibc + udev + my
partition layout. Apparently it is impossible to make /var automountable
because udev (which needs to enumerate devices befor mounting them) is
trying to connect to /var/r
Anyone know that centos is not running the latest version(s) of systemd
required for the upstream bug tracker so one has to ask what
notification spam is this
"Can one of the admins verify this patch?"
JBG
___
systemd-devel mailing list
systemd-devel@
On 04/12/2016 02:43 PM, Lennart Poettering wrote:
On Tue, 12.04.16 11:52, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
Anyone know that centos is not running the latest version(s) of systemd
required for the upstream bug tracker so one has to ask what notification
spam is this
"Ca
Open up a support case with Red Hat since that's what you are paying for.
On 05/04/2016 08:40 AM, Marco Giunta wrote:
Hi at all,
I've a problem with automount features of systemd. I need to mount two
nfs share in this way:
/srv/nfsnfs-server.example.com:/share1
/srv/nfs/nested
On 01/07/2011 03:01 AM, Michael Biebl wrote:
What's going wrong here? Is mount.vboxsf to blame or systemd?
If I can recall correctly reading sometime ago somewhere on the web
there was/is an *communication* issue between "mount" and "mount.vboxsf"
which showed up when it was issued from a she
On 01/19/2015 02:18 PM, Dan Kenigsberg wrote:
How should this be implemented in the realm of systemd?
I would think via udev rule + systemd-networkd
What are ovirt's plan regarding systemd-networkd support/integration?
JBG
___
systemd-devel mailing
On 01/19/2015 09:57 PM, Dan Kenigsberg wrote:
On Mon, Jan 19, 2015 at 04:51:48PM +, "Jóhann B. Guðmundsson" wrote:
On 01/19/2015 02:18 PM, Dan Kenigsberg wrote:
How should this be implemented in the realm of systemd?
I would think via udev rule + systemd-networkd
Could you
On 01/20/2015 03:19 PM, Martin Pitt wrote:
initial generic feedback
We only provide backwards compatibility with initscript which are lsb
compliance and I dont think . ending on a script confirms to
that standard hence that test should be unnecessary and that initscript
be fixed upstream a
On 01/21/2015 09:46 AM, Martin Pitt wrote:
while working on the sysv generator, some more cases came up where the
recently introduced "Provides:" symlink handling [1] causes trouble
[2]. As soon as you have backup files like /etc/init.d/foo.bak, you'll
get a "foo.service -> foo.bak.service" link
On 01/21/2015 03:43 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jan 21, 2015 at 11:08:44AM +0100, Martin Pitt wrote:
>So I expect if it gets dropped upstream, a lot of distros (and all the
>major ones) will have to bring that back; it's IMHO better to just
>maintain it upstream by the distro
On 01/21/2015 08:00 PM, Michael Biebl wrote:
2015-01-21 20:56 GMT+01:00 "Jóhann B. Guðmundsson" :
On 01/21/2015 03:43 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jan 21, 2015 at 11:08:44AM +0100, Martin Pitt wrote:
So I expect if it gets dropped upstream, a lot of distros (a
On 01/27/2015 12:40 PM, Tom Gundersen wrote:
Hi Dan,
On Mon, Jan 19, 2015 at 3:18 PM, Dan Kenigsberg wrote:
I'm an http://oVirt.org developer, and we plan to (finally) support
SR-IOV cards natively. Working on this feature, we've noticed that
something is missing in the platform OS.
If I mai
On 01/27/2015 01:41 PM, Martin Polednik wrote:
- Original Message -
From: "Lennart Poettering"
To: "Martin Polednik"
Cc: "Andrei Borzenkov" ,
systemd-devel@lists.freedesktop.org, ibar...@redhat.com
Sent: Tuesday, January 27, 2015 2:21:21 PM
Subject: Re: [systemd-devel] persisting sr
On 01/27/2015 10:48 PM, Lennart Poettering wrote:
Another idea might be to simply accept that activating the swap by two
names at the same time can happen concurrently, and teach mkswap in
some way to handle this gracefully.
For example, mkswap could learn a new switch --idempotent or so, which
On 01/28/2015 12:24 AM, Lennart Poettering wrote:
On Tue, 27.01.15 17:17, Chris Murphy (li...@colorremedies.com) wrote:
> >The problem is simply that we cannot know in advance that /dev/sda7
> >and /dev/disk/by-uuid/c0e7978b-f82b-4b7f-b72b-6717f6909abc will
> >eventually refer to the same devi
On 02/02/2015 03:32 PM, Dimitri John Ledkov wrote:
On 2 February 2015 at 15:14, Sebastien Bacher wrote:
Hey systemd hackers,
While trying systemd-bootchart on my Ubuntu vivid system I ran into some
issues. My system has upstart as /sbin/init, but I use
init=/lib/systemd/systemd and that works
On 02/04/2015 09:20 PM, Lennart Poettering wrote:
On Wed, 04.02.15 22:01, Lennart Poettering (lenn...@poettering.net) wrote:
>On Wed, 04.02.15 15:06, Martin Pitt (martin.p...@ubuntu.com) wrote:
>
> >Hey,
> >
> >Lennart Poettering [2015-02-04 13:42 +0100]:
> > >Well, but their enablement stat
On 02/12/2015 04:38 AM, Michael Biebl wrote:
2015-02-11 20:12 GMT+01:00 Lennart Poettering :
So, I have discussed this with Kay, David, Daniel, and co. And we
kinda came to the conclusion that we might as well just drop the
configurability where runlevel3-5.target point to. If we drop that, we
On 02/15/2015 04:21 PM, Christian Seiler wrote:
Hi,
I just noticed that sysv-generator doesn't handle
/etc/insserv/overrides (e.g. older SuSE, Debian) or /etc/chkconfig.d
(e.g. RHEL <= 6, Centos, old Fedora), it just ignores it, thus not
retaining administrator overrides to init script headers.
On 02/16/2015 11:32 AM, Christian Seiler wrote:
Sure, in an ideal world. But as I said in my initial mail, if you have
crappy scripts provided by third-parties, this is not always an option.
And I don't think init scripts are going to fully disappear in the next
10 years, it's not realistic - e
On 02/16/2015 03:42 PM, Cristian Rodríguez wrote:
May be in /sbin or /usr/sbin
You might want to resubmit this to including the 57600 baud rate request
from Jeff in the process ( 115200,57600,38400,9600 ) ;)
JBG
___
systemd-devel mailing list
sys
On 02/16/2015 05:40 PM, Lennart Poettering wrote:
On Mon, 16.02.15 17:39, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
On 02/16/2015 03:42 PM, Cristian Rodríguez wrote:
May be in /sbin or /usr/sbin
You might want to resubmit this to including the 57600 baud rate request
from Jeff in
On 02/27/2015 06:31 PM, dennis.mur...@wipro.com wrote:
I have a fedora 21 system that where I mount an nilfs2 file system. I use a
simple /etc/modules-load.d/nilfs.conf file to load the kernel module and have
an entry in the fstab. The file system mounts on boot as it should, but the
nilfs-c
On Feb 28, 2015 6:41 PM, "Lennart Poettering"
wrote:
>
> On Fri, 27.02.15 19:19, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
>
> > On 02/27/2015 06:31 PM, dennis.mur...@wipro.com wrote:
> > >I have a fedora 21 system that where I mount an nilfs2 file sy
On 03/05/2015 02:46 PM, system_error wrote:
Mar 5 14:55:45 desktop kernel: [ 1140.258095] nm-connection-e[2123]:
segfault at 1326510 ip 01326510 sp 7fff11ebda18 error 15
I'm not sure how you came to the conclusion that NetworkManager
segfaulting is systemd's fault but file a bug
Heyja
Should this not be dropped and *DE write,integrate/implement an
graphical frontend to systemd for themselves?
It's not like this is receiving the love it needs, hence I'm pretty sure
nobody is using this.
JBG
___
systemd-devel mailing list
s
On 03/30/2015 10:32 PM, Shawn Landden wrote:
On Mon, Mar 30, 2015 at 1:35 PM, "Jóhann B. Guðmundsson"
wrote:
Heyja
Should this not be dropped and *DE write,integrate/implement an graphical
frontend to systemd for themselves?
It's not like this is receiving the love it n
On 03/31/2015 02:30 AM, Shawn Landden wrote:
On Mon, Mar 30, 2015 at 4:02 PM, "Jóhann B. Guðmundsson"
wrote:
>
>
>On 03/30/2015 10:32 PM, Shawn Landden wrote:
>>
>>On Mon, Mar 30, 2015 at 1:35 PM, "Jóhann B. Guðmundsson"
>> wrote:
>>
On 03/31/2015 01:47 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Mar 31, 2015 at 07:31:31AM +, "Jóhann B. Guðmundsson" wrote:
>What I'm proposing is that we dropped that proof of concept since
>it's not being maintained, there exist better alternatives thus
On 03/31/2015 02:09 PM, Michael Biebl wrote:
2015-03-31 15:47 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
On Tue, Mar 31, 2015 at 07:31:31AM +, "Jóhann B. Guðmundsson" wrote:
What I'm proposing is that we dropped that proof of concept since
it's not being maintained
On 03/31/2015 02:27 PM, Michael Biebl wrote:
>And from the looks of it the Red Hat desktop team maintainers in Gnome seem
>to be expecting the Gnome users to be using Red Hat's own product cockpit to
>take care of that.
sorry, but that's not a real replacement for systemadm. Don't want to
run
On 03/31/2015 02:58 PM, Michael Biebl wrote:
When I made the final ConsoleKit release, I added a NEWS entry, saying
that this software was discontinued and pointing to the replacements.
http://cgit.freedesktop.org/ConsoleKit/commit/?id=af75e100dc4d4fac2e1633aa134e40e390d38918
We could do some
On 03/31/2015 02:30 PM, Michael Laß wrote:
Am Montag, den 30.03.2015, 20:35 + schrieb "Jóhann B. Guðmundsson":
It's not like this is receiving the love it needs, hence I'm pretty sure
nobody is using this.
Is there a replacement for systemd-gnome-ask-password-agent
On 03/31/2015 05:32 PM, Lennart Poettering wrote:
On Mon, 30.03.15 20:35, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
Heyja
Should this not be dropped and *DE write,integrate/implement an graphical
frontend to systemd for themselves?
It's not like this is receiving the love it
On 04/01/2015 12:33 PM, Jan Synacek wrote:
---
src/tmpfiles/tmpfiles.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 494fd1a..9280fd7 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -10
On 04/01/2015 01:04 PM, Lennart Poettering wrote:
On Wed, 01.04.15 12:40, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 494fd1a..9280fd7 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1099,9
On 04/01/2015 02:37 PM, Lennart Poettering wrote:
Note that I intend to add more subvolume lines to tmpfiles even. For
example, I am pretty sure /home should be created as subvolume if it
doesn't exist already, and similar.
I'm afraid that will still only work on a single host setup (
laptop
On 04/02/2015 08:31 AM, Lennart Poettering wrote:
On Wed, 01.04.15 21:04, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
On 04/01/2015 02:37 PM, Lennart Poettering wrote:
Note that I intend to add more subvolume lines to tmpfiles even. For
example, I am pretty sure /home should be
On 04/02/2015 01:21 PM, Lennart Poettering wrote:
Well, I disagree. And yeah, I still think that /var/lib/machines
should be a subvolume, if it is not created manually as something else
before. I hear no convincing case why it shouldn't be one.
I argue that we should default to directory crea
On 04/02/2015 03:48 PM, Lennart Poettering wrote:
On Thu, 02.04.15 14:33, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
On 04/02/2015 01:21 PM, Lennart Poettering wrote:
Well, I disagree. And yeah, I still think that /var/lib/machines
should be a subvolume, if it is not created
On 04/08/2015 06:53 AM, Greg KH wrote:
"all"? Ubuntu ships newer kernels than 3.4, if not, please take it up
with that vendor, it's not the community's job to support obsolete,
years-old software that everyone has moved on from a long time ago for
very good reasons.
Hmm there has to be some
On 04/09/2015 11:04 AM, Lennart Poettering wrote:
On Thu, 09.04.15 10:51, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
My above questions where directed directly at Lennart since you cannot know
if Lennart's assumption which he bases his decisions on are
premature,correct, wro
On 04/09/2015 08:54 AM, Lennart Poettering wrote:
Of course, this only works for GPT systems, i.e. modern systems, and
modern systems probably wouldn't run ext234 anyway, so maybe it's not
worth it... Actually neither xfs nor btrfs nor reiserfs appear to
require an fsck still, it's only ext234 an
On 04/09/2015 10:30 AM, Reindl Harald wrote:
Am 09.04.2015 um 12:17 schrieb Jóhann B. Guðmundsson:
On 04/09/2015 08:54 AM, Lennart Poettering wrote:
Of course, this only works for GPT systems, i.e. modern systems, and
modern systems probably wouldn't run ext234 anyway, so maybe it&
On 04/20/2015 01:58 PM, Lennart Poettering wrote:
systemd has no provisions for anything like this and I have doubts it
really should have. I mean, normal programs retain ccess to the cgroup
tree, so you could readd whatever you restore back in the cgroups, but
that's hardly sufficient to make
On 04/20/2015 02:35 PM, Lennart Poettering wrote:
On Mon, 20.04.15 14:33, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
On 04/20/2015 01:58 PM, Lennart Poettering wrote:
systemd has no provisions for anything like this and I have doubts it
really should have. I mean, normal programs
On 04/20/2015 02:49 PM, Lennart Poettering wrote:
On Mon, 20.04.15 14:43, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
I thought fancy enterprise features like this was on hold until networkd was
"ready" ?
This is not an enterprise feature. It's a promise one cannot ke
On 09/12/2014 08:57 AM, lux-integ wrote:
Greetings,
I am attempting to learn to use systemd. I have an IPtbales script I intend
to transform from a bash script to a systemd service file.
If it had been technically possible to migrate the legacy sysv
initscript to native systemd we ( as in
On 09/15/2014 04:30 PM, Chris Murphy wrote:
The issue is when booting live media (e.g. for OS installs), the autoactivation
is causing some installer confusion.
Should be fixed downstream in Anaconda/Live script.
___
systemd-devel mailing list
syste
On 09/16/2014 01:16 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Sep 16, 2014 at 01:21:30PM +0200, Pavel Raiskup wrote:
Hi,
consider the situation that admin has /etc/systemd/system/a.service, which
includes via .include the /usr/lib/systemd/system/a.service. Then in our
case there exists a
On 09/17/2014 12:26 PM, David Sommerseth wrote:
Hi,
I've been playing with the systemd feature enabled in OpenVPN. And I
propose this change to systemd-ask-password to avoid masking usernames.
I tried looking for alternative ways querying for usernames through
systemd without finding a good
On 09/18/2014 01:24 PM, Emil Renner Berthing wrote:
The real reason is of course that I'd like to see systemd running
on my router and other small devices that usually run some OpenWRT
derivative.
The openwrt community is still going forward with their (re)-invention
of init system called pro
On 09/18/2014 02:20 PM, Philippe De Swert wrote:
Hi,
On 18/09/14 17:13, Emil Renner Berthing wrote:
On 18 September 2014 16:10, "Jóhann B. Guðmundsson" wrote:
On 09/18/2014 01:24 PM, Emil Renner Berthing wrote:
The real reason is of course that I'd like to see systemd runni
Is the plan to introduce an repair switch or is the plan to inform the
users how they should proceed if that is not the case since users are
getting confused when they encounter journal errors like these
Data object missing from hash at entry...
Data object references invalid entry at...
Invali
On 09/19/2014 02:10 PM, Zbigniew Jędrzejewski-Szmek wrote:
journalctl --file /var/log/xxx.journal | systemd-journal-remote --file
/tmp/xxx.journal -
mv /tmp/xxx.journal /var/log/xxx.journal
We could easily provide the functionality to do this automatically,
but I don't know how useful th
On 09/21/2014 02:25 AM, Bastien Nocera wrote:
Ideas on how this should be implemented?
Just make sure this gets implemented in the right place and ensure this
can be disabled and is disabled by default as well as have proper
permission since you dont want to grant the ability to friends who
On 09/21/2014 01:31 PM, Martin Steigerwald wrote:
in the light of the ongoing discussions on linux-kernel
Could you provide a link to that ongoing discussion that is taking place
in the kernel community regarding systemd?
Did you ever ask yourself why your project provokes that amount of r
On 09/21/2014 10:23 PM, Reindl Harald wrote:
Am 22.09.2014 um 00:15 schrieb Jóhann B. Guðmundsson:
>Now alot of the resistance and polarity that is taking place like in the url
you pointed at is hiding itself behind
>their misinterpretation of the so called "Unix philosophy" a
On 09/21/2014 11:09 PM, Reindl Harald wrote:
Am 22.09.2014 um 00:48 schrieb Jóhann B. Guðmundsson:
On 09/21/2014 10:23 PM, Reindl Harald wrote:
Am 22.09.2014 um 00:15 schrieb Jóhann B. Guðmundsson:
Now alot of the resistance and polarity that is taking place like in the url
you pointed at
On 09/22/2014 11:40 AM, Reindl Harald wrote:
Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson:
On 09/22/2014 09:23 AM, Reindl Harald wrote:
Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson:
The reason for increased log entries in the journal is that more things
are happening now
On 09/22/2014 12:07 PM, Reindl Harald wrote:
Am 22.09.2014 um 13:45 schrieb Jóhann B. Guðmundsson:
>On 09/22/2014 11:40 AM, Reindl Harald wrote:
>>Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson:
>>>On 09/22/2014 09:23 AM, Reindl Harald wrote:
>>>>Am 22.0
On 09/22/2014 12:58 PM, Reindl Harald wrote:
i suggest you get rid of that arrogance and some other developers
too because it's the reason for the subject and proves that you
*do not* care about users as long you have not the same opinion
you are the one demanding a friendly tone from me, well
On 09/30/2014 02:26 PM, Tom Gundersen wrote:
On Wed, Sep 17, 2014 at 2:26 PM, David Sommerseth wrote:
I've been playing with the systemd feature enabled in OpenVPN. And I
propose this change to systemd-ask-password to avoid masking usernames.
I tried looking for alternative ways querying fo
On 09/30/2014 04:08 PM, Colin Guthrie wrote:
"Jóhann B. Guðmundsson" wrote on 30/09/14 16:19:
Hmm will this make that password visible to anyone who can watch the
user monitor?
If that is the case then this is an bad practice since nothing should
ever echo the input for passwords
I
On 10/04/2014 05:55 AM, Aleksei Besogonov wrote:
With all the recent noise about systemd abusing its position with the
way it takes over logging I’ve been thinking about a way to solve it.
As far as I understand the following holds:
- Systemd takes over /dev/log socket which is normally served
On 10/08/2014 11:41 PM, Lennart Poettering wrote:
TODO list to allow services also when they have no ExecStart= but with
an ExecStop=, but this has not been implemented yet.
What's the usecase for this behaviour?
JBG
___
systemd-devel mailing list
s
On 10/09/2014 02:26 PM, Lennart Poettering wrote:
On Thu, 09.10.14 12:14, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
On 10/08/2014 11:41 PM, Lennart Poettering wrote:
TODO list to allow services also when they have no ExecStart= but with
an ExecStop=, but this has not been implemented
On 10/09/2014 08:28 PM, "Jóhann B. Guðmundsson" wrote:
What I dont understand what's the usecase for somekind of ExecStop=
modfications, why do we need to do that?
Note that the Before= in the test script is failing to pass which
indicates something is borked in the orderin
On 10/09/2014 11:35 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Oct 09, 2014 at 01:41:24AM +0200, Lennart Poettering wrote:
The ExecStart=/bin/true we just add because current systemd versions
refuse to run service units that have no ExecStart= set. It is on the
TODO list to allow services a
On 10/22/2014 09:44 AM, Lennart Poettering wrote:
So, I thought myself a couple of times about adding a cron generator
upstream
As far as I can tell generators serve only one purpose and that is to
bridge an gap to allow users of consumers of systemd to migrate to it's
native format hence I
On 10/22/2014 11:16 AM, Alexandre Detiste wrote:
>Why not migrate what needs to be migrated to native system timer formats
>for those relevant component and leave the rest be handled by the
>traditional cron daemons since those two components complement each
>others shortcomings ?
"The rest"
101 - 200 of 420 matches
Mail list logo
