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
On Thu, Feb 20, 2014 at 2:25 PM, Paul Menzel
paulepan...@users.sourceforge.net 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
On Thu, Feb 27, 2014 at 12:35 PM, Vincent Batts vba...@redhat.com 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
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
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
On Sat, Mar 1, 2014 at 12:46 AM, 황재영 j-zero.hw...@samsung.com 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
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
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 dfarn...@gmail.com 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
On Thu, Mar 6, 2014 at 2:57 PM, David Farning dfarn...@gmail.com 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
On Thu, Mar 13, 2014 at 12:54 PM, Anand Neeli anand.ne...@gmail.com 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
On Sun, Mar 16, 2014 at 11:29 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl 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
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
lenn...@poettering.net 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:
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 linuxle...@gmail.com 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
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
On Thu, Apr 3, 2014 at 12:03 PM, Florian Albrechtskirchinger
falbrechtskirchin...@gmail.com 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
-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
On Sat, Apr 5, 2014 at 4:06 PM, Jason St. John jstj...@purdue.edu 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,
On Tue, Apr 8, 2014 at 5:30 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl 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.
On Tue, Apr 8, 2014 at 11:31 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl 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
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
lenn...@poettering.net 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
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
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 pkunk...@gmail.com 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
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
On Wed, May 21, 2014 at 5:48 AM, Jason A. Donenfeld ja...@zx2c4.com 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
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
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
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 dm...@redhat.com 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
On Tue, Jun 17, 2014 at 4:33 AM, Mantas Mikulėnas graw...@gmail.com 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.
*
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
+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 t...@jklm.no 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
On Wed, Jul 16, 2014 at 7:29 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl 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
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
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 jeng...@inai.de 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.
On Tue, Nov 12, 2013 at 4:06 PM, Jan Engelhardt jeng...@inai.de 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
+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
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
Thanks. Applied.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
I'm pretty confident in the accuracy of the controller mask
aggregation, especially given the new unit test. Here are the main
review questions.
Is it okay to couple realizing the cgroups and applying the attributes
the way the patch does? Before, we were often applying the attributes
for all of
On Wed, Nov 20, 2013 at 2:18 AM, Marcos Felipe Rasia de Mello
marcos...@gmail.com wrote:
ConditionFileIsExecutable=/usr/sbin/hdparm
It seems sketchy to me to put the executable in ExecStart into
ConditionFileIsExecutable. Is it supposed to fail silently when hdparm
is missing?
On Wed, Nov 20, 2013 at 3:00 AM, Marcos Felipe Rasia de Mello
marcos...@gmail.com wrote:
In my first attempts, I forgot to install hdparm. ;)
Shouldn't you only drop the rules and service with installation of hdparm, then?
___
systemd-devel mailing
On Wed, Nov 20, 2013 at 5:33 AM, Oleksii Shevchuk alx...@gmail.com wrote:
Any suggestions how to find the problem?
Valgrind
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Just to suggest the wildly different approach I mentioned on IRC, we
could treat addresses (including DHCP) as the main units and then
specify the backing hardware as part of the address's configuration.
This would be particularly useful for bridges.
___
On Thu, Nov 21, 2013 at 11:48 AM, David Timothy Strauss
da...@davidstrauss.net wrote:
This would be particularly useful for bridges.
Actually, I meant bonded interfaces, not bridges.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
I often get this when I have a dirty build. Have you tried a fully clean build?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
The service configuration is strange. Normally, this is how they work
with dependencies:
* Type=simple considers the service started immediately on exec()
with no respect for PIDFiles or sd_notify. This can cause dependent
services to come up too early.
* Type=forking considers the service
On Thu, Nov 21, 2013 at 4:33 PM, salil GK gksa...@gmail.com wrote:
3. One more use case I can think of is - if the process fail to send
heartbeat message ( WATCHDOG ) for some time and later it starts sending -
because of some time. So during the time WATCHDOG notification is missing
, 2013 7:50 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 22.11.2013 03:04, schrieb salil GK:
Thanks a lot David
On 22 November 2013 06:44, David Timothy Strauss
da...@davidstrauss.netmailto:
da...@davidstrauss.net wrote:
On Thu, Nov 21, 2013 at 4:57 PM, salil GK gksa
On Fri, Nov 22, 2013 at 10:24 PM, Reindl Harald h.rei...@thelounge.net wrote:
your internal checks are mostly theory because in case of
a bug you have undefined behavior and what you want to achieve
with the watchdog is catch this undefined behavior and restart
the service - in doubt this will
I'm disappointed in your response here. It's not up to your normally
high standards of technical discourse and tact on this mailing list. I
realize I've stepped on some feet, but there's quite a bit more to
this than me getting trigger-happy with a core commit.
On Fri, Nov 22, 2013 at 11:43 PM,
On Sat, Nov 23, 2013 at 7:53 AM, David Timothy Strauss
da...@davidstrauss.net wrote:
My attempts to discuss options and
approaches with you at LinuxCon, on the mailing list, and IRC have
only been marginally productive. Before my commit, we only had a TODO
logged.
Actually, I'm being a bit
On Nov 25, 2013 4:36 AM, Andrey Borzenkov arvidj...@gmail.com wrote:
Interesting case (https://bugzilla.novell.com/show_bug.cgi?id=852021).
Systemd enters emergency due to failed mount. At the same time syslog
socket triggers syslog.service. Due to implicit Requires on
basic.target which
On Mon, Nov 25, 2013 at 5:38 PM, Umut Tezduyar Lindskog
umut.tezdu...@axis.com wrote:
I would think port access protocols would be needed for servers even before
sending a single IP package.
I've never used a server that required 802.1x. I've only encountered
it in places where physical
On Tue, Nov 26, 2013 at 2:28 AM, Umut Tezduyar Lindskog
umut.tezdu...@axis.com wrote:
Any plans to support existing applications that are making use of thread
level resource management? If not, what are we left with then, posix thread
priorities?
Kay is right; there is no direct replacement.
On Tue, Nov 26, 2013 at 2:35 PM, Lennart Poettering
lenn...@poettering.net wrote:
Not following here. What precisely does this fix, can you elaborate?
We currently turn off the poll for the socket fds as soon as we queued
the service socket, so that we don't get woken up anymore. What would
Thanks. Applied.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Wed, Nov 27, 2013 at 2:32 AM, Lennart Poettering
lenn...@poettering.net wrote:
Well, but EPOLLET only works correctly if each time an event is
triggered we dispatch *all* possibly queued events on the fd, until
EAGAIN is read again. But we don't do that, heck, if Listen=no is used
we don''t
On Wed, Nov 27, 2013 at 6:23 AM, Shawn Landden sh...@churchofgit.com wrote:
I was worried that the fact that we never accept() the socket when using
distribute (now I am convinced we shouldn't use it otherwise)
I'm not sure what you mean here. Distribute-style functionality is
absolutely useful
On Wed, Nov 27, 2013 at 7:57 AM, Shawn Landden sh...@churchofgit.com wrote:
Are you sure applications can handle the extra file descriptor of
passing both the sockfd
and the acceptfd in this case? I don't see why they wouldn't just do
the accept() themselves?
Can you explain what you mean
On Wed, Nov 27, 2013 at 12:03 PM, Lennart Poettering
lenn...@poettering.net wrote:
Could you please explain what the usecase here is? Why is this better
than having two socket units with two proxy services?
Right now, it's because separate services cannot exist in the same
network namespace
wrote:
On Wed, 27.11.13 14:09, David Timothy Strauss (da...@davidstrauss.net)
wrote:
If this is about running multiple things in the same Network namespace,
then there are certainly other, better ways to achieve the same. For
example, we could introduce JoinPrivateNetwork=$SERVICE or so
On Fri, Nov 29, 2013 at 1:58 AM, Umut Tezduyar Lindskog
umut.tezdu...@axis.com wrote:
Can someone explain the process level management?
Right now, it's possible to do directly in the cgroups file system,
but we're eventually moving away from anything manipulating that but
systemd. I think that
On Nov 29, 2013 9:52 PM, Cecil Westerhof cecil.wester...@snow.nl wrote:
On 11/29/2013 08:59 AM, David Timothy Strauss wrote:
On Fri, Nov 29, 2013 at 12:53 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Fri, 29.11.13 00:11, Cecil Westerhof (cecil.wester...@snow.nl) wrote:
I have
On Thu, Dec 5, 2013 at 3:53 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
Never use a systemd unit to call modprobe.
And, even if you did, modprobe would be Type=oneshot (maybe also with
RemainAfterExit=true), definitely not Type=simple.
___
On Thu, Dec 5, 2013 at 7:29 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
The above statement not withstanding, but the Type and RemainAfterExit
applies only to ExecStart. This unit calls modprobe in ExecStartPre
which is always expected to do something and return. So this branch of
the thread
How reliable is the unit_id data this falls back to? If it's going
into an underscore-prefixed field in the journal, we need confidence
that it's not forgeable.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
This fails to apply for me. Just to check yours methods and mine, I
tried applying your Ensure unit is journaled for short-lived or
oneshot processes patch and succeeded. Comparing the two, it looks
like the text above the first triple-hyphen got dropped.
On Sun, Dec 8, 2013 at 12:23 PM, Dan McGee d...@archlinux.org wrote:
It is the free(s-buffer); bit that snuck in there from the other patches
I sent this morning. I can rebase this one before those so it applies to the
current tree, my mistake.
Aha! Applied. Thanks.
On Sun, Dec 8, 2013 at 8:25 PM, Shawn Landden shawnland...@gmail.com wrote:
This one doesn't work. I have have a somewhat-working next patch, but
the way epoll_wait works it actually isn't
lazy at all, and would require EPOLLET to even do
one-spawn-per-connection (global connection), but we
We currently use journal2gelf [1], which we also have a rewrite of
that uses the native Python bindings to the journal. We're probably
dumping our rewrite and adding journal integration to Beaver [2].
[1] https://github.com/systemd/journal2gelf
[2] https://github.com/clifton/beaver
After watching the results for an hour or so, this massively improves
the performance of is-enabled and several other systems on our heavily
loaded boxes.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
On Thu, Dec 12, 2013 at 6:23 AM, Lennart Poettering
lenn...@poettering.net wrote:
This isn't right. Units might be symlinked under different names, we
need to support that. For example, all template instances carry a
different name for the symlink then for the source.
Good point, though we
On Wed, Dec 11, 2013 at 8:36 PM, Andrey Borzenkov arvidj...@gmail.com wrote:
This completely changes semantic of what it does. In this case no
symlink is needed in the first place - just
touch .../unit.wants/other.unit would be enough, as long as we assume
units can only be located in standard
On Thu, Dec 12, 2013 at 8:15 AM, Kay Sievers k...@vrfy.org wrote:
We must not give the impression that this is secure in any way, it
is not, and cannot generally be used unless it is secured by other
things. So, no this is not secure at all, just possibly encrypted, but
I doubt that was the
This new patch version fixes instance support by replacing the
instance with nothing, allowing a comparison equivalent to the one we
make against the target of the symlink (which is something like
abc@.service for instances).
___
systemd-devel mailing
Hold on. This breaks is-enabled if you've enabled an instance *and*
that instance has its own override (using def@myinst.service versus
using def@.service).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
On Sat, Dec 14, 2013 at 8:12 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
Are you sure that the sysctl is set early enough, before the listening
socket is created?
Perhaps this is why your suggestion [1] for the journal bootup issue
didn't help.
[1]
If we supported PIDFile= for Type=simple, daemons could drop a PID
file to indicate startup completion without having to be full-on
Type=forking.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
I replied in the thread with a subject line.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
It seems odd to combine Type=oneshot with Accept=false (which is the
default for socket activation). The latter setting causes systemd to
expect a persistent daemon to accept() connections.
___
systemd-devel mailing list
On Sun, Dec 22, 2013 at 11:43 AM, Tony Seo tonys...@gmail.com wrote:
Frankly speaking, I don't understand why service daemon is infinitely
spawned when I set the option Accept= false.
And Why couldn't the client process connect to socket unit that I made by
setting Accept= true.
I think you
On Sun, Dec 29, 2013 at 11:57 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
I have been looking at our bugs [1-10, there are others too] related to
enabling/disabling of units and following of symlinks. Currently this
is an unintuitive mess and some changes will have to be made.
On Sat, Dec 28, 2013 at 10:47 AM, Michael Scherer m...@zarb.org wrote:
So using templated units, we could do for example :
SELinuxContext=staff_u:staff_r:%s_t:s0-s0:c0.c1023
In the spirit of making isolation easy, it would be neat to have a
built-in convention for selinux isolation in systemd
1 - 100 of 169 matches
Mail list logo
