Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

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

Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

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

Re: [systemd-devel] Static IP address on wandering Wi-Fi client

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

Re: [systemd-devel] Static IP address on wandering Wi-Fi client

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

Re: [systemd-devel] Static IP address on wandering Wi-Fi client

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

Re: [systemd-devel] How to speed up detection of emmc partition and mount the filesystem

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

Re: [systemd-devel] Collect logs over serial

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",

[systemd-devel] Mkosi and downstream release cycles and their support

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

Re: [systemd-devel] taking time off

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

Re: [systemd-devel] RFC: idea for a pstore systemd service

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

Re: [systemd-devel] Bugfix release(s)

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

Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

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

Re: [systemd-devel] Fedora 25, cgroups V2 and systemd roadmap

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

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 traditional w

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

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 upstream

[systemd-devel] Head ups - upstream first no longer applies to the kernel.

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

Re: [systemd-devel] firmware update check script

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

Re: [systemd-devel] Standardizing names for graphical session units

># 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.

Re: [systemd-devel] Standardizing names for graphical session units

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

Re: [systemd-devel] Standardizing names for graphical session units

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 <johan...@gmail.com <mailto:johan...@gmail.com>> wrote: It's questionable if such application should reside in upstream systemd since arguably systemd should have n

Re: [systemd-devel] Standardizing names for graphical session units

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

Re: [systemd-devel] systemd.conf early-bird tickets, cfp and workshops

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

Re: [systemd-devel] Can LSBInitScipts specify an dependency on systemd unit?

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]

Re: [systemd-devel] Can LSBInitScipts specify an dependency on systemd unit?

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

Re: [systemd-devel] question on special configuration case

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

Re: [systemd-devel] question on special configuration case

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

Re: [systemd-devel] question on special configuration case

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

Re: [systemd-devel] Systemd ask-password unable to handle cryptsetup passwords with \0 character inside ?

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

Re: [systemd-devel] systemd network interface names - new twist

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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

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

Re: [systemd-devel] check to see if service is still alive

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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

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

Re: [systemd-devel] automount nested nfs share

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

Re: [systemd-devel] centos-ci

On 04/12/2016 02:43 PM, Lennart Poettering wrote: On Tue, 12.04.16 11:52, Jóhann B. Guðmundsson (johan...@gmail.com) 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

[systemd-devel] centos-ci

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

Re: [systemd-devel] udev vs. nscd vs. /var automount

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

Re: [systemd-devel] [ANNOUNCE] systemd.conf 2016

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 systemd-devel@lists.freedesktop.org

Re: [systemd-devel] systemd efi boot and default entry

On 04/01/2016 03:15 PM, Tobias Hunger wrote: On Fri, Apr 1, 2016 at 4:59 PM, Jóhann B. Guðmundsson <johan...@gmail.com> 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 re

Re: [systemd-devel] systemd efi boot and default entry

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, are you

Re: [systemd-devel] systemd efi boot and default entry

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

Re: [systemd-devel] New "ubuntu-ci" integration tests are being added to PRs

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

Re: [systemd-devel] New "ubuntu-ci" integration tests are being added to PRs

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

Re: [systemd-devel] New "ubuntu-ci" integration tests are being added to PRs

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

Re: [systemd-devel] New "ubuntu-ci" integration tests are being added to PRs

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

Re: [systemd-devel] Moving systemd-bootchart to a standalone repository

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

Re: [systemd-devel] [ANNOUNCE] systemd v229

On 02/11/2016 05:47 PM, Lennart Poettering wrote: On Thu, 11.02.16 17:32, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: I just tagged the v229 release of systemd. Enjoy! CHANGES WITH 229: * The coredump collection logic has been reworked: when a coredump

Re: [systemd-devel] [RFC] the chopping block

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

Re: [systemd-devel] [RFC] the chopping block

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

Re: [systemd-devel] [RFC] the chopping block

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

Re: [systemd-devel] [ANNOUNCE] systemd v229

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

Re: [systemd-devel] known but not-listed units

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

Re: [systemd-devel] CODENAME field in /etc/os-release

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

Re: [systemd-devel] Do we need /dev/core?

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.

Re: [systemd-devel] Do we need /dev/core?

On 12/30/2015 11:44 AM, Marco d'Itri wrote: On Dec 30, "Jóhann B. Guðmundsson" <johan...@gmail.com> 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

Re: [systemd-devel] Query regarding "EnvironmentFile"

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

On 12/21/2015 04:36 PM, Michael Biebl wrote: 2015-12-21 17:30 GMT+01:00 Jóhann B. Guðmundsson <johan...@gmail.com>: 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 adde

Re: [systemd-devel] Query regarding "EnvironmentFile"

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

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]

Re: [systemd-devel] Query regarding "EnvironmentFile"

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

On 12/21/2015 04:02 PM, Michael Biebl wrote: 2015-12-21 17:00 GMT+01:00 Jóhann B. Guðmundsson <johan...@gmail.com>: 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 s

Re: [systemd-devel] Query regarding "EnvironmentFile"

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

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

Re: [systemd-devel] RFC: Setting TasksMax= by default

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.

Re: [systemd-devel] [packaging] split of systemd package

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

Re: [systemd-devel] [packaging] split of systemd package

On 11/11/2015 10:57 AM, Michal Sekletar wrote: On Wed, Nov 11, 2015 at 11:52 AM, Jóhann B. Guðmundsson <johan...@gmail.com> wrote: I thought the conscious was not recommending downstream to split systemd into subpackages? This decision was recently (at systemd.conf) reeva

Re: [systemd-devel] [packaging] split of systemd package

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

Re: [systemd-devel] [packaging] split of systemd package

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

Re: [systemd-devel] Detect if a script runs during bootup

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

Re: [systemd-devel] [packaging] split of systemd package

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

Re: [systemd-devel] [packaging] split of systemd package

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 users

Re: [systemd-devel] [packaging] split of systemd package

On 11/11/2015 08:28 PM, Michael Biebl wrote: 2015-11-11 21:21 GMT+01:00 Jóhann B. Guðmundsson <johan...@gmail.com>: [snip] To coordinate and oversee and collectively share work done between distribution integrating the relevant components in their distribution. And now you s

Re: [systemd-devel] [packaging] split of systemd package

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

Re: [systemd-devel] A few GitHub team changes

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

Re: [systemd-devel] amavis

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

Re: [systemd-devel] Stricter handling of failing mounts during boot under systemd - crap idea !

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

Re: [systemd-devel] Stricter handling of failing mounts during boot under systemd - crap idea !

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

Re: [systemd-devel] Stricter handling of failing mounts during boot under systemd - crap idea !

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

Re: [systemd-devel] Creating units using D-Bus

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

Re: [systemd-devel] Creating units using D-Bus

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

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

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

Re: [systemd-devel] Creating units using D-Bus

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

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

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

  1   2   3   4   >