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 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
Hi All,
could you please any help on this issue.
Thanks,
Gowtham
On Thu, Dec 17, 2020 at 12:27 PM gowtham b
wrote:
> Hi,
>
> hope you are doing good
> Facing issue in systemd 244 version Execstop is not executing while
> process crashing. Did additional testing if we restart
Hi,
hope you are doing good
Facing issue in systemd 244 version Execstop is not executing while process
crashing. Did additional testing if we restart the process via systemd
"systemctl restart tr069pa" command Execstop is running properly seeing the
restart log in the redirected file. The same se
s right ( as in it's not going to be
replacing wpa supplicant on other *nix like for example the BSD stack )?
Regards
Jóhann B.
___
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
o a single
place ( networkd )?
Why do you want to keep the network configuration and management space
fragmented ( as opposed to consolidated ) ?
Regards
Jóhann B.
___
systemd-devel mailing list
[email protected]
using
DHCP or a static IP address.
If you have not yet you should have a look at IWD [1][2][3] before
settling on wpa_suppplicant for your product.
Regards
Jóhann B.
1. https://www.youtube.com/watch?v=QIqT2obSPDk
2. https://lists.01.org/pipermail/iwd/
3. https://git.kernel.org
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
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
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/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
__
On 1/15/19 6:49 PM, Lennart Poettering wrote:
On Di, 15.01.19 11:23, Eric DeVolder ([email protected]) 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/14/19 3:48 PM, Lennart Poettering wrote:
On Mo, 14.01.19 08:43, Dave Reisner ([email protected]) 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
Hi guys,
I'm running Ubuntu 16.04.01 Server and just realised some log files are not
being created.
Such as:
/var/log/kern.log
/var/log/postgresql/postgresql.log
service postgresql status
Warning: Journal has been rotated since unit was started. Log output is
incomplete or unavailable.
roo
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 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 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 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 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 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 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: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: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 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 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 10:27 AM, Lennart Poettering wrote:
On Tue, 16.08.16 10:11, Jóhann B. Guðmundsson ([email protected]) 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: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 09:06 AM, Lennart Poettering wrote:
On Mon, 15.08.16 16:52, Jóhann B. Guðmundsson ([email protected]) 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 09:04 AM, Lennart Poettering wrote:
On Mon, 15.08.16 10:53, Jóhann B. Guðmundsson ([email protected]) 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/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
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/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
I don't see a conflict. These are all per-user units, so if user A
runs kde-session.target and user B runs gnome-session.target that's
fine -- the two user systemd instances don't even know about each
other.
It's more about people will be have hard time distinguish between
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
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:[email protected]>> wrote:
It's questionable if such application should reside in upstream
systemd since arguably systemd should have never
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/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
community members. Proposals for workshops can be
submitted at https://cfp.systemd.io
If you have questions about workshops please contact us at [email protected]
Or you can just be replied to here since you advertise 300 euro
participation fee for workshop schedule that a) does not exist and b) is
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/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/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/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/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 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
[email protected]
https://lists.freedesktop.org/mailma
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 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 05/26/2016 01:15 PM, Lennart Poettering wrote:
On Thu, 26.05.16 14:39, Thomas Güttler ([email protected]) 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 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 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 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/25/2016 03:22 PM, Lennart Poettering wrote:
On Wed, 25.05.16 10:05, Jóhann B. Guðmundsson ([email protected]) 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
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
Open up a support case with Red Hat since that's what you are paying for.
On 05/04/2016 08:40 AM, Marco Giunta wrote:
Hi at all,
I've a problem with automount features of systemd. I need to mount two
nfs share in this way:
/srv/nfsnfs-server.example.com:/share1
/srv/nfs/nested
On 04/12/2016 02:43 PM, Lennart Poettering wrote:
On Tue, 12.04.16 11:52, Jóhann B. Guðmundsson ([email protected]) wrote:
Anyone know that centos is not running the latest version(s) of systemd
required for the upstream bug tracker so one has to ask what notification
spam is this
"Ca
Anyone know that centos is not running the latest version(s) of systemd
required for the upstream bug tracker so one has to ask what
notification spam is this
"Can one of the admins verify this patch?"
JBG
___
systemd-devel mailing list
systemd-devel@
On 04/06/2016 09:15 AM, Łukasz Stelmach wrote:
Hi,
I've hit a problem caused by a mix of: automounting + glibc + udev + my
partition layout. Apparently it is impossible to make /var automountable
because udev (which needs to enumerate devices befor mounting them) is
trying to connect to /var/r
On 04/05/2016 08:40 AM, Lennart Poettering wrote:
one day of hands-on
training sessions.
Who will be training what exactly?
JBG
___
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/system
On 04/01/2016 03:15 PM, Tobias Hunger wrote:
On Fri, Apr 1, 2016 at 4:59 PM, Jóhann B. Guðmundsson
wrote:
That makes no sense that an boot is not market completed until it manage to
contact it's update servers but inline with other hacks coreOS is doing in
relation with systemd.
I se
On 04/01/2016 03:15 PM, Alex Crawford wrote:
On 04/01, Jóhann B. Guðmundsson wrote:
That makes no sense that an boot is not market completed until it manage
to contact it's update servers but inline with other hacks coreOS is
doing in relation with systemd.
To what hacks, exactly, ar
On 04/01/2016 12:44 PM, Tobias Hunger wrote:
Hi Jóhann and Vasiliy,
IIRC both coreos and chormeOS only mark a boot as successful after
talking to their respective update servers. The assumption apparently
is that the OS can fix itself when it is able to communicate properly
with its own update s
On 04/01/2016 10:52 AM, Vasiliy Tolstov wrote:
2016-04-01 13:50 GMT+03:00 Jóhann B. Guðmundsson :
AFAIK the android boot process fires an standard broadcasting action
"ACTION_BOOT_COMPLETED" once system services are up and running in memory,
which is the time when it considered the
On 04/01/2016 10:11 AM, Vasiliy Tolstov wrote:
2016-04-01 13:08 GMT+03:00 Jóhann B. Guðmundsson :
I dont see how you plan on implement this if not with either a secondary
program loader which stores an redundant environment or an kernel support
that does the similar/same thing I mean you need
On 03/31/2016 02:31 PM, Michal Sekletar wrote:
We don't need to extend the kernel in order to implement this
particular mechanism. After new kernel is installed, you make it
default and mark as "tentative". Then, after first successful boot of
newly added bootloader entry you just remove the fl
On 03/30/2016 03:49 PM, Michal Sekletar wrote:
On Mon, Mar 21, 2016 at 1:42 PM, Vasiliy Tolstov wrote:
Now i want to have two entries and assign priority to it via systemd,
in my use-case i want to know last succeseful boot entry and use it.
After upgrade i want to boot from new antry and if
On 02/18/2016 11:26 AM, Daniel Mack wrote:
On 02/18/2016 12:19 PM, Jóhann B. Guðmundsson wrote:
>On 02/18/2016 10:22 AM, Daniel Mack wrote:
>>I disagree. All sorts of testing is good for us, and if a PR is breaking
>>downstream Ubuntu, and we recognize that before merging
On 02/18/2016 10:43 AM, Martin Pitt wrote:
I'd actually turn it the other way around and claim that if Fedora,
Arch, etc. have downstream tests, then please trigger them too. After
all, failures of them don't block anything (right now, anyway), and
having the extra information in the PRs can onl
On 02/18/2016 10:22 AM, Daniel Mack wrote:
I disagree. All sorts of testing is good for us, and if a PR is breaking
downstream Ubuntu, and we recognize that before merging, that's really
great.
I'm all for more testing the better but due to downstream fragmentation
all these have the same fund
On 02/18/2016 08:01 AM, Martin Pitt wrote:
So please don't put too much attention to these results yet. I want to
to enable them to see how the testing and communication holds up in
practice, but before this we definitively need to sort out [2] first.
Will failed tests or false positives start
On 02/17/2016 04:51 PM, Daniel Mack wrote:
Hey,
[I've put all people in Cc who have had more than one commit related to
systemd-bootchart in the past]
As part of our spring cleaning, we've been thinking about giving
systemd-bootchart a new home, in a new repository of its own. I've been
worki
On 02/11/2016 09:44 PM, Andrew Bartlett wrote:
On Thu, 2016-02-11 at 20:04 +, Jóhann B. Guðmundsson wrote:
On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:
2) compat support for libsystemd-login.so and friends (these
were
merged into a single libsystemd.so a long time ago
On 02/11/2016 08:41 PM, Armin K. wrote:
On 11.02.2016 21:04, Jóhann B. Guðmundsson wrote:
On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:
2) compat support for libsystemd-login.so and friends (these were
merged into a single libsystemd.so a long time ago). We are still
On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:
>2) compat support for libsystemd-login.so and friends (these were
>merged into a single libsystemd.so a long time ago). We are still
>building compat libraries to ease the transition, but that was a
>long time ago, hence I'
On 02/11/2016 05:06 PM, Lennart Poettering wrote:
Heya!
So I am thinking about some spring cleaning, and would love to remove
the following bits from the systemd package:
All seem to be very sound choice to make.
Arguably you should chop away the environment files support in the
process si
On 02/11/2016 05:47 PM, Lennart Poettering wrote:
On Thu, 11.02.16 17:32, Jóhann B. Guðmundsson ([email protected]) wrote:
I just tagged the v229 release of systemd. Enjoy!
CHANGES WITH 229:
* The coredump collection logic has been reworked: when a coredump is
On 02/11/2016 04:50 PM, Lennart Poettering wrote:
Heya!
I just tagged the v229 release of systemd. Enjoy!
CHANGES WITH 229:
* The coredump collection logic has been reworked: when a coredump is
collected it is now written to disk, compressed and processed
(incl
On 01/14/2016 03:01 PM, Lennart Poettering wrote:
We currently do not show runtime generated unit files among the output
of "systemctl list-unit-files", but it would probably make sense
Aren't these files auto generated on each bootup/reload/restart thus
exposing them is likely to cause conf
Use the existing fields as in
NAME=
VERSION=
ID=
VERSION_ID=
PRETTY_NAME=
VARIANT=
VARIANT_ID=
Adding additional codename field serves no purpose or value which the
previous fields do not already cover.
___
systemd-devel mailing list
systemd-devel@li
On 12/30/2015 11:44 AM, Marco d'Itri wrote:
On Dec 30, "Jóhann B. Guðmundsson" wrote:
You should ask that question on the kernel mailinglist and or on the Debian
devel list if they want to remove that symbolic link to /proc/kcore
I am already dealing with the Debian side (
On 12/30/2015 11:24 AM, Marco d'Itri wrote:
Does anybody know about something actually using /dev/core or is it yet
another instance of cargo cult sysadmining?
A Debian code search shows only two packages using it. In tests.
Wrongly.
https://codesearch.debian.net/results/%22%2Fdev%2Fcore%22/pa
On 12/23/2015 08:18 PM, Reindl Harald wrote:
Am 23.12.2015 um 21:12 schrieb Jóhann B. Guðmundsson:
On 12/23/2015 07:30 PM, Alex Crawford wrote:
I like this model and I'm not sure how I would solve this if
EnvironmentFile
didn't exist.
The usual underlying cause of usage of Envi
On 12/23/2015 07:48 PM, Lennart Poettering wrote:
I see no reason why systemd should be involved with this. Just make
etcd a proper daemon, and read its config data directly, rather then
serializing it into the command line.
In sys v initscript it started out as variable options, placed on to
On 12/23/2015 07:30 PM, Alex Crawford wrote:
I like this model and I'm not sure how I would solve this if EnvironmentFile
didn't exist.
The usual underlying cause of usage of Environment or EnvironmentFile in
type units is more or less always due to the fact that the
daemon/service cannot re
On 12/23/2015 12:43 AM, Lennart Poettering wrote:
Just to clarify that. I think EnvironmentFile= was a mistake, and I
explained why. But then again, I am not planning to remove it, and I
never suggested that.
What usescases do you see for it's existence.
FYI the longer you take fixing your m
On 12/21/2015 04:36 PM, Michael Biebl wrote:
2015-12-21 17:30 GMT+01:00 Jóhann B. Guðmundsson :
It's an added work to add the environmental line to begin with and it's an
That would be done once, by upstream ideally. The work would be negligible.
Still an added work eithe
On 12/21/2015 04:02 PM, Michael Biebl wrote:
2015-12-21 17:00 GMT+01:00 Jóhann B. Guðmundsson :
No what's obvious is it does not add any value not et all
Well, I can reiterate the points, but I suggest you just read this thread again.
and not all
daemons and service support addit
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
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 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 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/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 ([email protected]) 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/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/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/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
for every other type unit ?
Or
Users sets SystemTasksAccounting=no in system.conf but enables task
accounting for a.service while while keeping it disabled for every other
type unit ?
b) I'd like to introduce DefaultTasksMax= that controls the default
value of the per-unit TasksMax= by defaul
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/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 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 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 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
___
1 - 100 of 427 matches
Mail list logo
