On 30.4.2022 05:08, Andrei Borzenkov wrote:
On 28.04.2022 10:54, Lennart Poettering wrote:
* systemd-boot is an additional bootloader, rather than replacing
an existing one, thus increasing the attack surface.
Hmm, what? "additional bootloader"? Are they suggesting you use grub
to start sd-b
On 30.4.2022 07:53, Jóhann B. Guðmundsson wrote:
On 30.4.2022 05:08, Andrei Borzenkov wrote:
On 28.04.2022 10:54, Lennart Poettering wrote:
* systemd-boot is an additional bootloader, rather than replacing
an existing one, thus increasing the attack surface.
Hmm, what? "addit
On 1/14/19 3:48 PM, Lennart Poettering wrote:
On Mo, 14.01.19 08:43, Dave Reisner (d...@falconindy.com) wrote:
On Mon, Jan 14, 2019 at 10:59:06AM +0100, Jan Synacek wrote:
Hi,
since v240 didn't go too well, I would like to suggest that the next one
(preferably two) release(s) are bugfix only
On 1/15/19 6:49 PM, Lennart Poettering wrote:
On Di, 15.01.19 11:23, Eric DeVolder (eric.devol...@oracle.com) wrote:
Systemd-devel,
Below is a write-up I've done to explain a new service for archiving pstore
contents. I've attached the pstore.service files
(/lib/systemd/system/pstore.service
On 1/15/19 8:58 PM, Michael Biebl wrote:
What's going on is just too stupid/crazy.
This begs the question what you consider is too stupid/crazy?
Is it something here upstream ( which could be improved upon )?
Or is it something ( political? ) downstream in Debian?
Or both?
JBG
__
Greetings
Not sure if this is the right place for mkosi and casync discussions
probably better create seperated mailing list for both of these
components ( lates issue against mkosi seems to be a user problem not a
bug ).
Anyway we have had two bugs reported against mkosi today one of which
On 1/31/19 4:34 PM, Paul Menzel wrote:
numbered differently
You can try to do this via tty symlinked udev rule, something along the
lines of
# /etc/udev/rules.d/99-consistent-serial.rules
# Generic sample ( replace $FOO with something relevant to your
environment )
SUBSYSTEM=="tty", KE
On 2/4/19 7:22 PM, Petr wrote:
Hello,
I have custom linux on embedded machine generated with Buildroot
using emmc drive which contains root filesystem on /dev/mmcblk0p2
and application data on /dev/mmcblk0p4. The root fileystem is mounted
pretty quickly, but the application data are mount
Hi
On 6/13/19 2:44 PM, Bruce A. Johnson wrote:
We recently decided to add a Wi-Fi interface as an
option to the Ethernet interface, and it was easy enough to set up
wpa_supplicant to handle connecting the lower layer, after which
systemd-networkd uses the .network file to bring up IP, either usi
Hi
On 6/17/19 2:28 PM, Marcel Holtmann wrote:
And frankly IP configuration needs to move into the network technology daemons
like iwd for example.
What's the argument here for that reasoning as in why not consolidate
all network configuration ( ethernet/wifi/vrrp/vpn's etc.. ) to a single
p
Hi Marcel
On 6/19/19 5:14 AM, Marcel Holtmann wrote:
Hi Johann,
And frankly IP configuration needs to move into the network technology daemons
like iwd for example.
What's the argument here for that reasoning as in why not consolidate all
network configuration ( ethernet/wifi/vrrp/vpn's etc
You will always risk ending up with a race condition if you place your
type units outside the official directories.
/etc/systemd/system/* ( Administrators )
/run/systemd/system/* ( Temporary )
/usr/lib/systemd/system/* ( Vendors )
Arguably the support running/loading type unit files outside
On 05/25/2016 03:22 PM, Lennart Poettering wrote:
On Wed, 25.05.16 10:05, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
You will always risk ending up with a race condition if you place your type
units outside the official directories.
/etc/systemd/system/* ( Administrators )
/run
On 05/26/2016 06:52 AM, Rashmi Ranjan Mohanty wrote:
Just out of curiosity... If /usr itself is there on a separate partition, can
this issue happen
then or systemd can handle that scenario ?
Systemd can cope with /usr being on separated partition however other
core/baseOS components might n
On 05/26/2016 09:36 AM, Lennart Poettering wrote:
/usr is for the OS vendor really.
Given that it's generally expected and wanted that application
developers follow the os vendors packaging guideline and rules as
possible in distribution and many 3rd party repositories reflect that, I
have
On 05/26/2016 09:44 AM, Frederic Crozat wrote:
I don't know how this software will be shipped, but if it is as a RPM
package, it is best to be installed in /usr/lib/systemd/system.
/etc/systemd/system should be for admins or 3rd parties not using
packages.
/etc is admin only territory and shou
On 05/26/2016 01:15 PM, Lennart Poettering wrote:
On Thu, 26.05.16 14:39, Thomas Güttler (guettl...@thomas-guettler.de) wrote:
>Am 26.05.2016 um 14:35 schrieb Andrei Borzenkov:
> >On Thu, May 26, 2016 at 3:18 PM, Thomas Güttler
> > wrote:
> >>I want to know if the service is alive,
> >
> >
On 05/26/2016 02:38 PM, Lennart Poettering wrote:
>On 05/26/2016 09:36 AM, Lennart Poettering wrote:
>
> >/usr is for the OS vendor really.
>
>Given that it's generally expected and wanted that application developers
>follow the os vendors packaging guideline and rules as possible in
>distrib
On 06/02/2016 04:33 PM, JB wrote:
Thanks, that's the plan but in order to buy myself that time, I'd need
to get this resolved first.
I'm afraid you wont buy yourself anything since your only option is to
start immediately to look into applying real-time kernel patches or find
another dis
On 06/07/2016 01:26 PM, Lennart Poettering wrote:
Not sure where this really
leaves us.
It leaves people wondering if it fits into bus 1. . .
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailma
On 06/07/2016 03:13 PM, Hebenstreit, Michael wrote:
we need to keep the OS of our systems are stripped down to an absolute bare
minimum.
If you need absolute bare minimum systemd [¹] then you need to
create/maintain your entire distribution for that ( for example you
would build systemd s
On 06/07/2016 10:17 PM, Hebenstreit, Michael wrote:
I understand this usage model cannot be compared to laptops or web servers. But
basically you are saying systemd is not usable for our High Performance
Computing usage case and I might better off by replacing it with sysinitV. I
was hoping f
On 06/08/2016 06:51 AM, Hebenstreit, Michael wrote:
Thanks for this and the other suggestions!
So for starters we’ll disable logind and dbus, increase watchdogsec
and see where the footprint is – before disabling journald if
necessary in a next step.
You cannot disable journal but you can
On 06/09/2016 08:55 AM, Bao Nguyen wrote:
Can it be declared like that? Can it work as expected if LSB depends
on systemd service?
Migrate that scripted mess to type units and be done with it.
JBG
___
systemd-devel mailing list
systemd-devel@lis
On 06/09/2016 09:02 AM, Ross Lagerwall wrote:
On Thu, Jun 9, 2016 at 9:55 AM, Bao Nguyen wrote:
With a new enough systemd, you should be able to add a snippet to extend
the initscript like this:
$ cat /etc/systemd/system/my_lsb_service.service.d/local.conf
[Unit]
Requires=systemd_1.service
Afte
On 06/27/2016 02:36 PM, Chris Kühl wrote:
Workshops:
A new addition to this year's conference is the workshop day. The goal
of this day is to offer hands-on training sessions to those who want
to learn more about systemd. It's intended that these trainings be
conducted by systemd community me
On 07/04/2016 08:01 PM, Martin Pitt wrote:
Feedback appreciated!
Shipping an predefined desktop units arguably does not belong upstream
since it's just catering to one ( desktop ) out of three (
embedded/server/desktop) target user base. It might result in other two
target user base having
On 07/06/2016 08:50 AM, Colin Guthrie wrote:
I'm not sure how this would work regarding things like g-s-d which you
want in multiple DEs.. perhaps the gnome.target would have to be split
up into gnome-base.target and gnome.target to allow for this use case?
Or perhaps g-s-d could just become bus
On 07/06/2016 12:51 PM, Jan Alexander Steffens wrote:
On Wed, Jul 6, 2016 at 2:21 PM Jóhann B. Guðmundsson
mailto:johan...@gmail.com>> wrote:
It's questionable if such application should reside in upstream
systemd since arguably systemd should have never
On 07/06/2016 02:34 PM, Martin Pitt wrote:
This /usr/lib/systemd/user/graphical.target (and only that)*does*
belong in to systemd, as it cannot sensibly be in any
gnome-session/mate-session/kde-session/etc. package -- it's a shared
resource/synchronization point between all of those. Having a un
># gnome-user-graphical.target
>
>[Unit]
>Description=User systemd services for graphical session
>StopWhenUnneeded=yes
So this is just another name for "my"
gnome.target/gnome-session.target. As I said I'm not too fussed about
how we name those, we should just decide about some convention.
On 08/04/2016 07:45 AM, Stéphane ANCELOT wrote:
You are right, but that's only systemd that is incompatible with this feature
(and some more).
Actually all initsystems are incompatible with this.
As some people and some articles I have read on the web, it is time for myself
switching my s
Just a heads up based on the merge of [1] systemd no longer requires
features to have been accepted in the upstream kernel before merging it.
Adjust you expectation accordingly for submission and potential
downstream breakage for type units in which upstream might have decided
to take advanta
On 08/15/2016 04:08 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Aug 15, 2016 at 10:53:56AM +, Jóhann B. Guðmundsson wrote:
>Just a heads up based on the merge of [1] systemd no longer
>requires features to have been accepted in the upstream kernel
>before merging it.
See the
On 08/16/2016 09:04 AM, Lennart Poettering wrote:
On Mon, 15.08.16 10:53, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
Johann, what you are posting here is really not helpful in any
way.
It's helpful in that way of letting people know that you have chosen to
deviating from ups
On 08/16/2016 09:06 AM, Lennart Poettering wrote:
On Mon, 15.08.16 16:52, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
The world isn't just black and white, you know.
That depends entirely on ones perception of the world does it not?
I'm interesting to hear when it is no
On 08/16/2016 10:44 AM, Greg KH wrote:
On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote:
Recent case in point is the that the wireguard maintainer was/is interested
seeing it property integrated into systemd. Anywork related to that could not
be started *until* he had his
On 08/16/2016 10:27 AM, Lennart Poettering wrote:
On Tue, 16.08.16 10:11, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
Yes kdbus is a good example why this should not be done.
Why not just have an experimental repository for out of tree, un-merged
stuff upstream and those that want to
On 08/16/2016 10:42 AM, Greg KH wrote:
As long as this new code doesn't break things for users without those
kernel patches, why would you object? Are you having to maintain these
new features for some reason?
No but I eventually might have to deal with the fallout from such approach.
Why ca
On 08/16/2016 11:28 AM, Greg KH wrote:
On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote:
On 08/16/2016 10:44 AM, Greg KH wrote:
On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote:
Recent case in point is the that the wireguard maintainer was/is
On 08/16/2016 12:31 PM, Greg KH wrote:
On Tue, Aug 16, 2016 at 12:25:47PM +, Jóhann B. Guðmundsson wrote:
On 08/16/2016 11:28 AM, Greg KH wrote:
On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote:
Such as what specifically?
Are you pretending you are going to be
On 08/16/2016 12:13 PM, Greg KH wrote:
On Tue, Aug 16, 2016 at 11:23:03AM +, Jóhann B. Guðmundsson wrote:
Why cant the kernel community figure this out and solve this upstream first
since it's quite obvious from the threads that Tejun Heo linked to in that pull
request that this
On 08/16/2016 12:34 PM, Greg KH wrote:
But agreement is usually the best way to work things out, don't you
think? Isn't it better than the traditional way a company works (a
project manager says "this has to be merged!")?
Agreed mutual agreement is the best course of action always but
someti
On 08/16/2016 12:51 PM, Greg KH wrote:
On Tue, Aug 16, 2016 at 12:47:16PM +, Jóhann B. Guðmundsson wrote:
Irrelevant.
No, not at all, I'm just really confused as to what systemd changes are
required to get wireguard working properly with it?
Think of it like native integration
On 08/16/2016 12:53 PM, Greg KH wrote:
On Tue, Aug 16, 2016 at 12:51:12PM +, Jóhann B. Guðmundsson wrote:
>On 08/16/2016 12:34 PM, Greg KH wrote:
>
> >But agreement is usually the best way to work things out, don't you
> >think? Isn't it better than the tradit
On 08/16/2016 02:47 PM, Greg KH wrote:
In the meantime, to object to other developers doing work on
systemd to test out these changes seems very odd, who are you, or me, to
tell someone else what they can or can not do with their project?
Interesting philosophical question as to who owns the p
On 10/10/2016 11:31 AM, Kevin Wilson wrote:
Hello, systemd developers,
So we have now 3 V2 cgroups controller in the kernel (pids, memory and io).
The CPU controller as of now is not merged in and is available only in
an out of tree git repo (due to some debate over
it with kernel scheduler deve
On 10/10/2016 04:46 PM, Lennart Poettering wrote:
I still hope that Fedora can go the Facebook route, and just patch the
stuff in, and ignore the fight going on in the kernel community.
That wont fly by the kernel sub community in Fedora in which they are
doing whatever they can not having to
On 11/17/2016 12:11 PM, JEYARAJ wrote:
Hi All,
Dear Sir,
I ,am installing job scheduling system for a single machine.munge also
installed latest version.
I start with Munge service .Error is showing;
Again I used the command:
Systemctl status munge.service
Error is came.
This error is irre
On 12/02/2016 12:28 PM, Simon McVittie wrote:
Does this mean your user is trying to be physically present in two places
at the same time? How is this a useful thing to do?:-)
Clones are very useful things to have.
You just sit a drink a pina colada in hut in bora bora while they do all
the h
On 05/10/2015 10:07 PM, Mark Oteiza wrote:
Hi,
In 219, systemd.networkd fails to configure and set up links with ipv6
disabled.
Propably better to use |*ipv6.disable_ipv6=**1* |which will ||will keep
the IPv6 stack functional but wont assign any IPv6 addresses but I have
to ask what's the
On 05/11/2015 10:31 AM, Andrei Borzenkov wrote:
I had issues with accessing some sites with IPv6 enabled. Not everyone
lives in shiny new world and IPv6 support from providers can be quite
buggy.
Most likely due to misbehaving name servers which should then be
reported to hostmaster of the s
On 05/15/2015 07:54 AM, jsyna...@redhat.com wrote:
From: Jan Synacek
---
changes in v2:
* simplified creation of new arguments (replaced unnecessary dynamic allocation
with a VLA)
* renamed add_file_change to unit_file_add_changes
* addressed wording issues in documentation
Hmm is the u
On 05/15/2015 09:51 AM, Lennart Poettering wrote:
But anyway, this is certainly a matter of taste...
Or cause for confusion.
I asked an noob to run systemctl enable --now and he immediately
asked back if he ran systemctl enable if it would not be enabled
"immediately" so "--now" seems to
On 05/21/2015 03:19 PM, Colin Walters wrote:
On Wed, Apr 1, 2015, at 10:02 AM, Martin Pitt wrote:
IMHO subvolumes, like hard disk partitions, are something that the
administrator of a host should create deliberately only. Automatically
created ones just create confusion about "why the heck can
On 05/27/2015 01:07 PM, Martin Pitt wrote:
Hello,
as discussed in the "get some distro patches upstream" thread, this is
the generalization for supporting different
chkconfig/update-rc.d/whatnot distro implementations of enabling
init.d scripts, as per LSB specification.
Is this not somethi
On 05/27/2015 04:00 PM, Lennart Poettering wrote:
On Wed, 27.05.15 13:39, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
On 05/27/2015 01:07 PM, Martin Pitt wrote:
Hello,
as discussed in the "get some distro patches upstream" thread, this is
the generalization for supporting
On 06/01/2015 08:36 PM, Matthew Karas wrote:
I am trying to start a dropbear service after my openvpn service starts up.
---
[Unit]
Description=SSH Per-Connection Server
Wants=dropbearkey.service
After=syslog.target dropbearkey.service
Wants=openvpn@equipment.se
On 06/02/2015 11:06 AM, David Herrmann wrote:
Regarding the final github address: David Strauss kindly offered the
'systemd' user to us. Hence, we hope to move the repository to
github.com/systemd/systemd this week. Sorry for the confusion, I hope
we can settle all this this week.
Given that
On 06/02/2015 11:48 AM, Dimitri John Ledkov wrote:
On 2 June 2015 at 12:34, "Jóhann B. Guðmundsson" wrote:
On 06/02/2015 11:06 AM, David Herrmann wrote:
Regarding the final github address: David Strauss kindly offered the
'systemd' user to us. Hence, we hope to mo
On 06/09/2015 11:02 AM, Lennart Poettering wrote:
On Mon, 01.06.15 22:43, Michael Biebl (mbi...@gmail.com) wrote:
2015-06-01 20:12 GMT+02:00 David Herrmann :
Hi
As of today we've disabled git-push to fd.o. The official development
git repository is now at github [1].
What about the bug tra
On 06/09/2015 11:57 AM, Mihamina Rakotomandimby wrote:
On 06/09/2015 02:30 PM, "Jóhann B. Guðmundsson" wrote:
As of today we've disabled git-push to fd.o. The official development
git repository is now at github [1].
What about the bug tracker? Will it remain at fdo's
On 06/09/2015 06:42 PM, David Timothy Strauss wrote:
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?
What
On 06/09/2015 06:53 PM, Camilo Aguilar wrote:
Oh please Jira no, it is too much and the user friendliness is highly
arguable.
Please do not top post and compared to bugzilla and the lack of proper
oversight github and other issue tracker provide it's much better.
JBG
_
On 06/09/2015 06:42 PM, David Timothy Strauss wrote:
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?
I ca
On 06/09/2015 07:50 PM, Lennart Poettering wrote:
On Tue, 09.06.15 11:30, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
I would like to see us move and migrated the bugs to jira ( which is without
doubt the best and friendliest bug tracker I have found ) which integrates
nicely with
On 06/09/2015 09:34 PM, Lennart Poettering wrote:
On Tue, 09.06.15 19:19, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
On 06/09/2015 06:42 PM, David Timothy Strauss wrote:
Let's just try the GitHub tracker. I like how it associates issues with
pull requests and supports auto-li
On 06/09/2015 09:44 PM, Lennart Poettering wrote:
On Tue, 09.06.15 21:11, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
We need to do proper QA to properly support and backup our downstream
consumers ( distributions, embedded and otherwise) and that means tagging
bugs by distributions
On 06/09/2015 10:21 PM, Lennart Poettering wrote:
On Tue, 09.06.15 19:33, Jakub Skořepa (ja...@skorepa.info) wrote:
Hello,
My name is Jakub Skořepa and I'm working on Cockpit UI for Systemd
Timers.
For that I need to create and modify systemd unit files. Cockpit uses D
-Bus for everything so
On 06/10/2015 12:30 PM, Stephen Gallagher wrote:
A good overview of what we're aiming to accomplish can be found here: h
ttps://github.com/cockpit-project/cockpit/wiki/Feature:-Systemd
-timers#stories
Though at the end of the day, it might be fair to say that systemd
timers are cool and very
On 06/10/2015 12:35 PM, Lennart Poettering wrote:
On Wed, 10.06.15 14:04, Martin Jansa (martin.ja...@gmail.com) wrote:
WHat really surprises me about the whole discussion is that we cannot
be the first ones running into this. Given the success of github this
must be a common issue. And if it
On 06/10/2015 03:09 PM, Lennart Poettering wrote:
On Wed, 10.06.15 14:53, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
WHat really surprises me about the whole discussion is that we cannot
be the first ones running into this. Given the success of github this
must be a common issue. And
On 06/10/2015 03:02 PM, Stephen Gallagher wrote:
You make some good points Jóhann. It probably does make sense to focus
(at least at first) on managing timer units shipped alongside services
as opposed to trying to develop a UI for managing arbitrary timer
units. I'll discuss this with some of
On 06/10/2015 04:35 PM, Lennart Poettering wrote:
On Wed, 10.06.15 16:20, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
>Without proper infrastructure ( or at least the wills to acquire such ) how
>can you ( or any of us for that matter ) with a straight face advocate for
>cons
On 06/10/2015 05:46 PM, Greg KH wrote:
There's also no real need for it, I don't understand why you keep
insisting there is given how well things have been working so far.
I do understand and am aware of the complication ( legal and otherwise
social aspect of it etc ) involved with bringing fu
On 06/10/2015 07:36 PM, Greg KH wrote:
On Wed, Jun 10, 2015 at 07:04:17PM +, "Jóhann B. Guðmundsson" wrote:
On 06/10/2015 05:46 PM, Greg KH wrote:
There's also no real need for it, I don't understand why you keep
insisting there is given how well things have been w
On 06/29/2015 02:08 PM, jon wrote:
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-upgrade-default-init-system
I just installed debian 8.1, on the whole my reaction is mixed, one
thing however really pisses me off more than any other
"5.6.1. Stricter
On 06/29/2015 03:01 PM, jon wrote:
On Mon, 2015-06-29 at 14:21 +, Jóhann B. Guðmundsson wrote:
On 06/29/2015 02:08 PM, jon wrote:
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-upgrade-default-init-system
I just installed debian 8.1, on the
On 06/29/2015 04:17 PM, Andrei Borzenkov wrote:
No. systemd changed interpretation of well established configurations
in incompatible way. There is no way to retain existing behavior. It is
far from "recommends" - it is "my way or highway".
Not following which changed interpretation of well e
On 07/02/2015 02:04 PM, François Vocel wrote:
Hello,
I installed Kolab on CentOS 7.
The amavis service will not start.
There already is a bug report about this [1] but most common cause for
amavisd not starting is the configuration files is misconfigured
https://bugzilla.redhat.com/show_b
On 08/20/2015 10:02 PM, Lennart Poettering wrote:
On Thu, 20.08.15 23:41, Michael Biebl (mbi...@gmail.com) wrote:
Hi,
say I wanted to grant an unprivileged userA the ability to
systemctl start/stop/restart/reload foo.service
and only grant this for foo.service.
Is there a way to achieve tha
On 10/13/2015 07:07 PM, David Timothy Strauss wrote:
entire members
What makes up that members list [1] in the first place?
https://github.com/orgs/systemd/people
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freed
On 11/11/2015 10:47 AM, Lukáš Nykrýn wrote:
Hi,
During systemd.conf we have discussed some recommendation for
downstreams, how they could split systemd to subpackages, so lets
continue that discussion here.
I thought the conscious was not recommending downstream to split systemd
into subpac
On 11/11/2015 10:57 AM, Michal Sekletar wrote:
On Wed, Nov 11, 2015 at 11:52 AM, Jóhann B. Guðmundsson
wrote:
I thought the conscious was not recommending downstream to split systemd
into subpackages?
This decision was recently (at systemd.conf) reevaluated :)
Not everybody can attend
On 11/11/2015 11:58 AM, Martin Pitt wrote:
However, is this even a topic for upstream,
I would argue not.
I would argue that this is a downstream collaboration matter in which a)
the split should be the same regardless of distribution and the sub
components should be split in same manner acr
On 11/11/2015 01:12 PM, Michael Biebl wrote:
2015-11-11 12:58 GMT+01:00 Martin Pitt :
Hello all,
in case it's useful, this is how we split them in Debian.
However, is this even a topic for upstream, apart from giving
recommendations? I. e. do you actually consider putting this kind of
split
On 11/11/2015 03:39 PM, Frank Steiner wrote:
If I was able to work with systemd unit files, I could perfectly
do what I want, but I'm stuck with this LSB file.
Why are you stuck with that lsb file and what exactly does it do?
( Paste the content of it )
JBG
___
On 11/11/2015 03:51 PM, Zbigniew Jędrzejewski-Szmek wrote:
Why not systemd-devel?
Because these aren't development related discussion and there is a need
for separated collaborated git repository to prevent duplication of
downstream work etc.
JBG
__
On 11/11/2015 04:04 PM, Reindl Harald wrote:
Am 11.11.2015 um 17:03 schrieb Jóhann B. Guðmundsson:
On 11/11/2015 03:51 PM, Zbigniew Jędrzejewski-Szmek wrote:
Why not systemd-devel?
Because these aren't development related discussion
this list was multiple times statet also as
On 11/11/2015 08:28 PM, Michael Biebl wrote:
2015-11-11 21:21 GMT+01:00 Jóhann B. Guðmundsson :
[snip]
To coordinate and oversee and collectively share work done between
distribution integrating the relevant components in their distribution.
And now you started an unrelated meta-discussion
On 11/11/2015 08:38 PM, Reindl Harald wrote:
Am 11.11.2015 um 21:21 schrieb Jóhann B. Guðmundsson:
On 11/11/2015 04:04 PM, Reindl Harald wrote:
Am 11.11.2015 um 17:03 schrieb Jóhann B. Guðmundsson:
On 11/11/2015 03:51 PM, Zbigniew Jędrzejewski-Szmek wrote:
Why not systemd-devel
On 11/13/2015 01:49 PM, Lennart Poettering wrote:
Heya!
So, I am tempted to make the following changes to systemd, and was
wondering about opinions about it:
a) The first change is rather uncontroversial I presume: I'd like to
set DefaultTasksAccounting=yes in system.conf by default. This
On 12/09/2015 07:46 PM, Lennart Poettering wrote:
I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate Envir
On 12/10/2015 03:20 PM, Reindl Harald wrote:
Am 10.12.2015 um 15:46 schrieb Jóhann B. Guðmundsson:
If you are unaware of any other use case for it
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
[root@testserver:~]$ cat /etc/sysconfig/httpd
OPTIONS
On 12/11/2015 03:56 AM, Andrei Borzenkov wrote:
10.12.2015 18:44, Jóhann B. Guðmundsson пишет:
On 12/10/2015 03:20 PM, Reindl Harald wrote:
Am 10.12.2015 um 15:46 schrieb Jóhann B. Guðmundsson:
Care to show example how it should be done from your point of view?
So that they can actully be
On 12/18/2015 04:00 PM, Michael Biebl wrote:
2015-12-09 20:46 GMT+01:00 Lennart Poettering :
On Wed, 09.12.15 18:27, Soumya Koduri (skod...@redhat.com) wrote:
Hi,
I have created a systemd.unit(nfs-ganesha.service) file as below :
[Unit]
After=nfs-ganesha-config.service
Requires=nfs-ganesh
On 12/21/2015 01:00 PM, Reindl Harald wrote:
Am 21.12.2015 um 12:40 schrieb Jóhann B. Guðmundsson:
ExecStart=/usr/sbin/foobard $OPTS
and then tell admin to use systemctl edit
[Unit]
Environment=OPTS=-baz
bonus points if we could standardise the $OPTS var name across daemons.
Then distros
On 12/21/2015 01:30 PM, Reindl Harald wrote:
ExecStart=/path/to/daemon FOO would cut you from distro-changes in
other params and explained abvoe sooner or later lead in failing and
could even be security relevant depending on new options or removed
options in the distro-unit
You do realize
On 12/21/2015 03:17 PM, Michael Biebl wrote:
The benefit of that instead of having to override the complete
ExecStart line should be obvious and has already be mentioned in this
very thread.
No what's obvious is it does not add any value not et all and not all
daemons and service support add
On 12/21/2015 02:15 PM, Reindl Harald wrote:
and since you say this what is your business for taking
"EnvironmentFile" away from administrators area - my config, take your
hands from it instead propose to break it - nobody cares if you would
something do in a different way as long you are n
1 - 100 of 420 matches
Mail list logo
