There could be a (potentially socket-activated) service that handles
requests for image downloads.
On Tue, May 31, 2016, 11:06 Brandon Philips wrote:
> Hello Everyone-
>
> The rkt container engine wants to run with different permissions pre-start
> and start. In pre-start it needs to fetch/downl
You either need a load balancer (less elegant) or need to make use of the
Linux kernel's SO_REUSEPORT option so the new application can bind to the
same port as the old one (at which point the old application should unbind
the port and shut itself down).
On Fri, Jul 8, 2016 at 9:07 AM Lennart Poettering
wrote:
> Ultimately it's really a design decision: tabular file formats have
> the benefit of being a lot more dense, but are neither particularly
> extensible nor self-explanatory (as you need to know what each column
> means). Unit files are a b
Dokku would be about a 5-10 lines of shell script with services running in
systemd.
On Wed, Jul 13, 2016, 20:41 Kai Hendry wrote:
> On Sat, 18 Jun 2016, at 07:56 PM, Paul Menzel wrote:
> > Is that possible by just using systemd, or is a load balancer like
> > HAProxy or a special NGINX configura
On Thu, Jul 14, 2016, 19:07 Kai Hendry wrote:
> I would love to see that 10 lines of shell you claimed, but I think you
> might be underestimating the fine work that went into Dokku!
>
It's not so much underestimating the work in Dokku as much as leveraging
what systemd and a tool like haproxy p
For what it's worth, I try to encourage projects to identify their bindings
as simply for systemd, even if the journal support is the first (and only)
set of APIs available. It's just so easy to support the other APIs once the
journal is already supported, and daemons that want to use the journal
s
On Mon, Jun 1, 2015 at 11:20 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> On Mon, Jun 01, 2015 at 08:12:37PM +0200, David Herrmann wrote:
> > [1] https://github.com/systemd-devs/systemd
> Is there a particular reason not to use the existing
> https://github.com/systemd/systemd ?
>
Looks like everything's in place now at the new github.com/systemd/systemd
home.
I've halted the Jenkins CI from pushing to that repository (which was
formerly the mirror updated whenever CI passed). I'll probably update CI to
merely push a branch like "master-passing" so there's still a way to ge
On Tue, Jun 2, 2015 at 5:03 PM Kay Sievers 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 s
Let's just try the GitHub tracker. I like how it associates issues with
pull requests and supports auto-linking for commit IDs, user names, and
other issue numbers. Is there any serious use case for systemd upstream it
doesn't support?
___
systemd-devel m
On Fri, Jun 26, 2015 at 7:00 AM Mantas Mikulėnas wrote:
> On Fri, Jun 26, 2015 at 4:15 PM, Lesley Kimmel
> wrote:
>
>> Hi all;
>>
>> I've been working with RHEL5/6 for the past several years and have
>> developed many init scripts/services which generally use lock files and PID
>> files to allow
I think you should look into forwarding your logs to a more sophisticated
aggregator, like the ELK stack.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Tue, Sep 8, 2015 at 10:48 AM Simon McVittie <
simon.mcvit...@collabora.co.uk> wrote:
> As far as I understand it, this duplication is present to give the
> sysadmin a choice between two ways to run sshd, depending on this
> particular ssh server's requirements.
>
> If ssh access is frequently u
On Wed, Sep 23, 2015, 18:14 Lennart Poettering
wrote:
> We are close to being sold out now, only 14 tickets are still
> available now. If you intend to attend, make sure to register for the
> conference *now*, before it's too late and all tickets are gone.
>
> Register here:
>
> https://systemd.e
On Mon, Sep 28, 2015 at 1:19 AM Alessio Igor Bogani <
alessioigorbog...@gmail.com> wrote:
> Hi systemd developers and users,
>
> The systemd 219 brought with Yocto "Fido" can't set hostname supplied
> by DHCP on my Beaglebone:
>
> eth0: eth0: could not bring up interface:
>
If you only want one instance running, why not just create one service and
reconfigure/restart it?
On Mon, Oct 5, 2015, 09:04 Johannes Ernst wrote:
> I have a foo@.service. When started as
> systemctl start foo@abc
> I’d like all other currently active foo@… services to stop, and vice
>
I made a few minor GitHub team changes:
(1) The "Owners" team is now deleted. GitHub migrated the access this team
originally provided to an "owner" attribute, making the team unnecessary.
Leaving the team would have only caused the actual owners to be out-of-sync
with the named "Owners" team. You
In case anyone in the former owners group is checking here, you would have
received an email saying you've been removed from the "Core" team. GitHub
wanted me to rename it, so I did to "Core" before ultimately realizing it
served no further purpose. No one should have any less access to systemd
Git
On Wed, Oct 14, 2015 at 9:35 AM Jóhann B. Guðmundsson
wrote:
> What makes up that members list [1] in the first place?
>
I think it includes anyone on any team associated with the organization. It
also provides organization-level permissions for things like making new
projects (but not being an
I read up on PSD, and I expect you're using it for performance/hardware
longevity. Correct me if I'm wrong about this.
So, have you considered just mounting your home directory or a volume for
things like browser profile data with normally aggressive/unsafe options on
a normal file system? You can
The wording of your questions isn't clear to me. Do you mean that A and B
are socket-activated services, each requiring C? And when you say "the
message of A and the message of B," do you mean packets going to the
sockets for A and B?
If so, a packet going to A or B will also start C. The requests
Would you be interested in moving this work to the systemd umbrella project
on GitHub? You would still manage the team, but it may get more visibility.
On Fri, Nov 13, 2015, 19:27 Jan Synáček wrote:
> Hello,
>
> if anybody lurking here and hacking on systemd also likes scheme, I
> created bindin
Rebooting an old thread now that we're finally testing this out.
> "strace" should do the job. It should give you a pretty good idea of all
syscalls a process uses. That's what I used when testing SyscallFilters=.
This turns out to be less useful than it seems.
There are two major ways to invoke
On Fri, Jan 22, 2016 at 1:36 PM Mantas Mikulėnas wrote:
> There's a third way:
>
> ExecStart=/usr/bin/strace -D -ff -o /tmp/myservice.trace
> /usr/bin/myservlce --foo
>
Do you know if that would pass through file descriptors for socket
activation?
___
On Tue, Mar 24, 2015 at 4:29 AM, WaLyong Cho wrote:
> Could anyone explain why?
An admin using CPUShares= or a similar proportional CGroup controller
probably assumes that setting the shares to twice the default (for
example) increases the relative proportion of resources for that unit.
However,
On Tue, Mar 24, 2015 at 4:29 AM, WaLyong Cho wrote:
> If this can be configurable, how about add a configuration for cgroup
> mask propagation to siblings?
I believe the way to prevent propagation is to separate the units into
different slices.
___
syst
On Thu, Mar 26, 2015 at 7:33 PM, WaLyong Cho wrote:
> Thanks, understood. But I think this propagation is needed only for
> taking weight argument such like CPUShares=weight,
> StartupCPUShares=weight, BlockIOWeight=weight,
> StartupBlockIOWeight=weight, BlockIODeviceWeight=device weight. For
> ex
On Fri, Mar 27, 2015 at 7:56 PM, WaLyong Cho wrote:
> Hmm, it seems not. When I added MemoryLimit= option to just one service,
> cgroups for every unit were generated on memory cgroup.
It looks like memory_limit and cpu_quota_per_sec_usec both have this
potential issue. The other four controllers
On Tue, Apr 21, 2015 at 12:26 AM, Martin Pitt wrote:
> So I see no use case for idle timer based cleanup. Can you please
> explain why they are better than on-demand cleanup?
We do it on Pantheon's infrastructure because many daemons have a
resource footprint that is more than just allocated memo
Just to give some context, at Pantheon, we're working on optimizations
for the "enabled" part of systemd core. The first step we're doing is
enhancing the test suite. The additions here pass on master and will
also pass with the changes we'll submit after more tests are in core.
___
It would be good if the test units were more basic, not things
including "Crash recovery kernel arming." This makes it seems like the
contents are substantial to the tests, when they're not. Just run
something like ExecStart=/usr/bin/echo to make it clear that the units
are stubs. Then, anything bu
I think the test additions need to be rebased into a single commit
onto master rather than the initial patch plus the fixes as a second
commit.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinf
It looks like newlines at the end of the new files are inconsistent
("No newline at end of file").
Other than that +1. It's great to add tests, have them pass on master,
optimize master (the next patch), and then still have them pass.
___
systemd-devel m
Mark Theunissen, part of the team here at Pantheon, got our changes
upstream in version 5.05:
https://www.stunnel.org/sdf_ChangeLog.html
Progress!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/li
I would like to discuss the state of systemd scalability on dense/large
systems.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
I'm responding here only to the systemd list.
On Tue, Oct 14, 2014 at 4:35 PM, Martyn Russell wrote:
> Another option would be to use systemd. However, I am mindful that it's not
> available everywhere just yet (but soon will be I hear) I am also aware, I
> might get a biased answer here :)
syst
Changes like this make config management so much easier. +1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Fri, Oct 17, 2014 at 9:03 AM, Paassen, Hiram van
wrote:
> Is it possible to start multiple different services from one process?
In short, that is not sanely possible. If you care about latency for
accessing the service, even on the first request, then just don't
activate it using DBus. Enable
On Fri, Oct 17, 2014 at 9:47 AM, Leslie Zhai wrote:
> But there are only lots of use cases about Linux Server and web application,
> as a Linux desktop geek, I often consider about the disadvantage of
> traditional deployment of Linux desktop application. Krita, for example, an
> awesome digital p
On Thu, Oct 16, 2014 at 6:07 AM, Martyn Russell wrote:
> True, but some users (I am guessing with low end machines) are complaining
> about Tracker while they're trying to use their system.
I said that having an active user does not inherently imply resource
contention, not that they're uncorrela
On Thu, Oct 23, 2014 at 5:15 AM, Lennart Poettering
wrote:
> With your patch you generate a system-wide cache for that, but when do
> you flush it precisely? What's the logic there?
It updates on daemon-reload or daemon-reexec, consistent with how we
load modified unit files. "systemctl enable/di
On Fri, Oct 17, 2014 at 1:24 PM, Lennart Poettering
wrote:
> Does this make sense?
Speaking as a nano user and someone who barely knows how to quit vim,
I still think the decision of the default editor should be "vi" or the
distribution's choice.
___
sy
It's not ridiculous, but it's also no better. This patch still blocks
the main event loop during each lookup.
Proper integration of non-blocking lookup would involve using
sd_resolve_get_fd() to integrate with the main event loop.
___
systemd-devel maili
On Thu, Feb 20, 2014 at 2:25 PM, Paul Menzel
wrote:
> Or is there a reason why systemd should not be used for that?
Distro portability, but that's rapidly dying as a reason.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists
On Mon, Feb 24, 2014 at 2:08 PM, Lennart Poettering
wrote:
> logind is now a lot more aggressive when suspending the
> machine due to a closed laptop lid. Instead of acting only
> on the lid close action it will continuously watch the lid
> status and act on it. This
On Thu, Feb 27, 2014 at 12:35 PM, Vincent Batts wrote:
> Can we get a Makefile target for compiling the
> systemd-socket-proxyd as statically linked? For it to be portable for
> any guest container.
I think that would be neat. While I wrote much of that proxy, I'm not
versed well enough on linkin
This is a lot of code, and this approach is largely obsoleted by
link-local IPv6 addressing, which also has the benefits of being
simpler, deterministic (at least with RFC 4862), and collision-proof.
Both Apple [1] and Microsoft [2] prefer IPv6 link-local as the best
practice.
Is it really that im
I'll be attending the Linux Storage, Filesystem & MM Summit in March.
Are there any topics germane to systemd I should put on the agenda or
discuss with other folks there?
Things I have in mind so far:
* Next steps for mount and automount units
* That's it so far.
I'm mostly attending for my c
On Sat, Mar 1, 2014 at 12:46 AM, 황재영 wrote:
> I've tried to build systemd(v43) with statically linking.
That version is ancient. I'm afraid you won't find much help with it
here. Have you tried a newer release?
___
systemd-devel mailing list
systemd-dev
When is startup considered over? I'd like if it meant before the
WantedBy unit was started so this value still has use for arbitrary
startup.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/
Applied. Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mon, Mar 3, 2014 at 5:47 PM, David Farning wrote:
> Several of the ground breaking ideas in systemd seem to come directly from
> launchd.
systemd makes no claim to be original or ground-breaking with many of
its ideas. As you mention, some come from launchd. Others come from
Solaris service ma
On Thu, Mar 6, 2014 at 2:57 PM, David Farning wrote:
> Now my philosophical sticking point is how big pid1 should be to do
> what it needs to do. Practically, I am trying to understand where
> those boundaries should be and how to communicate that information.
A large amount of systemd's code doe
On Thu, Mar 13, 2014 at 12:54 PM, Anand Neeli wrote:
> I have multiple systems, How do i forward logs from one system running
> systemd-journald to another remote systems journal service, so that all the
> logs are stored on a centralized machine.
>
> Have went through systemd-journal-gatewayd, bu
On Sun, Mar 16, 2014 at 11:29 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> Curl requires the whole file to be exported first, which isn't great,
> because it wants to give the content size in the header. I'm note
> sure if it is possible to tell it to not do that.
I'm think you just need to implement
It's already reported (by me):
https://bugs.freedesktop.org/show_bug.cgi?id=75185
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mon, Mar 24, 2014 at 12:16 PM, Lennart Poettering
wrote:
> So on Fedora tcpwrap is unlikely to go away soon.
Not necessarily. We just decided this morning in the server working
group that we would only include it if base OS insists:
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-03-25
Other than for zswap discussions, I spent the whole time on the
storage and file system side. I've filled in the topics that came up
(or I could topically ask about), and I have some good contacts now if
answering any others proves essential.
Outside the file system/MM space, at least one Ganesha
On Fri, Mar 28, 2014 at 12:41 PM, Lee Atkinson wrote:
> .reading the Fedora 18 Users Guide
Fedora 18 is not a currently supported release, and its systemd is
ancient by this mailing list's standards.
___
systemd-devel mailing list
systemd-devel@lists.fr
Oh dear. Perhaps there's a way to use cgroups data to more selectively
do cleanup when there's overlap between regular users and service
users?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinf
On Thu, Apr 3, 2014 at 12:03 PM, Florian Albrechtskirchinger
wrote:
> Both you and Tom Gundersen raised the point of assisting end-users with
> boot issues. 'dbg' (as suggested, shorthand for 'dbg=kri') is as
> concise and simple as it gets.
-1 on this because it moves in the opposite direction o
-1 on adding ConditionACPower=true
I frequently only plug in my laptop after putting it to sleep and then
disconnect it before waking it up again. It'd be possible to run
cleanup less frequently when on battery, but that would just delay the
work and increase the impact (which is pretty negligible
On Sat, Apr 5, 2014 at 4:06 PM, Jason St. John wrote:
> "init.debug" would be better than "systemd.debug", in my opinion. It
> is shorter (less typing and no possible end-user confusion over
> "systemd.debug" vs. "system.debug"), and it is init-agnostic. Other
> init systems (OpenRC, Upstart, etc.
On Tue, Apr 8, 2014 at 5:30 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> I think it is synchronized after successful jenkins runs, so it is always
> buildable
> and unit tests pass.
That's my GitHub mirror, not anything on freedesktop.org.
___
systemd-deve
On Tue, Apr 8, 2014 at 11:31 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> https://github.com/systemd/systemd is not yours?
Nope, that's mine. You were right. I misread the two trees as the
authenticated and anonymous git on freedesktop.org for some reason.
They were out of sync because CI broke. It
CI is back online, but test-dhcp-option is currently failing, so it
won't update on GitHub until that's fixed.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
+1 from me. Seems like a good bugfix.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Tests are back to passing, so GitHub is now in sync with the
freedesktop.org git.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Thu, Apr 10, 2014 at 9:01 PM, Lennart Poettering
wrote:
> Yuck, I figure we need to ignore RemoveIPC for all system users, not
> just for root.
This still seems dangerous to me. I'm sure I have services running
under users where I've forgotten the "system" flag for the users.
_
Maybe if any service is running something as a user *or* it's a system
user, that user is immune to RemoveIPC?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Posting here for discussion at the systemd hackfest today.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
This is a completed version of the patch Lennart and I worked on at
the hackfest. The version we worked on had separate string arguments
for each type of state. This patch harmonizes it more with the way
systemctl --state already works, which is an array of possible states
to match across all state
systemctl disable or systemctl mask. You also have to stop it first,
as that only changes the default.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Sun, May 11, 2014 at 9:30 AM, Alex B wrote:
> It's ok for one timer, but not for the set of them.
> In general I'm want to schedule all maintenance tasks to 5 a.m.
> or lunch break and forget about them.
> This applies both for distro provided timers an my own.
I'd personally like sort of time
Bumping this for review.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
An alternative workaround is to put the socket into a directory that
has the permissions desired. If you can't read the directory, you
can't use a socket in that directory.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.fr
On Wed, May 21, 2014 at 5:48 AM, Jason A. Donenfeld wrote:
> Temporary work around is to hard code IPs into NTP.
It'd be neat to do the following:
(1) Do a DNS lookup for NTP servers, fetching DNSSec information.
(2) If a signature/clock sync issue is the only barrier to validating
the response
One of the cleanest ways to do what you want is to create a
D-Bus-activated systemd service (or socket-activated, if that's more
appropriate). That allows activation completely outside the user's
session without elevated privileges. Of course, it requires
considerable work for each service to do it
Is there a downside to using KillMode=mixed instead?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Tue, May 27, 2014 at 10:55 PM, Jonathan Liu wrote:
> I suspect one downside is that if the container takes longer than the
> timeout to shutdown then it will go on a SIGKILL-ing spree... which
> could be a problem if a container process was in the middle of saving
> to disk while shutting down.
The CoreOS crew has already done most of this work by writing a native
Go implementation (rather than wrapping the C APIs).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Tue, Jun 10, 2014 at 6:07 AM, Dan Mace wrote:
> Which only handles writes via the Unix socket. The implementation we're
> prototyping supports journal queries in ways that (to my knowledge) aren't
> possible without either forking to external tools (e.g. journalctl) or
> linking to sd-journ
On Tue, Jun 17, 2014 at 4:33 AM, Mantas Mikulėnas wrote:
> I mean, as long as the first-listed server responds – and localhost always
> responds – then the fallback servers won't be used at all.
Localhost can be subject to two types of failure:
* The local daemon being down.
* The resources the
As someone who deploys developer VMs and production ones, this is
useful. Will it be possible to make units have ConditionDeployment=?
That would allow disabling, say, pushes of log messages to our log
aggregation servers from development and testing deployments.
___
I don't see much value in choosing a role from a predefined list.
Rarely do machines fit into one single, straightforward role.
It would be more useful to support machine tags/labels/roles that map
to units, especially if that's dynamically configurable using, say,
DHCP(v6). Then, something may be
+1 on anything that makes the journal faster on heavy workloads. It
remains a major bottleneck on our systems.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Is there a good way to empirically determine the additional calls
required for an application, sort of like selinux permissive mode?
We're often running user code on our servers, and we'd like to perform
analysis and gradually roll out filtering. We'd like to be as
non-disruptive as possible.
_
On Sun, Jul 6, 2014 at 3:32 PM, Tom Gundersen wrote:
> "yes" is a synonym for "both" and "no" for "none".
These are odd semantics, given that IPv6 is completely configurable
using router advertisements for even DNS information (that is, no DHCP
whatsoever). Perhaps the option should be Autoconfig
On Wed, Jul 16, 2014 at 7:29 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> This won't work, since proxyd now cannot connect to port 400.
There is now a way to make that work with JoinsNamespaceOf=
___
systemd-devel mailing list
systemd-devel@lists.freedeskto
On Thu, Jul 17, 2014 at 4:51 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> I'd try without Private* settings.
>
> Also, replace /usr/lib/systemd/systemd-socket-proxyd with
> '/bin/strace -o /tmp/log /usr/lib/systemd/systemd-socket-proxyd'
> and look at the log file.
Yes, get it working without Private
Would you be willing to post the entire unit files for everything
here, just so future users can see them? Presumably, you're using
JoinsNamespaceOf=proxy-to-directory-400.service in
vgp.master-ldap-400.service?
___
systemd-devel mailing list
systemd-deve
On Tue, Nov 12, 2013 at 10:36 AM, Peeters Simon wrote:
> in 2b5c5383 you reference src/libsystemd-bus/bus-dump.c and
> src/libsystemd-bus/bus-dump.c , but those files aren't included, could
> you please commit them asap?
>
I've already emailed him. In the mean time, you can use one of the earlier
Is the code already assuming megabits in the "speed" variable?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Tue, Nov 12, 2013 at 3:27 PM, Jan Engelhardt wrote:
> As far as I can see, ethtool-util.c in systemd merely passes that on to
> ethtool, and /usr/include/linux/ethtool.h says "MBps" in its comments.
>
The capitalized "B" is generally "bytes."
___
sy
On Tue, Nov 12, 2013 at 4:06 PM, Jan Engelhardt wrote:
> In any case, even if the ethtool structures awkwardly specified the use
> of "bytes", the user-visible part should be in "bits", and this patch
> was to give an impetus.
>
I won't commit the patch unless there's clarity that setting the va
+1 on the unit in the value.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Based on the autotools docs, it looks like this would change the
default to enabled "maintainer mode," meaning developers would need to
run --disable-maintainer-mode to maintain the current behavior. Is
this correct?
If that's so, then maybe the suggested ./configure command from
./autogen.sh shou
Thanks. Applied.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Thanks. Applied.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Thanks. Applied.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
1 - 100 of 182 matches
Mail list logo