se
the hash of a random secret as a basis for the world-readable machine
ID. However, in existing installations that are upgraded, the old
machine ID should always be preserved.
S
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
_
), but reduces
resource consumption until then. This would be appropriate if the reason
for providing ssh access is as a rarely-used "developer console"
analogous to Android's adb, for instance.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
_
l, copying files in with mtools (or equivalent) when required.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
e-sessions.
Full details: https://lists.debian.org/debian-devel/2015/08/msg00354.html
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
ute in the
dbus.socket and dbus.service files and not make the code changes, but
then setting DBUS_SESSION_BUS_ADDRESS appropriately is your responsibility.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing l
is there any reason for the kernel not to present the
resulting information to user-space via inotify? In other words, is
there a reason why a user-space service is necessary?
(I realise that one possible reason for a user-space service is so that
it can aggregate all the periodic polling, on
worked as intended on the system bus.
Further reading: <https://bugs.freedesktop.org/show_bug.cgi?id=46787>
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
nal D-Bus implementations don't optimize "messages
to yourself" in this way. One of dbus-daemon's roles is to impose a
total ordering on messages - it's the component that makes the arbitrary
decision on how the individual message streams
;t put anything in /srv out-of-the-box, so that the sysadmin can use
it however they want to" (a lot like /opt).
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
ed and/or nss-myhostname to behave similarly?)
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
'user' bus won't replace the session bus yet
This is not the case. If there is a user bus, then the session bus *is*
the user bus.
S
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
t, but I don't maintain coreutils,
and perhaps I'd think differently if I did.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
(the "user bus"
model).
In practice this means you get a `dbus-daemon --session` per user if you
have dbus >= 1.9.14 compiled with the --enable-user-session option, and
systemd, inside the container.
Similarly, kdbus systems (inside or outside a container) always get a
"user bus&quo
On 07/05/15 10:30, Martin Vogt wrote:
> I try to give any user rw permissions on /dev/nvidia*.
>
> Usually this is done by adding the user to group "video", but
> here the group is configured on NIS and I cannot change it.
On a modern Linux system you should instead be able to tag those devices
a
of worrying about how efficiently-implemented those MIME modules
were, I'd be asking you why (and whether) you are sending enough patches
that it makes any practical difference, and if you are, whether pushing
them to a git repository might make more sense :-)
--
designed to be used.
See also <http://permalink.gmane.org/gmane.comp.freedesktop.dbus/13663>.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
(all taken from
getsockopt results), and a "log info" string (derived from /proc/$pid).
The "log info" is mentioned in the syslog message when something is
denied, but is not used for authentication, and is not made available to
dbus-daemon's clients such
ibdir to their preferred paths, whether that means
/usr/i686-linux-gnu/lib or /usr/lib/i386-linux-gnu or /usr/lib64. It
seems better for third-party software to be predictable about its
installation paths, rather than for it to "do what I mean" and alter its
defaults depending whether it
ation
... all of which can be done right now, if you really need to, without
any changes to either systemd or dbus.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
before /usr and /var are unmounted.
I'm happy to modify dbus.service if that's (part or all of) the
solution, but before I can do that we need to come up with a solution
that doesn't cause new dependency cycles.
S
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/&g
On 24/03/15 14:40, Stef Walter wrote:
> On 24.03.2015 15:22, Tom Gundersen wrote:
>> It all comes down to what you intend the fields to mean. Now we mean
>> the field to mean "the real localtime of the server (as seen from the
>> client)", whereas you want it to mean "the localtime the server think
th having.
> and yet
> other projects (dconf) don't do API versioning with the .pc filename.
If dconf never breaks API, no problem; if it does, it will hopefully
start including an API version in the .pc filename at that point.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
r setting will override the earlier setting.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
ian/tmp
tar -C $(pwd)/debian/tmp -czf data.tar.gz .
# now data.tar.gz contains e.g. ./usr/bin/foo, ./usr/include/foo.h,
# ./usr/lib/i386-linux-gnu/libfoo.so*
and most other packaging systems are similar.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
On 10/03/15 16:01, Lennart Poettering wrote:
> Yes, dbus is currently not compatible with stateless bootups. PAM is
> neither. For PAM we ship a tmpfiles snippet to work around this, for
> dbus we don't though, since kdbus kinda makes the problem go away...
In the meantime, you might be interested
On 09/03/15 12:32, Simon McVittie wrote:
> I'm developing a patch for udisks to fix its interaction with systemd
> user-sessions (, and I would like to check that the behaviour I propose
> is consistent with udisks' and systemd's security models.
Forgot to men
velopers: is this consistent with how you think
situations like this should work in the kdbus-based future?
(This sort of thing is one of the reasons I was keen to make D-Bus
support user sessions without requiring kdbus - if we can get this sort
of thing fixed now, in parallel with the kdbus deve
of a security label looks like
{}, not { "LinuxSecurityLabel": [] } or
{ "LinuxSecurityLabel": [ '\0' ] }.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On 19/02/15 21:26, Djalal Harouni wrote:
On Thu, Feb 19, 2015 at 05:44:34PM +0100, Djalal Harouni wrote:
On Thu, Feb 19, 2015 at 01:05:22PM +, Simon McVittie wrote:
On 19/02/15 12:43, Lukasz Skalski wrote:
r = get_creds_by_message(a, m, SD_BUS_CREDS_PID|SD_BUS_CREDS_EUID, &creds,
&a
}", "ProcessID", "u",
(uint32_t) creds->pid);
If the pid is out of range for uint32 it should be omitted from the map
(although that can't actually happen on current Linux). Same for the uid.
--
Simon McVittie
Collabora Ltd. <http://www.collabo
, SELinux, etc.) and "confine" your users,
you might be able to achieve what you think you have already achieved.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.free
nstead in Debian and its derivatives, including
Ubuntu. The differences are because, historically, this sort of plumbing
was something that every distribution had to invent for itself.
S
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
On 30/01/15 08:30, Simon McVittie wrote:
So that the people who are happy with the complexities of the current
arrangement can remain happy, here is how I intend it to work:
* ./configure --disable-user-bus: you get a login-session-centric world
* ./configure --enable-user-bus: you get a user
ed system, you probably want the "user session" enhancement
for dbus, which I'm currently upstreaming into dbus 1.9.x.
Regards,
S
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
syste
is mounted for some things, and never check it
again...
I think "in general this should work, but your configuration is not a
supported one" is an acceptable response to that, tbh. If a sysadmin
wants this badly enough, they can put a hook in their initramfs to mount
/usr/
On 03/02/15 10:16, Stef Bon wrote:
> I've never understood why the session bus is started through dbus-launch.
If we move from a per-login-session to a per-user-session bus, then it
won't be; dbus-launch will become solely for the people who run twm
under xdm or something, but who still want to ru
on too (so that
D-Bus-activated, non-systemd services will get the variables), and there
are a bunch of other variables set in /etc/X11/Xsession.d or equivalent
that should also be uploaded if present.
--
Simon McVittie
Collabora Ltd. <http:/
part is getting environment variables pushed around, for
which I don't have a complete patch yet (but I'm going to work on that
within the next couple of weeks).
S
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
_
On 02/02/15 10:22, Dimitri John Ledkov wrote:
> I would like to experiment with a user-bus, potentially in a transient
> manner to have 3 buses: system, user, session busses.
I still think it's a bad idea to have both a user bus and a session bus.
Having things "on the wrong bus" is definitely an
On 30/01/15 09:30, Simon McVittie wrote:
> user-session
>
>
> I don't think there is a standard term for this so I'm making one up.
Notes from the hackfest: A few people called these "super-sessions" when
we discussed them. I preferred user-se
On 30/01/15 22:53, Elias Probst wrote:
> IMHO, env variables are something we should get rid of in the long term.
> It might be fine for now to provide some legacy-compatibility mechanisms
> (like your not-yet-written tool), but to me environment variables are
> something straight out of the dark a
[For those who are there, I'll be at the system hackfest today and at
FOSDEM this weekend, so if you are interested in these topics, please
talk to me about them; I'll try to summarize discussion to these lists.
For those not there, I'll try to keep up with responses via email and
raise any interes
On 24/01/15 10:09, Topi Miettinen wrote:
> For example, smartd only needs access to /dev/sd*.
Let me spell that differently: smartd "only" needs the ability to make
arbitrary filesystem changes, defeating any possible configurable
security mechanism.
If you give it access to /dev/sd* but not to o
On 23/01/15 17:52, Lennart Poettering wrote:
> On Fri, 23.01.15 12:27, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
>> El 23/01/15 a las 10:31, Lennart Poettering escribió:
>>> The rc-local generator only exists to add compat support for those
>>> systems where it never was a sysvinit scrip
On 20/01/15 20:33, Martin Pitt wrote:
> Dimitri John Ledkov [2015-01-20 18:23 +]:
>> With parallel test harness in automake (everyone should have it by
>> now)
>
> Yay, thanks for pointing this out! That makes the whole thing indeed
> much friendlier.
systemd currently has
AM_INIT_AUTOMAKE([
On 15/01/15 09:28, Colin Guthrie wrote:
> Although if the script is in bash I'd use "if [ -d ..." rather than "if
> test -d ..." as (and bash experts (Harald?) can correct me here if I'm
> wrong) I believe [ is a bash built in (even if it is a binary in
> /usr/bin/), whereas it would have to fork
On 08/01/15 17:42, Dimitri John Ledkov wrote:
> On 8 January 2015 at 17:24, Simon McVittie
> wrote:
>> I personally think having only the user bus (and having
>> (G_|DBUS_)BUS_TYPE_SESSION connect to it) is the best long-term setup,
>> because it's easy to understa
On 08/01/15 17:04, Colin Guthrie wrote:
> Although when I discussed this on the ML
> before, one case which a PAM solution wouldn't address is people running
> "startx" after logging into a tty session
I personally am very tempted to say that startx users get to keep both
pieces, and that the *dm
On 08/01/15 17:24, Simon McVittie wrote:
> This is a conversation about the distinction between a per-(uid,machine)
> bus (the "user bus") and a per-login-session bus (the "session bus").
> We've had this discussion several times in the past
Some further reading
On 08/01/15 16:03, Dimitri John Ledkov wrote:
> There is upstart --user spawned per session, and everything is under
> it. The sessions' logind cgroups are parent of all processes within a
> session, and there are sub cgroups as needed for contained
> jobs/processes. Thus for three graphical sessio
On 08/01/15 14:36, Colin Guthrie wrote:
> Lennart Poettering wrote on 08/01/15 13:19:
>> Yes, the idea is that these services become singleton services of the
>> user, and the sessions ultimately only retain a "stub" process
>
> But dbus-daemon itself might be excluded from that no? I mean the mod
Adding D-Bus mailing list to Cc; questions about the user bus are
significant for D-Bus as well as for systemd --user, and modifications
of dbus-launch doubly so.
On 08/01/15 11:55, Colin Guthrie wrote:
> I've got a modified dbus-launch that can be slotted in nicely
I'm happy for dbus to get bett
On 22/12/14 14:33, Lennart Poettering wrote:
> I thought Debian would nowadays mount /usr from the initrd too?
We now do that in unstable, but unfortunately this change wasn't well
coordinated and caused several serious regressions, so it's unlikely to
migrate into Debian 8. (A separate /usr on md
On 18/12/14 14:10, Dale R. Worley wrote:
> Simon McVittie writes:
>> On 18/12/14 08:05, Andrei Borzenkov wrote:
>>> Any initscript that is using "su -" would [cause badness]
>>
>> Don't do that then? Init scripts are fairly clearly not login sessions
On 18/12/14 08:05, Andrei Borzenkov wrote:
> Any initscript that is using "su -" would [cause badness]
Don't do that then? Init scripts are fairly clearly not login sessions.
Which init scripts do that?
In Debian, our init scripts would typically use "start-stop-daemon
--chuid whateveruser --sta
On 04/12/14 08:56, arnaud gaboury wrote:
> -$DBUS_SESSION_BUS_ADDRESS
> For reasons I ignore (far from being a dbus expert), the
> $DBUS_SESSION_BUS_ADDRESS as returned by the
> $systemctl --user show-environment did not work for mate-settings-daemon.
...
> $systemctl --user show-environment return
On 25/11/14 23:46, David Herrmann wrote:
> In particular, if gdbus runs AddMatch(), it assumes the match takes
> effect immediately. If it sends a method call to another service after
> installing the match, and this triggers a signal, gdbus assumes the
> AddMatch() call to have succeeded (without
On 14/11/14 16:46, Stef Walter wrote:
> On 14.11.2014 16:39, Lennart Poettering wrote:
>> The services like hostnamed explicitly provide stable object
>> paths and suchlike so that clients can completely ignore when
>> the services go away and come back...
>
> Most DBus services are not like that,
On 09/11/14 02:08, Casey Schaufler wrote:
> Thus, dbus is a fine example where SMACK64EXEC is a bad idea. Because you
> want a system bus and a user bus with different attributes you want it to get
> the Smack label at launch time, just like you do for UID and capability sets.
I think there's a mu
On 06/11/14 14:16, Zbigniew Jędrzejewski-Szmek wrote:
> What matters is how it is all arranged:
>
> - if there's a job that does stuff, and then calls reboot or shutdown
> - a hook into the shutdown or reboot target does some work
unattended-upgrades is currently the latter: the user shuts down (
On 28/10/14 16:34, Colin Guthrie wrote:
> It seems we have different permissions for /etc/{g}shadow than fedora.
> We don't package it as ,root,root but rather 0440,root,shadow.
Who is "we"? Mageia? FYI, Debian uses 0640 root:shadow for the same files.
> We can then run some tools that need d
On 28/10/14 10:06, Mihamina Rakotomandimby wrote:
> what to do if
> there is the need to package a daemon and there is only a SysV init
> script available
LSB init scripts should continue to work fine. Make sure they have LSB
pseudo-headers (Required-Start etc.) for their dependencies.
> if runni
On 20/10/14 08:19, Chaiken, Alison wrote:
> ../systemd/src/shared/util.h:51:4: error: #error Unknown pid_t size
> # error Unknown pid_t size
> ^
> In file included from ../systemd/src/shared/util.h:87:0,
> from ../systemd/src/shared/log.c:33:
> ../systemd/src/shared/missing.h
On 23/10/14 12:21, Lennart Poettering wrote:
> The behaviour should really be to:
>
> 1. take the paths from configure switches
> 2. if they are not specified, try to get them from pkg-config
> 3. if the relevant pkg-config files are not installed, generate an error and
> refuse build
Actually..
On 22/10/14 12:37, Lennart Poettering wrote:
> When used with kdbus we actually do check for that client-side
> capability. THis is not available on dbus1 however, since we cannot
> determine the capability racefreely and thus safely
... because the kernel doesn't give us that ability on Unix sock
On 21/10/14 20:25, Lennart Poettering wrote:
> Ah, well, at least they should make the lib64 thing arch dependent.
Multiarch means that whichever architecture systemd happens to have been
compiled for, /lib64 might exist. If it does, it's a system library
directory.
(Consider an i386 or armhf sys
On 21/10/14 20:30, Lennart Poettering wrote:
> But in cases like the iptables tool (which
> is written in a style that kinda requires the usage of shell scripts
> to invoke it, since it is more a programming language and is seldom
> called just once at boot)
If your ruleset is static (e.g. does no
On 21/10/14 19:18, Lennart Poettering wrote:
> Well, on some distros lib64 is a symlink on others it isn't. Doesn't
> Debian have /lib/ or so with /lib64 just a symlink to the right
> subdir?
My Debian laptop has /lib64 as a real directory, containing a
ld-linux-x86-64.so.2 symlink into /lib/.
I
On 21/10/14 13:03, Christian Seiler wrote:
> That is definitely a good point. Also note that /lib32 is not included
> in the patch...
lib64 is part of the Linux/x86_64 platform ABI (the exact path
/lib64/ld-linux-x86-64.so.2 is hard-coded into every Linux/x86_64
executable) so it cannot be conside
On 21/10/14 09:37, Martin Steigerwald wrote:
> In my long years of using Debian and also doing some packages for it in the
> last years I never saw that any introduced changed caused a serious "we may
> need to fork" like announcement
I've seen several instances of Debian people *actually* forki
On 13/10/14 14:38, Dale R. Worley wrote:
> My general understanding is that the traditional behavior when "you
> need an editor but the user hasn't specified one" is to use "vi", and
> so people who don't want "vi" *always* set $VISUAL in their
> environment.
The Right Thing™ is distro-specific. D
On 25/09/14 22:12, Gustavo Sverzut Barbieri wrote:
> move each user/group creation to a file that represents its own split
> package, so it's possible to ship them in separate.
Even if you split out bits of systemd functionality like networkd,
timesyncd, kdbus into separate binary packages, what h
On 02/10/14 10:09, Miroslav Suchy wrote:
> If I want to become specific user inside of that container, I have to do
> something like:
>
> /usr/bin/systemd-nspawn -D foo /bin/su -l mockbuild -c 'rpmbuild -root
> \'/build\' ...'
>
> which quickly go into escape-hell.
If you put a better privilege-
D-Bus' type hierarchy as described in the spec is:
\- basic
\- fixed type (u, i, etc.)
\- string-like type (s, o, g)
\- container
Someone seems to have referred to basic types as "simple types" at
some point, but that term isn't defined in the D-Bus Specification,
and seems redundant.
So f
---
src/libsystemd/sd-bus/PORTING-DBUS1 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd/sd-bus/PORTING-DBUS1
b/src/libsystemd/sd-bus/PORTING-DBUS1
index 958e7b6..81e9413 100644
--- a/src/libsystemd/sd-bus/PORTING-DBUS1
+++ b/src/libsystemd/sd-bus/PORTING-DBUS1
@
(Cc'd to the systemd mailing list because sd-bus is the reference
implementation of the user-space side of kdbus, but please join the dbus
list and follow-up there if you are interested in D-Bus.)
I've recently been looking at kdbus as a transport for D-Bus messages,
and how compatible or otherwis
On 22/09/14 10:23, Reindl Harald wrote:
> honestly the messages about "reaching target" are nonsense without
> a prefix pointing out that it is about a *user session* because it
> looks like a bootlog every minute
You can tell this is not the system instance of systemd (init) because
its process
On 22/09/14 10:27, Jan Synacek wrote:
> If /etc/machine-id is missing on the system, the first open() call
> should probably handle that case. That's actually not true (at least on
> my system), because the underlying filesystem is read-only at that
> time.
*What* is not true on your system?
Are
On 19/09/14 09:05, David Herrmann wrote:
>> -fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
>> +r = fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
>> +if (r < 0) {
>> +log_error("Failed to set pipe buffer size: %m");
>> +return -errno;
>> +
On 12/09/14 09:57, lux-integ wrote:
> The question is; is there a way of conditionally procesing lines in systemd
> service files such as the following
>
> ExecStart=/path/to/executible1
> ExecStart=/path/to/executible2
> some condition satisfied ( for example ConditionFileNotEmpty=SomeFile
On 10/09/14 16:10, Simon McVittie wrote:
> If you want to escalate privileges in a controlled way, you need a
> controlled privilege-escalation tool. PolicyKit is one such tool;
> systemctl is another; a setuid binary written by you [...]
> is another possibility.
Sorry, that should r
On 10/09/14 15:03, Michal Witanowski wrote:
> I was wondering if there is a possibility to call “systemctl poweroff”
> as non-root user [without PolicyKit or sudo]
...
> Theoretically there is no other way, am I right?
If you want to escalate privileges in a controlled way, you need a
controlled p
On 09/09/14 16:01, Colin Guthrie wrote:
> On Mageia and Fedora (at least originally, not sure if it's changed
> recently), the modules are in:
> /lib/modules//
> tree.
...
> The actual modules are stored in a:
> /lib/modules//kernel/
> subfolder.
It's the same on Debian and its derivatives, FWIW.
On 05/09/14 18:22, Jakub Klinkovský wrote:
> What is the reason behind logging unit's description? Consider the
> following journal message (from `journalctl -b`):
>
> systemd[1]: Starting A secure, fast, compliant and very flexible
> web-server...
As a data point, Debian's init scripts have trad
On 04/09/14 23:32, Dale R. Worley wrote:
> I admit that I haven't studied systemd enough to understand the
> significance of WantedBy. My understanding is that systemd performs a
> series of units, with dependencies showing which units must finish
> before other units start.
Sort of. It has a goa
On 21/08/14 19:12, Ivan Shapovalov wrote:
> Actually, I don't pretty understand the reasoning behind skipping the default
> dependencies on /usr mount
(Some of) the default dependencies require that /usr is mounted, so
mounting /usr cannot depend on them, to avoid a cycle.
(Or to put it the way r
On 20/08/14 16:28, Tom Gundersen wrote:
> +int attach_sd_event_to_g_main_loop(GMainLoop *loop, sd_event *event) {
(I know this is only a proof of concept but)
I think the construct you're looking for is a GMainContext, not a GMainLoop:
https://tecnocode.co.uk/2014/03/27/what-is-gmaincontext/
On 14/08/14 16:29, Lennart Poettering wrote:
> On Thu, 14.08.14 17:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
>> systemd: "Copy rules generated while the root was ro"
>
> Hmm, wut? What's that supposed to be?
I think it's glue for running udev when pid 1 != systemd and there wa
On 14/08/14 16:04, Zbigniew Jędrzejewski-Szmek wrote:
> Actually, most of them probably don't need to run at all:
Many of the ones you quoted indeed don't make sense with systemd and are
either explicitly masked by a symlink to /dev/null, or have a
corresponding native systemd service that overrid
On 14/08/14 14:31, Simon McVittie wrote:
> Default-Start: S means basic-target.target depends on
> mintsystem.service, which depends on dbus.service, which does not have
> DefaultDependencies=no, so it implicitly depends on sysinit.target, so
> you lose.
Sorry, that's not qui
On 14/08/14 13:27, Vlad Orlov wrote:
> ### BEGIN INIT INFO
> # Provides: mintsystem
> # Required-Start:$local_fs $syslog $remote_fs dbus
> # Required-Stop: $local_fs $syslog $remote_fs
> # Default-Start: S
> # Default-Stop:
> ### END INIT INFO
As Lennart said, this is Debian
device.bus = "usb"
> device.vendor.id = "21b4"
> device.vendor.name = "Intel Corp."
> device.product.id = "0081"
> device.product.name = "Integrated Rate Matching Hub"
> device.seri
On 07/08/14 15:21, Dimitri John Ledkov wrote:
> tmpfiles.d files do not depend on /usr present, and in
> --enable-split-usr configuration there may be system units
> (e.g. shipped in /lib) that rely on tmpfiles.d to be configured
> e.g. tmpfiles.d/systemd.conf itself. Hence tmpfiles.d should use
>
On 07/08/14 12:23, Peter Mattern wrote:
> If one of these options gets stated more than once the different
> instances seem to be linked by a logical AND, too.
Yes. This is documented in systemd.unit(5), which also describes how a
drop-in can reset the list of conditions and start from a clean sla
On 01/08/14 15:53, Simon McVittie wrote:
> Best-practice in Autotools projects seems to be to include config.h at
> the very top of every .c file, whether it is currently needed or not.
Sorry, I'd missed that systemd uses "cc -include
$(top_builddir)/config.h ...", which is e
nclude config.h at
the very top of every .c file, whether it is currently needed or not.
Thanks for reminding me to upstream this!
S
>From 669af691816ee56dbf097ae7f0e4f207af5929f5 Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Tue, 29 Jul 2014 14:40:18 +0100
Subject: [PATCH] util.h: incl
On 01/08/14 12:20, Kay Sievers wrote:
> On Fri, Aug 1, 2014 at 1:13 PM, Simon McVittie
> wrote:
>> are you saying that under kdbus, each connection to the bus [...] is only
>> allowed to own one well-known name (thing like org.freedesktop.systemd1)?
>
> No, it is no
On 31/07/14 21:38, Kay Sievers wrote:
> We have one .busname file per name and it will get really complicated
> to start stop a busname, when it has multiple names per connection. We
> should really avoid that and require one connection per name and allow
> only name.
I might be misunderstanding w
On 23/07/14 19:50, Zbigniew Jędrzejewski-Szmek wrote:
>> As a side effect this would actually even allow us to be closer to
>> FEdora's current bheaviour, since it reserves UIDs < 200 for static
>> assignment, which we could then easily exclude from theis logic, too.
> In practice this might not be
On 23/07/14 18:31, Lennart Poettering wrote:
> As a side effect this would actually even allow us to be closer to
> FEdora's current bheaviour, since it reserves UIDs < 200 for static
> assignment, which we could then easily exclude from theis logic, too.
Debian's uid/gid ranges for comparison, if
101 - 200 of 244 matches
Mail list logo
