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 sd-boot? I mean, you certainly could do that, but the only people I know who do that do that to patch around the gatekeeping that the shim people are doing. Technically the boot chain should either be [firmware → sd-boot → kernel] or [firmware → shim → sd-boot → kernel] (if you buy into the shim thing), and nothing else. I guess "additional bootloader" in this context means that distribution cannot use sd-boot as the only bootloader for obvious reason - it is EFI only. So distribution would need to keep currently used bootloader anyway. Distributions most certainly can become efi only if they chose to do so, there nothing technical that stands in that way. If current bootloader already works on platforms supported by distribution, what is gained by adding yet another one? Freedom of *choice* If the distribution allows users the freedom to choose from a set of components that the OS "made of" or runs, to fit the user use cases or has targeted use cases ( which bootloaders such as syslinux, u-boot, redboot etc. are aimed at ) then drawing the line at bootloaders makes no sense.* * If the distribution does not allow users the freedom to choose, then it makes no sense to support multiple variants of components that provide same/similar function in the distribution.* * JBG
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? "additional bootloader"? Are they suggesting you use grub to start sd-boot? I mean, you certainly could do that, but the only people I know who do that do that to patch around the gatekeeping that the shim people are doing. Technically the boot chain should either be [firmware → sd-boot → kernel] or [firmware → shim → sd-boot → kernel] (if you buy into the shim thing), and nothing else. I guess "additional bootloader" in this context means that distribution cannot use sd-boot as the only bootloader for obvious reason - it is EFI only. So distribution would need to keep currently used bootloader anyway. Distributions most certainly can become efi only if they chose to do so, there nothing technical that stands in that way. If current bootloader already works on platforms supported by distribution, what is gained by adding yet another one? Freedom of *choice* If the distribution allows users the freedom to choose from a set of components that the OS "made of" or runs, to fit the user use cases or has targeted use cases ( which bootloaders such as syslinux, u-boot, redboot etc. are aimed at ) then drawing the line at bootloaders makes no sense.* * If the distribution does not allow users the freedom to choose, then it makes no sense to support multiple variants of components that provide same/similar function in the distribution.* * On that note if you take the bug report [1] that has been cited in this thread then it's quite evident that Debian is not about the freedom of choice. "We do not consider it valid to have a choice of boot loaders" which immediately excludes ca 20+ Linux/(F)OSS boot loader projects and thus**discriminates against the person or group of persons behind those projects and even the person trying to contribute to Debian itself "Hi I'm rescinding this request. I've got a working prototype, but I don't know where this would go." The distribution is not even about freedom of information, which prevents individuals from having the ability to seek and receive and impart information effectively. ( to understand the how and thus the why the conclusion was reached which for in this particular case *all* bootloaders projects could look at the dialog, learn from it and fix anything if it affected them or correct any misunderstanding that might be happening. ) "> Is this discussion public? Can you share it? We unfortunately do not have a written record of it." ... JBG
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 only. Please, consider it. systemd needs better release hygiene, not just a smattering of bugfix releases. As a rolling release distro, we regularly find release-day blockers. That's bad for everyone. v240 was particularly bad as 6 months had elapsed since v239 (and over 3100 commits). That's the longest timespan and most commits in any systemd release in its nearly 9 year history. Well, that sounds as if you want to volunteer as release engineer?;-) Thing is, we are understaffed. I too have a wishlist of things I'd like to see done, but with only two paid full-time upstream engineers there's only so much we can do. Interesting what has happened to the rest? Sometimes helps also just to reach out if things are getting to understaffed/overwhelmed. I'm pretty sure that those of us that partook in this journey from the get go are still here in one form or another. If you (or anyone else in the community) would like to step up and maybe take a position of release engineer, working towards a clearer release cadence I think everybody would love you for that! I know I certainly would. But additional work is not going to be done without anyone doing it. I would not mind partaking in such collaborated effort and at the same time suggest that systemd adapts the upstream kernel release model and ties it's upstream release cycle as close to the upstream kernel releases as in one major release per kernel's development cycle release no later then .rc7 with some middle ground fit's the project to quiet down for that release. With a long term goal here for the linux ecosystem being able to reach a state in which every component that makes up the core/baseOS image ( getting system to boot and run ) and run on for whatever purpose can be released as an single updated image for downstream to consume as an update for their devices/distros and what not thou others opinions might differ in that regard. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 and bin/pstore-tool). These are trivial right now, but easy to build upon if periodic, rather than just on-boot, examination of the pstore is desirable. If you look at the TODO list in our git tree, you'll find that importing and flushing pstore has been a long-time TODO list item for us. Hmm does it need to be another full blown coredump? Looking at his script this should suffice more or less for what he was trying to achive no? Create the tempfile pstore.conf with the following content d /var/lib/pstore 0755 root root - and place that file in /etc/tmpfiles.d/ Then create an path type unit - pstore.path with the following content [Unit] Description=Monitor the pstore directory for files. Documentation=https://www.kernel.org/doc/Documentation/ABI/testing/pstore [Path] PathModified=/sys/fs/pstore/ And place that file in the /etc/systemd/system directory Then create type service unit pstore.service with the following content [Unit] Description=Move pstore files to persistant storage Documentation=https://www.kernel.org/doc/Documentation/ABI/testing/pstore [Service] ExecStart=/bin/bash -c '/usr/bin/mv -t /var/lib/pstore /sys/fs/pstore/*' Restart=on-success And place that file in the /etc/systemd/system directory Then run systemctl daemon-reload and see if this suffices. Admins or whomever can then just do the cat to dmesg vodoo on the files in /var/lib/pstore if and then when they need it JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[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 which is requesting a new release of mkosi so the Arch community can update and create images with the latest Fedora releases and another one that an Ubuntu user is trying to create image of an older Ubuntu release which does not seem to have properly supported systemd ( which arguably simply is unsupported but then there needs to be an error msg to the user ) The Arch related bug/request indicates that the release cycle of mkosi needs to be tied to the release cycle of atleast every major distribution ( Arch,Fedora,Debian,OpenSuse ) however this will not scale, let alone when *every* distribution that ships systemd/mkosi will ask to be included, the code most certainly will become un-maintainable and quite ugly, quite fast. The latter requires some kind of policy regarding obsolete of distribution ( noticed that few EOL fedora releases seem to be supported in the code ) which arguably should never be handled upstream let alone hard coded ( arguably upstream should just support latest stable + next release ) Cant these whole which distro is supported and on which release be put in a file to be read by mkosi,then that file can be update/maintained by downstream without having to wait for a new release of mkosi ( and downstream can decide that for themselves and deal with those support questions and matter ). Another architectual thing ( and this might be an oversight on my part but ) how does mkosi.extra,mkosi.postinst scale along with corresponding mkosi.$distribution file? Does one have to create mkosi.$distribution, mkosi.extra.$distribution directory, mkosi.postinst.$distribution for upstreams to deal with fragmented distribution mess downstream ( /etc/sysconfig/ red hat ism, different package names, cert location, the all needless deviation that resides downstream ) How has this been thought through ( seperate directory's, git repo for each distro or what? ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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", KERNEL=="tty$FOO", SYMLINK+="ttySLAB0",
TAG+="systemd", ENV{SYSTEMD_WANTS}+="tty-logger.service"
# Vendir spesific, ( replace idVendor,idProduct,serial for with
something relevant to your environment
SUBSYSTEM=="tty", ATTRS{idVendor}=="VI123", ATTRS{idProduct}=="IDP123",
ATTRS{serial}=="12345", SYMLINK+="ttySLAB0" TAG+="systemd",
ENV{SYSTEMD_WANTS}+="tty-logger.service"
Remove any [Install] section from the tty-logger type service unit.
You might not even need the type service unit ( omitt TAG+="systemd",
ENV{SYSTEMD_WANTS}+="tty-logger.service" ) if you create a journal
snippet along these lines...
/etc/systemd/journald.conf.d/ttyslab0.conf
[Journal]
ForwardToConsole=yes
TTYPath=/dev/ttySLAB0
MaxLevelConsole=
Regards
JBG
||
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 mounted about 1.7s after systemd starts, the main reason is that the mmcbl0p4 is found by systemd after 1.4s. As a workaround I created service that is executed right after the local-fs-pre.target which execute "mount /dev/mmcblk0p4 /app" and that works, but I would like to know if there is correct way how to tell systemd that I want to mount the root fs and application fs sooner than everything else (I believe that what I want is to tell systemd to mount /dev/mmcblk0p4 without waiting for udev to find /dev/mmcblk0p4 as new device and start auto mount). Hmm... your solution could be a simple type mount unit which is ordered before the local-fs-pre.target but maybe not. + there are two type of embedded paths in this world those that are super tiny resource constrained and those that are not. Former you dont use systemd for but instead some linux micro platform usually tied to or associated with internet of terror devices ( IoT ) like Soletta project, the latter you do use systemd for but only after systemd has been put on a diet so you will need to provide proper context here as in what that custom embedded devices does or is trying to do and why you need to shave those 1.4s off, what's the problem you are trying to solve with it? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 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/pub/scm/network/wireless/iwd.git/about/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 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 systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 etc.. ) to a single place ( networkd )? Why do you want to keep the network configuration and management space fragmented ( as opposed to consolidated ) ? because that is what the standards are doing. WiFi for example can transport the IP address inline. You just need to confirm it with DHCP later. It is how the standards are written that you want to really move DHCP one level down. The same applies to cellular connections where all the IP level configuration comes via the cellular network and not DHCP. I see that's what the standard specifies but why not merge IWD/EAD with systemd ( systemd-wirelessd/systemd-etherauthd and or tightly integrate it with networkd )? What are the benefits you see keeping these as separated components as opposed to be part of the service management framework for consolidated core/baseOS The IWD/EAD are Linux only projects 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 systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 outside the above directories should be altogether removed or at least a warning issues since this is bound to create administrative mess ( as was apparent when vendor did something like that with legacy sys v init ). JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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/systemd/system/* ( Temporary ) /usr/lib/systemd/system/* ( Vendors ) Arguably the support running/loading type unit files outside the above directories should be altogether removed or at least a warning issues since this is bound to create administrative mess ( as was apparent when vendor did something like that with legacy sys v init ). I don#t really agree I must say. It's classic ( sys v ) init brokenness in which vendors placed their stuff in opt ( or elsewhere ) which more often than not was a) on separated partition b) on separated sub-volume c) on a network drive ( nfs and the likes ) then symbolic linked ( through install script ( which usually do more harm than good since such scripts assumptions are way off with the environment and infrastructure policy's ) to one of the classic init.d directories which led to the exactly same racy condition ( if legacy sysv initscript and or type units depend on something else ) and brokenness as he's experiencing here. What's the use case for placing type unit files outside those directories and supporting following symlinks to them? Why dont you always want to require type unit files to be placed in those directories to prevent things like he's experiencing and I mentioned above from happening? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 not, so you need to ensure that you boot with an initrd that mounts /usr before jumping into the root file system and everything on the core/baseOS layer should be fine otherwise things might fail silently and go unnoticed or fail spectacularly depending on the component(s) in question. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 to ask what's your reasoning for limit this to OS vendor only? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 should not be touch by anything other than themselves these days so unless the administrators create the type unit file themselves nothing should be placing type unit files there including 3rd parties not using packages. Arguably those upstream should not be shipping type unit files, legacy sysv initsctipts etc et all and I know for a fact that many upstream project outright refuse to play "favorite init system" and dont ship init scripts or type unit files with their project since they rejected my submission of type units to them based on that principal. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 the service is alive, > > > >Define "service is alive". > >the service is alive if a custom check method has the exit status of 0 That's out of the scope for systemd really. That's monitoring, and I am not convinced having custom check function support in systemd is really appropriate, this should be implemented outside of systemd really. Administrators usually create type timer units which are bound to relevant type service unit and is run on periodic interval and checks if the service responses and restarts it if it's not for those use cases where the daemon/service is in some limbo state and not responding for whatever reason ( that is if they dont have any monitoring system like zenoss or nagios etc that does that for them ). JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 >distribution and many 3rd party repositories reflect that, I have to ask >what's your reasoning for limit this to OS vendor only? It's a shared namespace. Distros have enough problems already making sure that no two packages own the same names for their binaries, libraries, ... If you now allow multiple unrelated parties to all dump their own stuff in there, then you can only fail with that. If 3rd party application providers aren't following the vendor OS packaging guidelines well then that OS vendors will have that mess on it's hand ( or rather that unfortunate administrator that install said application or application stack ) and that pretty much can be said about anyone or anything not following upstream or "standards" in general so such scenarios are doomed to fail regardless of any effort in trying to prevent that . I think /opt is deeply flawed and not thought to the end, but the one thing it does get right is that every vendor package gets its own dir below /opt, thus dealing with the namespacing problems at least a bit. That's not always the case and it's not guaranteed that 3rd party even follows that, some choose to use /srv instead of /opt and some choose to place their things anywhere . If those glorified "holy unix bible" writers in last century could have thought ahead, they would have created /usr/vendor at the same time they created /usr/local and everyone would have adapted to that already but here we are on a new century with file system//hierarchy mess on our hand, which hopefully in not to distant future application containers will take care of for us since fixing this requires joint collaborated effort of ( at least major ) distributions and them implementing it at the same time and that's not going to happen anytime soon, if ever since some of those distribution hold so deer into their false sense of "independence" or deliberately are deviating and forking themselves from one another due to "competition". JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 distro since F21 is EOL and the only response you get from everybody is "upgrade" or "try with latest release" F22 is on 4.4x kernels F23/F24 is on 4.5.x ( soon to be on 4.6.x ) and rawhide on 4.7.x so you need to apply patches to those release or use for example CentOS 7.x which comes with the 3.10 kernel JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 so you just with what you need and use systemd's built in networkd not NetworkManager, timesyncd not ntp etc, change sshd to be socket activate, only install components necessary for the application to run, kernel mods so fourth and so on ) . If you need to perform benchmark on Red Hat and it's derivatives/clones then disable this would scew the benchmark output on those would it not? Can you clarify how dbus-daemon, systemd-journald, systemd-logind, systemd-udevd are causing issue/impacting in the above setup some thing more than "I dont think we need it hence we want to disable it". JBG 1. https://freedesktop.org/wiki/Software/systemd/MinimalBuilds/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 for some simpler solution, but if it's not possible then that's life. Will certainly make an interesting topic at HPC conferences :P I personally would be interesting comparing your legacy sysv init setup to an systemd one since systemd is widely deployed on embedded devices with minimal build ( systemd, udevd and journald ) where systemd footprint and resource usage has been significantly reduced. Given that I have pretty much crawled in the entire mud bath that makes up the core/baseOS layer in Fedora ( which RHEL and it's clone derive from ) when I was working on integrating systemd in the distribution I'm also interesting how you plan on making a minimal targeted base image which installs and uses just what you need from that ( dependency ) mess without having to rebuild those components first. ( I would think systemd "tweaking" came after you had solved that problem first along with rebuilding the kernel if your plan is to use just what you need ). JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 can reduce it and the following should give the least amount of logging in all potential scenarios and usage ;) Just create "/etc/systemd/journald.conf.d/10-hpc-tweaks.conf"which contains [Journal] Storage=none MaxLevelConsole=emerg MaxLevelStore=emerg MaxLevelSyslog=emerg MaxLevelKMsg=emerg MaxLevelConsole=emerg MaxLevelWall=emerg TTYPath=/dev/null Then restart the journal ( systemctl restart systemd-journald ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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] Requires=systemd_1.service After=systemd_1.service That's just silly and introduces another level of administrator headache. What he's requesting is something that belongs as a feature request in sysv or the likes and never should be supported in systemd in any shape or form. If you use systemd write type unit for that not legacy sysv initscript. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 members. Proposals for workshops can be submitted at https://cfp.systemd.io If you have questions about workshops please contact us at i...@systemd.io 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 not part of the professional package ( read as corporate sponsored individuals since we do have quite few that would be considered professionals in the community, where this might be a value add to ) is expected to be conducted by systemd community members for systemd community members ( since they would also have to pay 300 euro fee also to attend ). It would be good to know who's the genius behind this idea, ( read sat somewhere at an meeting and had the "hey here's an idea let's add workshop to the mix, have the community manage it and charge 300 euros for it in the process" ) the pricing behind it and where does all that money go? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 having to patch things out in the environment. Why would you call it graphical-<$DE>.slice as opposed to simply <$DE>.slice which is part of the <$DE>.target and graphical target is link to that <$DE>.target ( if shipped upstream it needs to be generic enough to cater whatever is out there right ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Standardizing names for graphical session units
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 activated and not need any direct starting? It wont and it became pretty clear to me when doing the systemd integration in Fedora that each desktop environment would end up needing it's own ( boot) target and as such they should be labeled by the desktop in question ( gnome.target,lxde.target,kde.target etc ) and graphical.target would be deprecated and or point to an generic abstraction layer for the DM/DE's which the graphical.target would then starts, in which the end users would select which Desktop Environment he wanted to use to solve the above problem you are referring to. the application that would be started by the graphical desktop would be something along the line of Choose your desktop Gnome ( which starts GDM ) LXDE ( which starts LXDE ) KDE ( which starts XDM ) etc.. Basically just display some custom background image with menu entry which allows users to select the desktop environment target to be started System boots --> default.target --> graphical.target ( application started in which user selects for example the Gnome desktop menu entry ) --> gnome.target is started which all type units required to start the desktop manager are part of ( including the gnome-session.target. ) It's questionable if such application should reside in upstream systemd since arguably systemd should have never created the graphical.target to begin with ( if it had not we probably would not be having this discussion since desktop environment targets would have been created instead ). JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 mailto:johan...@gmail.com>> wrote: It's questionable if such application should reside in upstream systemd since arguably systemd should have never created the graphical.target to begin with ( if it had not we probably would not be having this discussion since desktop environment targets would have been created instead ). What do you mean? There is no user-level graphical.target in systemd (yet), and this discussion has nothing to do with the system-level graphical.target. Martin is proposing changes to and dependency's on the graphical.target trying to make it act as the abstraction layer ( since there does not exist a single DM solution that serves all DE properly ) which will never work since each desktop environment will need it's own target which can be isolated to so applications/administrators and end users can switch desktop environments ( by simply switching/isolating to another target ) if they have installed multiple DEs to be able to effectively handle the usecase that Colin pointed out ( classic use case for that are labs in university's ) . If you only have a single DE environment installed you could just make that DE the default target of the installment and skip entirely the graphical target if everything gets correctly implemented ( in effect obsoleted it ) however if you try to use a DM that belongs to an single desktop environment ( as opposed to one DM to rule them all ) with multiple desktop environments you will always end up with a mess on your hand. In anycase none of the desktop environment targets should ever be shipped with systemd upstream and depend on graphical.target but only be as a part of their relevant desktop environment, shipped with it and depend on it's own target otherwise systemd as an core/baseOS component is being (mis)used to achieved consolidation in areas which are outside it's scope. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 unit structure which actually works and is reasonably easy to extend and maintain is AFAICS the main blocker why systemd isn't being used for desktop environments at all yet. I think we are talking somewhat in mixed direction here. What I'm ( poorly ) trying to say is that you will need to make a clear distinction of naming on the type units for the desktop environment and the type units for the desktop environment user and potentially other existing type units on the system to avoid confusions and conflicting naming scheme, since Desktop Environments will need to have their own targets so based on my comments on this and for Gnome ( on Fedora ) and on the type units you are creating in your script ( that all have to reside in ~/.config/systemd/user/ directory for all the desktop environment user type units right ) so this would become something along the lines of # gnome.target [Unit] Description=Gnome Desktop Environment Documentation=https://wiki.gnome.org/ Requires=multi-user.target Wants=gdm.service Conflicts=rescue.service rescue.target After=multi-user.target rescue.service rescue.target gdm.service AllowIsolate=yes # gdm.service [Unit] Description=GNOME Display Manager Conflicts=getty@tty1.service After=getty@tty1.service Conflicts=plymouth-quit.service After=plymouth-quit.service After=rc-local.service plymouth-start.service systemd-user-sessions.service OnFailure=plymouth-quit.service [Service] ExecStart=/usr/sbin/gdm KillMode=mixed Restart=always IgnoreSIGPIPE=no BusName=org.gnome.DisplayManager StandardOutput=syslog StandardError=inherit EnvironmentFile=-/etc/locale.conf # gnome-user-graphical.target [Unit] Description=User systemd services for graphical session StopWhenUnneeded=yes # gnome-user.target [Unit] Description=User systemd services for GNOME graphical session BindsTo=gnome-user-graphical.target gnome-user-session.service # gnome-user-session.service [Unit] Description=gnome-user-session leader PartOf=gnome-user-graphical.target [Service] ExecStart=/bin/sleep infinity # someapp.service [Unit] Description=example graphical app PartOf=gnome-user-graphical.target [Service] ExecStart=/bin/sleep infinity ... This will allow for # DE units kde.target kdm.service xfce.target xdm.service DE user type units kdm-user-graphical.target kdm-user.target kdm-user-session.service xfce-user-graphical.target xfce-user.target xfce-user-session.service etc.. In your script you had an conflicting naming scheme ( gnome.target/graphical.target ) and a colliding one ( graphical.target with systemd default and potentially other DE's as well ) if multiple desktop environments where installed. And you also might need to add something like an Alias ( like for example "Alias=user-graphical.target" ) directive to the DE-user-graphical.target unit so that someapp.service can be made PartOf an generic directive (PartOf=user-graphical.target) to make it DE agnostic ( should it be required to be so ) if it's not DE specific. ( if you follow me here ). JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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. Right. >In your script you had an conflicting naming scheme ( >gnome.target/graphical.target ) and a colliding one ( graphical.target with >systemd default and potentially other DE's as well ) if multiple desktop >environments where installed. 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 two or more type units with the same name but serve two different purposes. This would work if an new type unit would be introduced which could be called .session or .user so you would end up with gnome.session or gnome.user instead of gnome.target for example or gnome.service etc. It might be an option to introduce a new type unit(s) since the existing type units might not be the right way to handle this. >And you also might need to add something like an Alias ( like for example >"Alias=user-graphical.target" ) directive to the DE-user-graphical.target >unit so that someapp.service can be made PartOf an generic directive >(PartOf=user-graphical.target) to make it DE agnostic ( should it be >required to be so ) if it's not DE specific. ( if you follow me here ). I do follow. However, there is no such thing as a "runtime alias" for units, TTBOMK. There is Alias= in the [Install] section, but this cannot really be used for this purpose -- we don't want to change the /usr/lib/systemd/user/user-graphical.target symlink every time that we start a user session in a DM. I was just using it as an example since you have the same problem trying to describe "generic" ordering/requirement/dependency in type units. One way to solve them is with type target units as you proposed ( user-graphical.target could serve that purpose ) but back in the day Lennart was against introducing generic type targets like webserver.target, database.target etc which would have simplified things quite a bit in various type service for applications that needed for example be ordered either after or before like After=webserver.target vs having to define all of them in the existence Apache,Nginx,Lighttpd,Monkey,Cherokee,Hiawatha etc. So I just automatically dismissed that as a solution since I assumed he would be consistent and reject such proposals/ideas. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 system to a professional initscript service. If you have not switched your system to an systemd based distribution now would be the time. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[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 advantages of such merged features in systemd. JBG 1. https://github.com/systemd/systemd/pull/3905 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
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 man page: Due to the lack of consensus in the kernel community, the CPU controller support on the unified cgroup hierarchy requires out-of-tree kernel patches. See cgroup-v2-cpu.txt[3]. I think that's pretty clear. If you think it should be made more clear, let me know how. Irrelevant if it's clear or not and repeating does not change the fact that merging this into the master branch means the policy of upstream first no longer applies so it can never be used as an argument used against merging submitted code against the entire systemd codebase. This ought have been rejected or resided in it's own "experimental" branch of the systemd codebase until they have sorted the cgroupv2 stuff out upstream. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 first is policy so people can submit work which has not been accepted in other upstreams. 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 stuff merged in the upstream kernel however now anyone can have anything not upstreamed implemented in systemd. Yes, we generally want a clear upstreaming perspective for kernel changes we support. But we have merged support for stuff that wasn't upstream yet before (most prominently: kdbus), and we will continue to do so in future. Yes, it would be great if cgroupvs2 would be fully merged in the upstream kernel, but given that in most parts it actually is and it provides systemd with major benefits to its core, I think it's fine to merge the support for cgroupsv2 already. 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 use/rely/test that stuff can build and run it downstream? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 it is not but such philosophical discussion are probably best served over a beer. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 stuff merged in the upstream kernel however now anyone can have anything not upstreamed implemented in systemd. Wait, what needs to be added to systemd to get wireguard "working" properly? It's just like any other network VPN service, what makes it special (well, becides the very coolness of it of course...) Were there patches that were rejected? Any pointers to them? The patches have not been written yet because the systemd developer mentioned he would not accept it until this was merged upstream. Which is a perfectly legit perspective. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 to use/rely/test that stuff can build and run it downstream? Because we want this stuff in the hands of people. In fact, we are interested into seeing the matching kernel patch in Fedora kernels too, in order to make sure this gets more presence. I have to ask to what end? This was not accepted upstream so is the plan here to expose this to larger use base, have downstream make the necessary changes to somehow pressure the upstream kernel community to accept this? If Red Hat wants the Fedora community to implement this "for testing and exposure" for their clients and business partners they should do so via copr repo along with a kernel that contains this patch and any exposed bugs wont get fixed in the kernel community since this has not been accepted right + the first one that get's bitten by any regression this might introduced would be the Arch community and probably CoreOS/Google long before the Fedora community ( Fedora is not leading anything anymore other than it's community members in circles ) who are running like headless chickens now after the failed implementation of Red Hat product ( read as the products/editions/WG's ) which has made the distribution worse off than it was when it was "generic" but there is an effort now making Fedora generic again called "modular" so it can be everything to anyone just like it was before and that circle will complete itself. And cgroupsv2 isn't just some entirely random thing: it fixes major bugs for us, and is at the core what systemd does. Which arguably is even more of a reason why un-merged upstream changes should not be implemented since fluctuating changes to such a core implementation in systemd can cause serious regression for downstream(s). What's the long term plan here if the kernel community never accepts this? What are you planning to do then and how do you expect downstreams to handle that? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 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 is a political issue not a technical one. Surely Linus and his so called lieutenants can step in and break political status quo like that. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 was/is interested seeing it property integrated into systemd. Anywork related to that could not be started *until* he had his stuff merged in the upstream kernel however now anyone can have anything not upstreamed implemented in systemd. Wait, what needs to be added to systemd to get wireguard "working" properly? It's just like any other network VPN service, what makes it special (well, becides the very coolness of it of course...) Were there patches that were rejected? Any pointers to them? The patches have not been written yet because the systemd developer mentioned he would not accept it until this was merged upstream. Again, what type of patches to systemd are needed for wireguard? For example changes to networkd configuration files. Why are you so fixated on this since his stance is arguably the correct one on refusing this in the first place *until* this has been implemented in the upstream kernel which arguably and should have been done in relation with cgroup v2 until that got sorted out. Are you against the policy of upstreaming first? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 to be reviewing this now? Do other VPNs require changes to systemd in some way? Irrelevant. Why are you so fixated on this since his stance is arguably the correct one on refusing this in the first place *until* this has been implemented in the upstream kernel which arguably and should have been done in relation with cgroup v2 until that got sorted out. Who is "his"? Tom if you must know but that view was shared with Kay and Lennart at one point. Are you against the policy of upstreaming first? The world is not black and white :) Aha like saving the planet has anything to do with saving the planet but you have answered what I asked. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 that this is a political issue not a technical one. Surely Linus and his so called lieutenants can step in and break political status quo like that. That makes no sense at all, sorry. Work with the upstream developers to get this resolved, that's all that anyone can do here. So each maintainer can prevent changeset from being merged if affect the area he ( currently ) maintains the kernel. That's interesting and begs the question how much time and energy the kernel community spend in resolving matters that stem from "opinions" and people stubbornness? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 sometimes drastic measures will need to be taken to break status quo. Did not the filesystem maintainers all get locked in a room until they could agree on the way forward in which they where let out of the room again and out came btrfs ;) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 with .network files and the likes as in the interface would be configured ||with it as opposed to be using wireguards own configuration file but as I said it's irrelevant since how and to what extent is subjected to changes once Susant and Tom have had a chance to review such work but before any such work can be started Jason needs to submit the relevant bits to be included in the kernel first which afaik he has still not done. No biscuits and marmalade and until the hottest (vpn) kid on the block has been merged upstream. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 way a company works (a > >project manager says "this has to be merged!")? > >Agreed mutual agreement is the best course of action always but sometimes >drastic measures will need to be taken to break status quo. Which is what happens when needed. We've been doing this for a long time now, you would think that people would trust us by now... Less to do with trust more to do with the fact If that process was working, Tejun Heo changes would have been merged ( or some mutual agreement reached on the way forward ) and we would not be having this discussion here in the first place. I would be living in my black and white world in which everything is dictated and dominated by cause and effect equal and opposite reaction, the black and white, the zeros and ones and you would be living in your "gray area" plane of existence hunting pokemons or doing whatever floats your boat;) JB. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 project Lennart? Those that contributed lines to it and if so do those contributors just "own" their lines ( do I own my contributed lines in the project and have a saying on how they are used , I dont think so ) in the codebase? is it the community and users surrounding it ( since without it would be meaningless) ? who? Questions in which people can and probably would debate about to death and beyond for decades. + This is about consistency as in about Lennart and others drawing the line of having code accepted upstream *before* being taken advantage of, used and merged into the project. An policy I myself whole heartily agree with but at the same time they themselves are not following that rule which makes that policy the whole definition of hypocrisy does it not? If the line has been raised from having to be accepted upstream first to being *preferred* being accepted upstream first than that's ok, no longer hypocrisy and inline with my original mail, contributors and downstream expectation adjusted accordingly which I would assume would be aligned with the kdbus experience in which years was spent in having that committed into the upstream kernel, integration was made into systemd and elsewhere, downstream *encourage* to pick it up and begin testing it [1] with the added load and changes ( implementing/reverting ) in contributed/paid time that costed contributors downstream. An costly experience that would have never come to pass if previous rule that was drawed in the sand had been followed to the letter. I personally recommend the project should stick with the original line drew in the sand, for the master branch and all the "experimental" stuff which may or may not come to pass, be kept in it's own experimental branch which would be the best of the both worlds I would think. Downstream that want stability get what they want and are less likely to experience any sudden *surprises* and those that want the experimental stuff for whatever reason like testing get what they want. JBG 1. https://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 developers). Not sure that it will be merged in the next 2 months. Fedora 25 is to be released in a month and a half, on 15 of November. https://fedoraproject.org/wiki/Releases/25/Schedule My questions are: what are the intentions regarding using cgroup v2 in systemd in F25 as the default instead of using cgroup V1? Is the absence of the CPU controller is a reason for not having cgroup V2 as a default in F25 ? and if so, why ? Future and direction of systemd in Fedora should be discussed on the fedora development list. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fedora 25, cgroups V2 and systemd roadmap
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 carry out of tree patches and wind up in the same scenario they have been in with "Secure Boot" for the past what 3 - 5 years now. I'm pretty sure that every downstream distribution has already realized that the longer they carry patch or patches that exist out of tree, the harder they get to maintain without extra support as in additional manpower in maintaining the kernel for that distribution and will also chose not to carry that patches. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Munge start Error
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 irrelevant to systemd You should contact that munge community and or consult it's documentation for correct setup and permissions of their software since your configuration of that software is giving you permission errors at startup. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 hard work ;) JGB ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd failure with ipv6.disable=1
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 usecase for disabling ipv6 in the first place? Is it because of the "I dont use it hence I disable it" mentality or is it due to some issues in networkd you have encountered with it? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd failure with ipv6.disable=1
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 site. If you disables IPv6 support in the kernel it only prevents the relevant network interfaces from being created, it does not result in disabling IPv6 name lookups from programs that makes an AF_UNSPEC or AF_INET6 request afaik hence you always end up double query the name servers ( with all it's downside ) unless you disable that within the application itself hence disabling ipv6 in the kernel makes little to no sense. You can alleviate the downside of double lookups by adding "options single-request" or "options single-request-reopen" ( the latter probably solves most of the issues with misbehaving name servers ) to /etc/resolv.conf but afaik you cannot disable globally ipv6 lookups for all applications that perform it. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] systemctl: introduce --now for enable, disable and mask
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 usecase for this to spare administrator having to type twice the systemctl command on the console as in systemctl start $foo && systemctl enable $foo becomes "systemctl start --now $foo" If that's the case would it not be better to simply support "systemctl start enable $foo" rather then introducing yet another switch for administrators to remember? On top of that is not "now" a bit confusing word to be using for this behaviour ? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] systemctl: introduce --now for enable, disable and mask
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 be implying that something is not happening immediately. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
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't I remove that directory".. It's roughly equivalent of some random package messing with your partitions and/or fstab. So if we could somehow make this conditional on "running on real iron", that would be a good compromise IMHO. I also agree with this. Real or not makes no difference systemd should not be creating subvolumes et all or atleast there should be a system wide option to disable it altogether and that option should be disabled by default upstream. This breaks btrfs setup/administrations on host, breaks tools etc. so perhaps just best to get a second opinion with upstream btrfs community and get their opinion of having core/base component creating subvolumes on their own is the *smart* thing to do and see if their words are enough to change Lennart's mind about this. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts
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 something that downstream should be carrying tailored to what init implementation what was used in the past and or is shipped in the present, ( Debian for example ships/supports multiple init systems ) and the support for this dropped upstream? In the end of the day we *want* the init scripted mess be migrated to native systemd units and the only way that will ever be done is if the support for it will be dropped upstream which forces distribution and vendors to either maintain the compatibility layer themselves and or actually go through the effort of migrating to native systemd units. I would think embedded and most distribution ( with the exception of Debian and Slackware ) should have migrated all their legacy sysv initscripts to native systemd initscripts by now. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts
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 different chkconfig/update-rc.d/whatnot distro implementations of enabling init.d scripts, as per LSB specification. Is this not something that downstream should be carrying tailored to what init implementation what was used in the past and or is shipped in the present, ( Debian for example ships/supports multiple init systems ) and the support for this dropped upstream? Well, I think it's too early for that. 3rd party software tends to be written for LSB. Also, Debian/Ubuntu only very recently switched to sytemd. Out of fairness we owe them to support the old stuff natively for a while, the same way we benefitted from that during the fedora transition. Last time I checked Debian shipped the most initscripts of the distributions roughly half more then we do in Fedora ( ca 1200 components ). Now if we put aside Debians support for multiple initsystem which makes it more likely that they prefer using generators instead of actually migrate components and we subtract the collaborated migration effort done by us systemd integrators that resided in distributions community that we did together for what past 4 or five years, it will leave ca 600 components for Debian to migrate and they will do so in roughly the same time frame as we all did collectively I would expect. Add to that the "long discussion, approval period" in Debian's community before that work would actually start to happen, we are talking about supporting this for 5 - 7 years more ( unless something is done here , upstream to nudge it's completion sooner ). 3rd party software will not migrate until they have to that is a fact ( and distributions and upstream cannot wait for something they have absolutely no control over which is another fact ). Also, there are still ~100 sysv scripts in fedora too... I'm perfectly aware the status on unmigrated components along with other systemd integration and cleanup work has not progressed since I stopped leading and doing that in Fedora and now that has started to hinder other work ( as I had expected would happen ) but this is what some of your coworkers wanted and this is precisely what they got with the associated cost of their behavior and decision(s) which ultimately will cost Red Hat more in work,money and delays of it's upcoming RHEL release(s) There was an FESCo discussion dropping all the 100 - 150 components that had not been migrated in F23 with Adam Jackson valiantly assigning an task to himself and trying migrated what he could up to that point ( kudos to him for that. I have not seen that spirit in FESCo member since what FC5/6 ) I just dont think he realized how much amount of work that was nor how distracting it would become from his other work/upstream obligations not that I have checked but I expect that he has abandoned that work by now or it's progressing very very slowly. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting up service after my openvpn connection turns up
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.service After=openvpn@equipment.service --- But I would like to start up the service after "tun0" interface is available (made by openvpn). How do I find out what to put in "Wants" and "After" for tun0? I can't seem to find anything related Also if there is a better way to get dropbear to start after tun0 has appeared I'm open to doing that as well. My goal is to have my ssh server only look at my openvpn address and ignore ssh requests that are not from the vpn iface. I'm thinking I can do this with a script setting up drop bear with the -p option (and looking for my tun0 ip4 address and using it). Why dont you just configure SSH to only ccept connections from your vpn network either via match address entry or allowusers one leave the unit startup as they are shipped from upstream and or come from your distribution? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
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 you are moving into the direction that I had anticipated we needed to do ( pull-requests ) but was hesitated to ask about ( when I have been working on my infrastructure proposal for the systemd community ) since I though it would not fly by since it limits somewhats Lennart's "drive by patches" concept, I have to ask is moving this to a 3rd party hosting site the best thing to do? In my proposal which touches quite few other things ( including replacing both bugzilla and freedesktop wiki ) which is necessary to make things work smoothly for future growth/expansion in the community and systemd adoption, is it not better we would host this ourselves under our own domain ( I have already secured systemd.community domain for that purpose ) on our own instances? Do people prefer these things being hosted at sites which one does not have full control over? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
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 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 you are moving into the direction that I had anticipated we needed to do ( pull-requests ) but was hesitated to ask about ( when I have been working on my infrastructure proposal for the systemd community ) since I though it would not fly by since it limits somewhats Lennart's "drive by patches" concept, I have to ask is moving this to a 3rd party hosting site the best thing to do? yes. There are more drive-by people on github, than there are those that know where freedesktop.org cgit is, where systemd wiki is, where systemd mailing list is, and how to setup MTA to not mangle patches, and send them through. And even if there are drive-by people who shoot an email to the mailing list, we have enough reviewers / comiters who will be able to apply that. In my proposal which touches quite few other things ( including replacing both bugzilla and freedesktop wiki ) which is necessary to make things work smoothly for future growth/expansion in the community and systemd adoption, is it not better we would host this ourselves under our own domain ( I have already secured systemd.community domain for that purpose ) on our own instances? maintaining /own/ infrastructure does not improve systemd code base. Do people prefer these things being hosted at sites which one does not have full control over? adequate infrastructure is sufficient here. there is no paranoia about hypothetical full control, or lack of it. if everything fails, most of us have systemd git clones to move things elsewhere again. Or when we find something better to use. There are more things that need to be done than simply move the git repository and there are more people involved in community projects than strictly "developers" and those needs need to be taken into account as well. And is not github bound to those idiotic us export control laws which might exclude individuals from certain country's to obtain and or contribute to the project? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
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 tracker? Will it remain at fdo's bugzilla. I have to admit I'm not a huge fan of github's bug tracker. I am not a fan of bz either... I think for now we prefer github, but will leave bz open, and we will not migrate bugs. 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 github as well as move the community wiki to confluence to strengthen collaboration in the community. I had secured the systemd.community domain for just that work a while back and I have been working on it in my spare time to design and implement workflows for that in Jira. I would be the one that would overseeing and handling the migration and I was hoping David Strauss might be willing to host that infrastructure for us and or some other place for that matter ( mini pc in systemd's HQ in German maybe ?) I had plans on discussing all of this at one of the hackfest but due to lack of time and money I have been stuck on this rock here on top of the world. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
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 bugzilla. I have to admit I'm not a huge fan of github's bug tracker. I am not a fan of bz either... I think for now we prefer github, but will leave bz open, and we will not migrate bugs. 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 github as well as move the community wiki to confluence to strengthen collaboration in the community. I use Jira everyday but it will be overkill for our use. As do I and am maintaining over 700 projects of different nature, with 400.000 issue in such instance and it's not overkill, it is scalable which is precisely what we need and provides the necessary oversight that is required to "health monitor" the project(s) and the community as well as providing the modern collaboration infrastructure we need to, to sustain ourselves as a community on the 21 century. It is the perfect bug tracker, be it single project or more ( we require atleast three different project in that instance as in one for systemd itself and atleast two for the community, which be following completely different workflow than systemd project will ) for this and it is as very scalable ( and extendable via plugins ) for the future, for the direction the building block of modern OS ( systemd ) can take. I spent eight years working in mozilla bugzilla as well as various tracker instances and I can tell you here and now that they are insufficient for the task at hand since one of the goal here is to reduce time developers spend in bug trackers not increase it. On top of that the bugzilla mozilla and tracker UI is crap to use and lacks all mobile/tablet interface as far as I know. Which bug tracker would you propose? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
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 do you define as serious use case? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
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 can setup an instance which hooks up to the github for people to tried it out and test + people that prefer reporting in github can just continue to do so, Jira imports those issues anyway.. We can also skip hosting it with you since you oppose this and having it there was just an idea anyway, I'll just find another place to host the instance for jira and confluence, I'm paying for the domain as is anyway. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
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 github as well as move the community wiki to confluence to strengthen collaboration in the community. Well, I already feel uncomfortable with moving things to one closed source platform in github, but given the advantages I accept it. However, moving things to *two* closed source platforms sounds even worse to me. If we bind our project to closed source companies I much prefer sticking to one, instead of two. There is no difference between one or many "closed source" since you decided to head down this road et all and I have yet to see the problem you sought out to alleviate will be solved with that change or that change alone for that matter. Personally I'm not foreseeing us ever hacking on Atlassian source code directly but rather extend it via plugins ( locally written or otherwise ) if the need arise ( which afaik would be only needed for QA related stuff ) so I dont see how you really can call this "closed source" however the source code for Atlassian products is available to license holders and they offer free licenses for official open source projects [¹] which covers all the plugins on the market place as well. Also, while I see quite a few shortcomings in github model, pure bug tracking certainly isn't where the shortcomings are, it's more about tracking patches where I am not convinced, but I doubt JIRA will fix that part for us... or will it? I beg the differ for pure bug tracking it is quite limited. The fact is we are long overdue building a proper infrastructure to sustain the building block of modern OS. 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, vendors, releases. Once bug has been validated, write test cases to prevent them from happening again. provide them with prebuild packages to test ( and or only provide it as btrfs snapshots to avoid having to deal with plethora of packaging formats ) write proper release notes, provide proper documentation etc. means to correctly identify and allocate resources as needed. The better work we do here is, the less is the work downstream consumers have do to downstream. I would be the one that would overseeing and handling the migration and I was hoping David Strauss might be willing to host that infrastructure for us and or some other place for that matter ( mini pc in systemd's HQ in German maybe ?) I am very much of the opinion that we should be very careful when commiting to maintain our own infrastructure. You know how undermaintained fdo was, and if we do it on our own it's even worse. Administrating our own servers is a huge amount of work especially given you have to do this over a long long time continously, and our workforce is already too limited for the amount of work we have to do. This is not as high maintenance as you let it out to be or resource intensive for that matter. ( I design this with mini pc in mind, intel nuc and the like so this could be hosted here at home if necessary and or relocated to Germany if requested ) The infrastructure for this is well maintainable by a single individual in his spare time however four ( or more ) individuals providing their free time would be optimal. Your workforce is limited to what you make it out to be and you seemed to be fixating on development resources alone which arguably is wrong on two accounts. First development resource are small ( but important ) part of a successful project. Secondly the success to systemd is thanks to collaborated effort between individuals residing in downstream consumer community's and this is where that collaboration effort would continue to grow since this is where the contributed time is best spent ( and least time I checked the community was far greater then what ca 20 committed developers ) That said I was designing my work to reduce work on direct development resources not increase it ( which infrastructure resources are supposed to do ) so if you have to spent 10 minutes more once implemented than you did before this effort will have become a failure.. One of the major benefits of github I think is that it's their very business to administer the site for us, and they'll do it as well as they possibly can. That gets substantially more difficult if we roll that all on our own, given that most of us have little desire to become administrators oursevles and we have no budget for paying one over years. I had already taken money issue into account ( and even built a project within jira to handle that process )
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
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-linking for commit IDs, user names, and other issue numbers. Is there any serious use case for systemd upstream it doesn't support? I can setup an instance which hooks up to the github for people to tried it out and test + people that prefer reporting in github can just continue to do so, Jira imports those issues anyway.. I am pretty sure we should *at least* first get some experience with github's own tools before we start jumping ship for some facets of it. We need to understand where the shortcomings are before we look for something else. As I mentioned in my other reply Jira would be an addon to github not a replacement. Atlassian has an product called "stash" [1] which is competing against github. If people are looking into alternatives for an web-based git repository solutions to github some comparison can be found here [2] I myself however is more invested in other aspects of the community than which web-based git repository solutions should be used ( what mattered only to me in that area was the move to pull requests since it was an key component for things to work in the long run and voila we have that with github ). My area of interest is the infrastructure, qa documentation and such is where I see the necessity of laying the correct foundation so we have the room for growth, collaboration as well as it being the place which results in better utilization of individuals contributed time ( developers and others, for example we need to start offloading some work of developers at this point in time by my account ) . 1. https://www.atlassian.com/software/stash 2. http://www.slant.co/topics/1440/compare/~gitlab_vs_stash_vs_github-enterprise ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
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, vendors, releases. I'd be very careful with starting to track downstream issues upstream. I explicitly want to avoid that. It's a good thing that the bug kingdoms there are seperate, and that we aren't flooded with all kinds of downstream bugs all the time upstream. The "pre-filtering" done by downstream is absolutely important to keep things managable for us upstream. If anything I would be more strict here, and systematically refuse bug reports upstream for any package version older than the newest two, unless escalated by the downstream maintainers. Agreed In the long run I was thinking about a built in reporting tool that would report only the information we need, directly to our issue tracker ( anonymously without the need for an login account, what I dubbed "drive by reporting" ) and label bugs based on information from os-release that would be sent with that report and minimize any communication from upstream to downstream bug trackers since it wastes time ( #1228909 on bz.rh.com is prime example of unwanted, unneeded distraction from downstream, what I call contributors time waster which is why I stepped in and try to close that report to no prevail. ). I expected downstream package maintainers to have their own account and be part of this community and participating with us ( as is to be expected of downstream maintainers ) anyway first we need the infrastructure for that in place so I was keeping that information to myself ( as I'm doing with few other ideas ) until we have had sorted that out. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 so I need D-Bus API for that. I think that it would be beneficial if systemd was able to create unit files on-the-fly using through D-Bus method call. You can do that already, in the concept of "transient" units. However, these units are not persistent, they are stored in /run and go away on reboots. Google for the StartTransientUnit() bus call for details. I think it would be a good idea to also allow to create persisent units in a similar way eventually. However, that's not as obvious and easy as it sounds, it starts from the question where to store those units. Cron-like semantics would suggest somewhere below /var, but that means they aren't available at early boot, and we'd have to reload the configuration and requeue all jobs when /var appears. Which means we'd have to put them in /etc instead, which however is suboptimal for many usecases I think I'd be willing to merge a patch that adds adds a new bus call CreatePersistentUnit() that works like StartTransientUnit() except that it only creates but not starts a unit, and that it stores the unit in /etc. (Note: the only reason StartTransientUnit() not only creates but also starts a unit is because the unit would otherwise be GC'ed away immediately and not be reconstructable after that...) I hate to say this since I'm against litter unit files across the entire filesystem like infective disease and administrator then have to run around trying to chase them down but is it not better to store this under /srv somewhere [1], not etc, so it wont conflicts with "Stateless Systems, Factory Reset, Golden Master" Systems? On top of that if this gets created under /etc it's a free for all for administers to tinker with. Arguably supporting this et all or supporting this without forcefully having to bind those timer units with an existing type service unit is a mistake so it might just be better to direct them to install and use cron instead and have cockpit drop a snippet into /etc/cron.d and the likes instead Jakub,Stephen what's the end game with this as in what kind of timer definitions do you expect administrator be doing and support from the cockpit UI? 1. http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 capable and we really just want to have a decent UI for people to manipulate them. Cockpit seems like a good place since it already does management of a lot of other systemd functionality for Fedora Server. If you have specific questions or concerns with that design, we'd love to hear them. Timers are not suited to all administrated tasks ( only the ones that relate to bootup,hardware and daemons ) and you seem to have fallen into the trap of taking the cron concept and start applying it to timers ( as opposed to simply continue to use cron ) when it's not the same thing, ( to me it is the same as you take the run level concept and apply it to systemd boot targets and think that it's the same thing) and what's describe there on that story page is something that cron is better suited to handle ( and probably much easier to implement as well ). Now as I mentioned before you need to bind every timer unit that get's created with the relevant service running on the host. so when a daemon is started or stopped or even uninstalled ( think for example postgresql + postgresql backup timer service ) , or device appears then disappears the relevant timer unit is stopped in the process however timer units are not suitable for end user tasks ( which are the only thing that is listed there on that story page ). As I mentioned on numerous occasion when I was driving the cron to timer migration effort in Fedora that timers and cron are solution that complement each other not replace each other, which why the cron jobs to be migrated to native times units was limited to roughly half of the total of shipped cron jobs in the distribution. I guess the best way for you to realize this is to set up a batch server with 20, 50 or hundreds of timer units and maintain it and you will quickly understand timers shortcomings and why they should not be used for end users usecase like the ones on that story page. You most certainly can make administrators life more hell by using timers for all usecases, just like you can drive on the wrong side of the road but you shouldn't. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
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 is, then either github is actually prety bad, or I am too stuck in my bugzilla mindset and haven't really grokked the github way of doing things yet. If you want good review tool, why not use gerrit? We do not have the resources to maintain our own infrastructure. In term of manpower we have 452 code contributors and 1170 members subscribed to this list. Then there are several means to fund that infrastructure so could you please clarify how you come to this conclusion that we are short on resources? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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. And if it is, then either github is actually prety bad, or I am too stuck in my bugzilla mindset and haven't really grokked the github way of doing things yet. If you want good review tool, why not use gerrit? We do not have the resources to maintain our own infrastructure. In term of manpower we have 452 code contributors and 1170 members subscribed to this list. Then there are several means to fund that infrastructure so could you please clarify how you come to this conclusion that we are short on resources? "lurkers" and "admins who are committed to continously run services for us for free over years" are quite different things. Also, systemd is not an organization, we are just some losely affiliated hackers. We have no budget, we have no money, we cannot employ anyone, and we have zero intention to change that and acquire budget/money/administration. o_O 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 consolidation and call systemd the modern building block of an OS ( which arguably means this is second component to the Linux kernel ) and sell distribution and companies that it should be what they rely on? All these years we have work hard on all distribution and embedded switch to us, rely on us and when push comes to shove we go "meh" we have no intention to go to the next level to properly support you? Am I the only one here that feels any obligation and responsibility to our downstream consumers? I need a drink... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 my colleagues. That said, there still may be some value in enabling the creation of new timer units for these purposes. (For example, there may be timers that are only useful if two normally-unrelated services are installed, so neither one would be likely to ship such a timer in their package, even disabled). But it's hard to say whether that's worth designing for or solving by shipping additional packages with helper units. Now that I see that you have started to understand what I tried to convey when running that cron to timer migration but failed miserably in doings so, going to say that value is an illusion Ithrow in another ( real life ) example to complex matters further. Let's use this drupal related cron job as an example "|0 * * * * wget -O - -q -t 1 http://www.example.com/cron.php";| that many will be familiar with which you would migrate to native systemd timers. Shipping this with drupal cannot be done since you cannot bind that to a specific web server ( the installed server might be apache, might be lighthttp or might be nginx etc ) not binding it to the web server will keep this timer unit running with all it downside once the administrator shuts down the webserver ( as happens currently with cron ). What I'm trying to emphasize here there exist only one to one mapping with each service ( or target ) and timer unit and those two things need to be bound together. With my former cron to timer feature and serverWG hat on, what I would propose and do which is quite the opposite from what you propose here is have all components ship their cron job in a separated sub-package ( those are mostly crap anyway ) then design the cockpit UI in such manner that dissociates cron job and uses generic term like for example "scheduled task" which covers both solution and whatever the future might bring and offers the user to create an arbitrary task ( which would use cron and have screen(s) tailored to that and create and associate task to an service ( with screen(s) tailored to that which would use timers ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
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 >consolidation and call systemd the modern building block of an OS ( which >arguably means this is second component to the Linux kernel ) and sell >distribution and companies that it should be what they rely on? > >All these years we have work hard on all distribution and embedded switch to >us, rely on us and when push comes to shove we go "meh" we have no intention >to go to the next level to properly support you? Yeah, we have no intention to turn systemd into a company or foundation. Sorry. Is that a requirement? Can we not survive through funds and donation? As far as I know the linux kernel is neither an company nor a foundation and somehow they manage do they not? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 funds to the project. Thou you might feel things have been working so far I do not. Has it worked? yes barely, Could we do better? very much so. I feel that the community has been showing growth pain for quite sometime. patches sent to the mailinglist have gone unnoticed, unreviewed. bugs filed in bz.fd.o being poorly handled etc. That is why I started working ( a while back ) on finding suitable bug tracker, buying the systemd.community domain etc. with sole intent to offload work of developers ( and show up with proof of concept on one the hackfest to start this discussion for real ) The reason I'm being so persistent is because I believe this is the right course forward at this point in time to offload work from developers and for the growth and improvement of the project hence I should give it my best to try to see that through. Also I'm afraid that the move to github will not yield the result that is being sought and arguably is necessary ( most certainly not alone) on top of that people seem to have mixed feelings about it's process and workflows as well so deciding something like this behind closed door then simply announce it was not the right approach towards the community that is if the intend is truly to build,have and sustain a community but here we are. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
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 working so far. I do understand and am aware of the complication ( legal and otherwise social aspect of it etc ) involved with bringing funds to the project. Thou you might feel things have been working so far I do not. Has it worked? yes barely, Could we do better? very much so. I feel that the community has been showing growth pain for quite sometime. patches sent to the mailinglist have gone unnoticed, unreviewed. bugs filed in bz.fd.o being poorly handled etc. Creating a foundation isn't going to change this :) Arguably the foundation already exist but that foundation is not doing it's due dilligance so what alternative when dealing with the core/baseOS layer do we have? Fragmentation is not the way, that has been historically proven so again what alternative have been discussed in this regard on plumbers? After what 5 years is consolidation in sight or are people still thinking that layers is or should be about choice? That is why I started working ( a while back ) on finding suitable bug tracker, buying the systemd.community domain etc. with sole intent to offload work of developers ( and show up with proof of concept on one the hackfest to start this discussion for real ) The reason I'm being so persistent is because I believe this is the right course forward at this point in time to offload work from developers and for the growth and improvement of the project hence I should give it my best to try to see that through. Also I'm afraid that the move to github will not yield the result that is being sought and arguably is necessary ( most certainly not alone) on top of that people seem to have mixed feelings about it's process and workflows as well so deciding something like this behind closed door then simply announce it was not the right approach towards the community that is if the intend is truly to build,have and sustain a community but here we are. How about we try the github stuff for a while now and see how well it works, or does not work, and then iterate from there based on experience? We could implement this one the side and take from there ( evaluate ) since it's an --> addon <-- to already chosen path not replacement but since you ( by you I mean the the cabal since afaik you did not have personal involvement in choosing this ) chose this route ( without input from the community and it's committers code or otherwise ). I can wait patiently since it's curios for me to observe code walk into repository which is an addon rep of 4 millions and individuals expect that in a room full of 8 millions that they get heard and noticed and entering that venue willl solve all their problems ( if they manage to get noticed, it will answer quite old and by old I mean longer than the history of America and books will be written ) Yeah sure I can patiently accept that challenge to my intellect ( I waited what 2 years after me an Kay briefly touch this subject of community on one of the hackfest, arguably both of us slightly intoxicated and I dvelved and work on it ) and be amazed since last time I walked into a forest I could not see the lotus for the leaves but let's see if the Germans have answer to that, and joining a community of 8 millions, with 4 millions of repositories will get heads to turn and people suddenly notice and contribute and or review code in relevance to our community. I cant personally come to the conclusion that move to github will yield the increase that they expect but you seem too and the number is 452 contributors to beat, so how long period do you choose to see if that number increase/decrease before you are willing to judge if that move was a success or a failure? I'll put my money where my mouth is and put my "community growth" aside and say after this official move to a github, an community of 8 millions, the contribution number will not have increased over thousand in this community after a year! heck I owe you a case of Icelandic beer of your choosing if that number has reach over 500 after that month. If that number goes beyond 500 after three months, additional case plus a litre bottle of reykjavodka. If that number has passed the 750 after half a year, your kayak trip around this miserable erupting rock. If it passes the contribution mark of thousand after an year a dive in Silfra including gear!. However if my prediction hold true you fly over here and teach me to build a kayak ( since I have never built a kayak but you have, an knowledge I gladly would possess ). I have faith that I'm wright and you are w
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 handling of failing mounts during boot under systemd" This is not "Stricter" it is a change in default behaviour. This change is a shit idea, who do I shout at to get the behaviour modified to back to sensible ? The systemd community only recommends what downstream consumers of it should do but does not dictate or othewise decided anything how those consumers eventually decide to implement systemd so if you dont like how systemd is implemented in Debian you should voice your concerns with the Debian community. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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, on the whole my reaction is mixed, one thing however really pisses me off more than any other "5.6.1. Stricter handling of failing mounts during boot under systemd" This is not "Stricter" it is a change in default behaviour. This change is a shit idea, who do I shout at to get the behaviour modified to back to sensible ? The systemd community only recommends what downstream consumers of it should do but does not dictate or othewise decided anything how those consumers eventually decide to implement systemd so if you dont like how systemd is implemented in Debian you should voice your concerns with the Debian community. Ok Who writes/maintains the code that parses "nofail" in /etc/fstab ? Who writes/maintains the typical system boot code (whatever has replaced rc.sysinit) ? I suspect the answer to both is the systemd maintainers, in which case is this not the correct place to bitch about it ? util-linux ( see man mount ) is what provides the nofail option and I dont follow what you mean by getting the behaviour to modify it back to sensible since systemd does already do what is sensible to do and always has. The fact is systemd has no means in figuring out which file systems are crucial and which ones are not hence it has always done the safe thing and dropped users to the emergency target if device listed in fstab has not appeared after a period of time so administrators have had to tell systemd which ones they consider to be none crucial to the bootup process by adding nofail mount option to the relevant device entry in fstab so I'm not sure what the Debian community considers as "stricter handling of failing mounts during boot under systemd" since this has always been the case with systemd. Perhaps systemd's behaviour is different from one ( or all ) of the other initsystem(s) that exist in Debian and that's what this documentation entry is about but not about any changes to systemd itself. My advice to you is simply to add the nofail mount options to the device entries in fstab for devices you consider not being crucial to the bootup process and systemd will happily carry on your boot process without dropping you to the emergency target if that device is not available. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 established configurations systemd has changed here. Do you have any reliable way to determine which file systems are important and which ones can be skipped at bootup? What do you propose systemd should do if a device listed in fstab is not available at bootup and that device has not been flagged that it could be skipped? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 https://bugzilla.redhat.com/show_bug.cgi?id=1177819 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] grant users access to certain services only
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 that without resorting to using hacks like sudo or a suid binary? From a cursory look, the existing PolicyKit rules are too coarse grained for this. Correct. This is currently not supported. That said, we could open this up, as PolicyKit allows parameterizing actions. I'd be happy to take a patch for this, and I figure it wouldn't even be a particularly complex patch... (in lieu of a patch, submit a github RFE...) Should not the solution for this be tied to the user and group field mentioned in the unit so for example the postgresql type service unit contains... User=postgres Group=postgres Which would mean that the posgres user could start,stop,restart,reload the postgresql.service as well as any user that has been added to the postgres group? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/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 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 subpackages? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 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 conference due to wide variety of reasons so making decisions there without the input of those in the community that could not attend is disrespectful. Anyway what was the cause for the reevaluation in other words why did people change their mind in this regard? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 across all distribution so it does not matter if you are running Arch/Debian/Ubuntu/Fedora etc. the documentation and required actions are the same for the consumer. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 putting this kind of split into the upstream build system à la "make install-"? I brought this issue up during my talk and recommended that we (downstream distros) might collaborate on this so where possible we have more consistency across distros. Since systemd-devel is rather low-volume these days it seemed ok to have these discussions here. If Lennart would like to see it elsewhere, that's fine of course. But I actually value his feedback on this matter. Arguable there should be a neutral ground somewhere ( systemd-cross-distro list of some sort ) where distribution can collaborate on matters like this since there are other things that need to be discussed and need to be sorted out other than just splitting systemd into separated components. Unit files for various daemon and services, naming of component which can directly affect names of type units themselves, deprecation of environmental files in units ( not sure how or if they are used in Debian but in Fedora there exist /etc/sysconfig/foo files which have become obsoleted for daemon and service with the introduction of systemd ) cross distro collaboration of integration of wide variety of systemd components ( timer units, networkd etc ) so fourth and so on. Hopefully the outcome of broader discussion like that would result in mutual proposal where each participant distribution could present to their distribution for distro wide acceptance and integration. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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-list by Lennart himself, just use Google to find that statement in the archive I dont see to what relevance this being user list or development list is here. These are discussion about integration of the building block of the OS in downstream distribution which upstream should only be involved with for guidance. ( upstream should never be maintaining their own component in downstream distribution for obvious reasons ). and there is a need for separated collaborated git repository to prevent duplication of downstream work etc. why? To coordinate and oversee and collectively share work done between distribution integrating the relevant components in their distribution. Basically the same thing we ( we as in major distribution + few I personally never heard of ) did in 2011 with the exception that now Debian and Ubuntu have joined the party and we would have a shared git repository to use instead of everyone having one either on an individual level or distribution level. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 : [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. Please do that in a separate thread and don't hijack this one. Please discuss this downstream since downstream packaging is an downstream matter. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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? Because these aren't development related discussion this list was multiple times statet also as users-list by Lennart himself, just use Google to find that statement in the archive I dont see to what relevance this being user list or development list is here interesting - so what did you try to tell the world with "because these aren't development related discussion"? Last time I checked downstream distributions packaging problems is not upstream development discussions. you are just pissed off because you where not present at the conference and nobody asked you before talk aboput something - that's it - period I have you know I chose rather to pay for a ticket to be shared with individuals that could not afford it rather then participate in a conference where the community was being charge for reflecting on itself. It's an ethical thing feel free to contact Nils if you need confirmation of that. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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. This means we get accounting of the number of tasks per unit enabled by default. Effectively this turns on the "pids" cgroup controller for all units. According to the cgroups folks this is OK as this specific controller is not particularly costly. This means that by default "systemctl status" will show a "Tasks: " line then, showing the number of tasks in the service. cgtop will be more efficient, too, then. Arguably this should be called system instead of default for system wide settings where applicable ( you need to keep a clear distinction which option belongs where and what it affects ) Will people be able to disable this per type unit ( set "UnitTasksAccounting=yes/no" ) Users sets SystemTasksAccounting=yes in system.conf but turns off task accounting for b.service while while keeping it 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 default, and would like it to set to some value such 1024 out-of-the-box. This will mean that any service or scope created will by default be limited to 1024 tasks. This of course is a change from before that has the potential to break some daemons that maintain an excessive number of processes or threads. However, I think it's a much better choice to raise the limit for them, rather than stay unlimited for all services by default. I think 1024 is not particularly low, but also not particularly high. Note that the kernel by default limits the number of processes to 32K in total anyway. Should there not be two options "SystemTasksMax" which alters the kernel default limits and UnitTaskMax which controls the default value of per-unit ? c) In logind.conf I intend to add a TasksMax= setting that sets the number of tasks for user sessions, and overrides the systemd-wide setting for user scopes. It would also be set out-of-the-box, and default to something like 8K or so. (Note that this is very similar to setting RLIMIT_NPROC via /etc/security/limits.conf, but has the benefit of covering also suid binaries, being nicely queriable via systemctl status and controllable during runtime via "systemctl set-property" and so on) Should not this be SessionTasksMax= setting? to clearly disquince this from other task mask settings ( accommodated by SessionTasksAccounting= ) d) in systemd's own unit files we'll configure much lower settings by default, since we know how many tasks they require. Putting this altogether you have in systemd.conf something along the lines of # Enable/disable system wide task accounting SystemTasksAccounting=yes/no # Set system wide task limit SystemTasksMax=32768 # Enables/disable task accounting for type units UnitTasksAccounting=yes/no # Set type unit wide task limit UnitTaskMax=1024 # Enable/disable session task accounting SessionTasksAccounting=yes/no # Set session task limit SessionTasksMax=8000 For type units people could overwrite system wide defaults via [Unit] UnitTasksAccounting=yes/no UnitTaskMax=64 For sessions people could overwrite system wide defaults ( logind.conf ) via SessionTasksAccounting=yes/no SessionTasksMax=12000 Status needs to show the current usage and max available and daemon reload should issue a warning on or fail if the max value for type units and sessions is set higher than the value of system tasks Max JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 EnvironmentFiles= is a really non-sensical game of unnecessary indirection. The legacy sys initscripts in Fedora, more or less ( with the exception of very few corner cases which got solved via templates ) where just using environment files that resided under the /etc/sysconfig directory that contained options to match $FOO="Yes" or "No" or Options="Bar" which you override either via copy of the type unit file or via overwrite snippet. I personally never saw the reason why it existed in first place ( in that context ) and I'm not aware of any other usecase for it's existence and I have seen units in various upstreams repos' that contain that /etc/sysconfig Fedora/RedHat-ism which at the same time makes them incomparable with any other distro thus adds to the upstream/downstream burden of maintaining those unit file(s). If you are unaware of any other use case for it perhaps it's time to start looking into obsoleting it. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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="-D testserver" Apache: Include "conf/local/testserver.conf" and now you can use the same systemd-unit on a dozens of machines and include specific config snippets WITOUT touch the systemd-unit or *anything* else in the apache configuration You apparently did not read or grasp what I said earlier. This is something you do via unit overwrite configuration snipped in conjunction with your Apache configuration changes not in an environment file. perhaps it's time to start looking into obsoleting it don't get me wrong but you sound once again like seek for changes to break users configuration to later blame users why they did not fix which ain't broken You cannot be gotten right. The follow up cleanup process in Fedora that I needed to conduct after the unit migration was completed, would have among other things obsoleted and removed those Fedora/RedHat specific environment files since it became clear immediately at that time that they had been obsoleted. We would have done that immediately in F14/F15 when we started the migration work but we had other political issues surrounding systemd to deal with at that time without having to add the obsolete of those legacy sysv initscripts environment files that Redhat holds so dear. I even created specific git repository without that environment file entry's specific to Redhat so that unit I migrated could be reused and shared amongst other distributions at that time as well being more likely to be accepted upstreams ( of those atleast I was in contact with ) only wanted to maintain a single unit file but cross distribution compatibility and the importance of it is something you dont seem to be capable of grasping since the only use cases that matters is the one that is specific and relevant to you. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 be compared? You just create an configuration snipped that replaces the ExecStart line for the daemon in the unit file with startup options for the daemon which contains the options you want to change or copy/edit the full unit and replace it. In his sample case above where he's using ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND and the environment file /etc/sysconfig/httpd you would create an configuration snippet which contains "ExecStart=/usr/sbin/httpd -D testserver -D FOREGROUND" instead . The only reason I can think of why distributions decided to split configuration out of the legacy sys v initscripts to begin ( you used to just tweak it there ) is because the legacy sysv initscript had become such a mess that administrator ended up breaking them when they did but perhaps someone else posses the historic knowledge why distributions started doing that. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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]
After=nfs-ganesha-config.service
Requires=nfs-ganesha-config.service
[Service]
EnvironmentFile=-/run/sysconfig/ganesha
ExecStart=/usr/bin/ganesha.nfsd $OPTIONS ${EPOCH}
(But honestly, there's really no point in trying to dynamically
convert stuff into a file that is suitable for EnvironmentFile=. I
mean, if you want a shell script, then use a shell script, and invoke
that from the main daemon's ExecStart= line, and make it exec the real
daemon as last step. There's really no point in playing these
multi-service conversion games. Also /etc/sysconfig is a Redhatism
that should really go away, the whole concept is flawed. Adding a new
/run/sysconfig/ certainly makes that even worse.)
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 EnvironmentFiles= is a
really non-sensical game of unnecessary indirection.
I do think that overriding the complete ExecStart= line is usually
suboptimal and not what you want if you just want to pass additional
options to the daemon.
Maybe a good middle ground / recommendation for such daemons would be,
to ship a line
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 like Fedora could do a one-time migration of their
settings in /etc/sysconfig/foobar and drop the file after the upgrade.
This makes no sense.
Here you are just adding an extra line with no value on top of requiring
some form of standardize the $OPTS var name across daemons ( as opposed
to administrators simply change the value of the line directly ).
Best practice and the least amount of work for administrator ( both in
editing and for other administrators to keep taps on changes made by
others ) is to copy/edit the entire unit.
Lennart can better explain what value he saw in introducing those
snippets compared to that since he introduced them in the first place.
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 like Fedora could do a one-time migration of their settings in /etc/sysconfig/foobar and drop the file after the upgrade. This makes no sense. for you! What he proposed is redundant and adds an extra line to the unit file and in addition requires some distro's acceptance that upstream needs to be aware of when it creates the unit for it's daemon/service. His proposal [Unit] Description=Sample unit # Unesseray line added Environment=OPTS=FOO [Service] ExecStart=/path/to/daemon $OPTS [Install] WantedBy=multi-user.target VS standard without any environment entry and does not require upstream being aware of any standardization or lack there of in downstream distributions. [Unit] Description=Sample unit [Service] ExecStart=/path/to/daemon FOO [Install] WantedBy=multi-user.target By all means enlighten me the benefits of his proposal which makes sense and does not add unnecessary line to the type unit file along with the complexity it might bring ( think larger type units ). JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 realize you have the exact same chances with an environment entry line do you not? The options being used there could be deprecated in the daemon startup and for those daemon/services that are capable of reading their own configuration files ( and thus those environment lines are not applicable to ) are never changed on updates.. When an administrators makes a change to an configuration ( or in this case type unit ) he is stating that he's deviating from the distributions shipped defaults for that components and since there is no reliable way for a system to detect and determine manual changes in configuration, there is always the risk that an update will break running system ( the administrators made changes ) which is why the configuration files for a running daemon/service are saved as copy's and the administrator who has made the deviation is expected to review and apply those changes himself. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 additional environmental options added to them et all so adding an empty environmental line just for the sake of adding it makes even less sense, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 not trying to force others change their setups for no good reason Because environmental lines or files that are spesific to daemon startup ( not it's environment ) have no value being there in the first place none what so ever and I'm saying this after going through and migrate around 400 legacy sysv initscripts and inspecting about 200 more. They might have served some value in the legacy sysv initscripts since those where in the lines of hundreds ( the largest I migrated was about 800 - 900 lines long ) but for some reason distribution decided to move the OPT= or OPTIONS= from the sysv scripts and into their own specific environmental file instead ( you used to configure it directly in the initscript itself and upstream could just ship it like that regardless of the distribution most likely distribution did so due to the share size of those legacy sysv initscripts ). JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
