Dominik George:
There is no GNOME without systemd. This is not specific to Debian.
Florian Lohoff:
Because i - aehm - cant set an icon for my system via hostnamed or something?
As you've spotted, what M. George wrote is ambiguous and unspecific and liable
to be further distorted. This may
Ansgar Burchardt:
Isn't that just a hack to work around deficits in sysvinit?
Matthias Urlichs:
The whole of sys5rc can be described as a hack to work around the
fact that sys5init does not have a whole lot of features … if
somebody had evolved it with an inittab.d directory and a more
The Wanderer:
This is the problem. The init system should not be providing
features which other software might, post-boot and pre-shutdown,
want to make use of. (AFAIK sysvinit never did, and most - possibly
all? - of the other init-system candidates don't either.) Such
features should be
The Wanderer:
At a glance at the sysvinit source, it doesn't look to me like
/sbin/init itself does service management, in the starting, stopping
and monitoring services form; at most, it seems to handle some subset
of the monitoring part, in the form of noticing when something has
died
The Wanderer:
That isn't all you gain by it; you also gain the benefit of being
able to use these features no matter which init system you're
running. Which in turn helps avoid lock-in, and enable easier testing
of (or migration to) alternatives, and prevent user surprise, and so
forth.
Vincent Bernat:
All of them are relying on the fact that the monitored process won't
fork.
They are therefore not able to handle readiness and dependencies.
Also untrue. Handling dependencies has nothing to do with forking, and
it's an error to think that anyone handles readiness.
Russ Allbery:
I think it's worth considering whether we should just dump the
Lintian checks for arch-independent files in /usr/lib, and make a
corresponding change to Policy that says that packages are free to
put arch-independent files there.
It would as a side-effect make you better
Sandro Tosi:
what is the recommended way to identify sysvinit? from the info
provided above one requires to check a dir existence and the
checking a command and then execute it to parse its output. it seems
a bit fragile, and maybe only upstart check really the running
processes
There
Gerrit Pape:
Hi, I'd very appreciate help on tracking down the failures and do
the appropriate analysis, reportbug, patch drafting, and the like, as
my time for this is quite limited.
I took a handful of packages as a sample, and the problem could be
traced to the same bug, over and over,
Vincent Bernat:
There is chpst for this kind of task. Unfortunately, being part of
runit, it may not be suitable for a dependency.
* http://superuser.com/a/72
Actually, there are chpst, s6-setuidgid, daemontools-encore setuidgid,
daemontools setuidgid, freedt setuidgid, nosh setuidgid,
Russ Allbery:
Yeah, this seems like the right solution to me too. Drop a
configuration fragment in /etc/systemd that overrides the user and
group and then don't touch it again.
I refer you to footnote #85 in that patched document that I just sent to
you. (-:
--
To UNSUBSCRIBE, email
Eric Valette:
There has been a good and valuable effort trying to split original
upstream packages provided init system scripts by debian developers
into /etc/default/X and /etc/init.d/X file and storing most commonly
changed sysv init options in the default file part (including start
or
Eric Valette:
I just mentioned that naively combining User=$TOTO or ${TOTO} TOTO
being defined in an default/package file parsed by EnvironmentFile=
does not seem to work as documented in man pages (seen the very same
question being asked on various distro mailing list without
definitive
Simon McVittie:
If sshd uses (or can be made to use) IP_FREEBIND to remove the
potential dependency on bringing up network interfaces, then
/lib/systemd/system/ssh.service could have DefaultDependencies=no,
RequiresMountsFor=/usr /lib /etc, and drop its dependency on
network.target.
Octavio Alvarez:
Question: is it safe to say that systemd doesn't yet support the
full /etc/fstab specification from util-linux [1]?
Yes; it's safe. It's also wrong. But it's quite safe. (-:
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe.
Vincent Danjean:
I found another issue with systemd and noauto.
[...]
Do you think I should do a bugreport ?
Not until you've constructed a far better description, because your
current description is this:
1. I have several lines in /etc/fstab that all have noauto.
2. systemd is obeying
Dimitri John Ledkov: > Most filesystems support destructive operations,
with a goal to recover data via some-sort check/repair functionality
e.g. btrfs check/rescue, xfs_repair etc. > Some filesystems also require
periodic maintenance calls, e.g. something like the `harmless' fsck on
each
Michael Biebl:
I wonder if nosh could be an option for non-linux. According to its
website it supports native systemd service files. I have to admit
though, I never looked at nosh myself, so I have no idea how far that
"systemd support" goes.
This caught my eye, so I thought that I'd
Jonathan de Boyne Pollard:
It didn't start because the service unit was wrong.
A quick check of the log revealed that the service was trying to
create a local-domain socket at |/run/lirc/lircd| . But there was no
|/run/lirc/| directory on my system to contain that. Your systemd
units
Adam Borowski:
Hmm... 1 out of 11¹ implementing italics plus one doing some other
thing doesn't strike me as a "wide" range.
I didn't bother to test terminals I don't have installed at the moment
but the above sample shouldn't be much off.
Aside from the tests in your list that you somehow
Samuel Thibault:
How much memory did the box have?
2GiB. So it's not that. (-:
Samuel Thibault:
Memory management is being worked on and there have been various
fixes, yes.
I'll give it another go when I get the time, then.
Richard Braun:
Note that installing a mail transfer agent on an isolated system
actually makes sense. It's one way between local users to communicate,
and it's used by apt to notify you about some important changes when
you install/upgrade packages. Besides, it's a pure Debian thing,
Gerrit Pape:
To me too this readiness IPC ideas and implementations look
over-engineered.
A good convention for service programs would be to functionally test
for services it needs very early on startup, and fail if dependencies
are not available. The service supervisor (any modern init
Dmitry Bogatov:
Thanks history, we have pid files, not `libpid' to talk to `pidd'.
Jonathan de Boyne Pollard:
You have forgotten about the existence of Debian Hurd. (-:
* https://jdebp.eu./FGA/hurd-daemons.html#proc
Samuel Thibault:
The Hurd precisely tries to expose things as files
Russ Allbery:
But change sucks, and part of what accreted was decades of subtle
workarounds to poorly-documented issues for which we have minimal
institutional memory.
Like fulfilling the 1970s Unix promise of italics in manual pages, on
the wide range of terminals that /can/ /do/
Simon McVittie:
This can already work. If you put XDG_RUNTIME_DIR in user programs'
environment, and arrange for your favourite service manager to make a
dbus-daemon (or something else that speaks the same protocol) listen
on $XDG_RUNTIME_DIR/bus before any user process would try to connect
Adam D. Barratt:
> I'm sure I'm not the only one irritated by this,
Then you should be looking at the Debian software that drives
https://lists.debian.org/ , which seriously mucks up subject processing,
and not at us poor users who are long-suffering under it. Debian
software gets
XDG Base Directory Specification:
If $XDG_RUNTIME_DIR is not set applications should fall back to a
replacement directory with similar capabilities and print a warning
message
Simon McVittie:
Are you saying that if XDG_RUNTIME_DIR is not set, D-Bus client
libraries should choose some
Gerrit Pape:
My suggestion was and still is to separate services from programs on
the package level, [...]
I vaguely remember from the systemd packaging Hoo-Hah someone else
advocating this idea. I don't recall who it was off the top of my head.
Gerrit Pape:
I was not successful to
Russ Allbery:
I think that... says the same thing I said?
Read again, and let your eye dwell upon Laurent Bercot's name this
time. (-: The world has changed since 2014 and the Debian systemd
packaging Hoo-Hah, and I've been keeping tabs.
*
Dmitry Bogatov:
Thanks history, we have pid files, not `libpid' to talk to `pidd'.
You have forgotten about the existence of Debian Hurd. (-:
* https://jdebp.eu./FGA/hurd-daemons.html#proc
Robert Edmonds:
The relevant text from the policy manual, §9.11: [...]
The Debian Policy Manual never got updated in the wake of the Debian
systemd Hoo-Hah. It remains written from the viewpoint that System 5
init and rc are the defaults, and that upstart is a novelty addendum.
Several
Robert Edmonds:
The relevant text from the policy manual, §9.11: [...]
Ansgar Burchardt:
Was that changed since the default init system was changed? It pretty
much still reads like Policy still assumes that sysvinit is the
default init system. It also still mentions upstart in 9.11.1;
Sam Hartman:
Hi. As part of reviewing an issue for the technical committee, I just
read policy section 9.3 in its entirety.
Section 9.3.1 really seems to be showing its age. That section covers
runlevels and the sequencing numbers after S and K in rc.d links
without reference to
Bart Schouten:
Personally I do not run a non-SystemD system, [...]
Then please spell the name correctly. It is no more "SystemD" than
inetd is "INetD" or rsyslogd is "RSysLogD". It is "systemd".
You'll be doing yourself a favour. For better or for worse, the
mis-spelling has become a
Simon McVittie:
Once per thread about systemd, I point out that dbus-daemon links to
both libapparmor and libselinux - which results in at least one
useless library for literally everyone with dbus installed, since
"major" LSMs don't stack, so nobody can possibly be using both
AppArmor and
Arturo Borrero González:
* systemd is starting to drop support for some sysvinit mechanisms
[https://sources.debian.net/src/systemd/231-4/debian/systemd.NEWS/]
Don't employ such thinking. It is a mistake; in two ways no less.
Close on the heels of the Debian Technical Committee's decision
The Wanderer:
IMO this level of integration between things which are not mutually
interdependent is a minor bug in itself, but none of the maintainers
are going to agree with me on that.
Actually, they might. But this is a facet of the Debian build system in
general, and not specific to
Simon McVittie:
You mean like libsystemd, which looks in /run to see whether systemd
is in use, talks to it if it is, and returns some suitable error code
(-ENOSYS?) if it isn't? :-)
Here's interesting for you. (-:
Here's libsystemd and Arturo Borrero Gonzalez's code that calls it.
Russ Allbery:
All other init systems except upstart [...]
Psst!
* https://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#Choice
In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon
McVittie:
Please contact the D-Bus upstream mailing list if you are interested
in implementing a user bus without systemd. You will need something
resembling pam_xdg_support (which is what Ubuntu used before they
switched
Samuel Thibault:
> Memory management is being worked on and there have been
> various fixes, yes.
Jonathan de Boyne Pollard:
> I'll give it another go when I get the time, then.
As promised, I have given it another go, with your latest DVD image dated
January 2017. The
Robert Edmonds:
The only package in the archive that I know of that has a seriously
deficient set of root hints is djbdns; it has 11/13 of the current set
of IPv4 root server addresses, and 0/13 IPv6 root server addresses.
(However, I don't believe the 'djbdns' binary package ships with the
rhkramer:
Intentionally cross posted. Aside: For those on the debian-user lists,
the thread came from the debian-backports list, but my frustration
should probably be expressed more to the debian-user list (or
debian-developer list, assuming there is such a list (to which I am
not
44 matches
Mail list logo
