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 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
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 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
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).
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
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?
___
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
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
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
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
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
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
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
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
>
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:
>
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 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
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 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
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 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
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 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 ?
>
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
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 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 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 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 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
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 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 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 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
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
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
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
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
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
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 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
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.
___
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 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
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 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
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.
_
+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
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
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.
___
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
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
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, 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.
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
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
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
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
Bumping this for review.
___
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
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
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
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
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
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.
_
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
+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
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
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
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 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.
-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 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
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 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
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 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
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 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
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 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 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
Applied. Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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/
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
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
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
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
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 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
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 Wed, Feb 19, 2014 at 10:57 AM, Lennart Poettering
wrote:
> Now, as far as I can see I didn't break your scalibility changes,
> but I was wondering if you could give this a test run with your huge
> number of units setup?
With 4000 units (2000 sockets and 2000 corresponding services with
CPUSha
On Wed, Feb 19, 2014 at 10:57 AM, Lennart Poettering
wrote:
> did you see the changes I made to the cgroup mask propagation bits? I
> reworked some code there to make sure that the mask doesn't keep
> increasing, but actually can lose bits again if cgroup properties are
> unset. Now, as far as I c
The only thing in master I'm still having to patch in production is
the is-enabled code path so it doesn't look up all the symlinks. I
don't see that as a release blocker, though.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://l
On Wed, Feb 12, 2014 at 12:37 PM, Tomasz Torcz wrote:
> That's some downstream distro bug. And this is Fedora mailinglist.
> RHEL issues are offtopic here.
This is not a Fedora mailing list at all.
___
systemd-devel mailing list
systemd-devel@lists.fre
+1 on no crashing with invalid user input
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
In order to maximize consistency with newly committed options in
systemd-nspawn, would it make sense to allow independent configuration
of the process and file labels instead?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists
"Elided" sees widespread use in the kernel and libc for locks:
http://lwn.net/Articles/534758/
They're not referring to adding ellipses, though. They're talking
about just removing locks. In that sense, "elide" and "ellipsize" are
not synonyms.
___
syste
Pushed with the following changes:
* Lennart's suggestions for option names.
* Lennart's other suggestion for no asprintf() in the options
processing. Moved the concatenation to strjoin() on use.
* Removed redundant trailing NULL in the arguments to strjoin().
* Removed invalid option "-s" from
On Tue, Feb 4, 2014 at 5:22 AM, Lennart Poettering
wrote:
> processlabel
The actual code processes this option as "label." I'll fix all of this
up (including the asprintf) and then commit.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.o
1 - 100 of 182 matches
Mail list logo
