Re: [systemd-devel] Fastest way to dump last X Mo of logs from the journal ?
> On 24 Apr 2024, at 19:48, Etienne Champetier > wrote: > > Anyone have other ideas to do fast exports without having all logs in > memory or twice on disk ? Maybe base on time not size? Then you can use the --since option. Barry
Re: [systemd-devel] Losing old journal messages after "Journal header limits reached"
> On 31 Jan 2024, at 18:44, Vadim Zeitlin wrote: > > I'd like to understand why does this happen and, equally if not more > importantly, how to prevent it from happening and store more logs. What is that value of MaxRetentionSec= in journal.conf? Barry
Re: [systemd-devel] Permanently remove services
> On 18 Jan 2024, at 17:30, Morten Bo Johansen wrote: > > How do I get rid of them once and for all? Use systemctl mask? Barry
Re: [systemd-devel] Testing LogFilterPatterns= on user-level services
> On 12 Jan 2024, at 20:29, Farblos wrote: > > On 2024-01-12 18:51, Barry wrote: > >> The docs say this means discard any log that contains ritzelbimpf. >> See >> https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#LogFilterPatterns= >> >> <https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#LogFilterPatterns=> >> >> What where you expecting? > > Exactly that - that I do not have any messages from test.service > in the journal containing "ritzelbimpf". Yet the journal show > both the "ritzelbimpf" and the "foobarbaz" messages, as seen in > the journal excerpt from my initial post. Doh! You are right. It seems to not do what is documented. Barry > > Thanks. >
Re: [systemd-devel] Testing LogFilterPatterns= on user-level services
> On 12 Jan 2024, at 13:51, Farblos wrote: > > LogFilterPatterns=~ritzelbimpf The docs say this means discard any log that contains ritzelbimpf. See https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#LogFilterPatterns= What where you expecting? Barry
Re: [systemd-devel] Question regarding configuration of SystemMaxUse and SystemKeepFree
> On 1 Sep 2023, at 22:36, PureLinux Betriebsführung wrote: > > So my question is - is there any option to set a relative value/a percentage > for that values? Per default, it seems to be possible. So why not a user > defined percentage? How are you managing journal config? If you are using a tool like ansible, puppet etc, then you would calculate the value and put into a template. Barry
Re: [systemd-devel] Conditionally reload a service from another service
> On 31 Jul 2023, at 21:23, Ian Pilcher wrote: > > I have created service (along with an associated timer) that checks the > remaining life of a TLS certificate and retrieves an updated certificate > from Let's Encrypt if the remaining life is too short. Certbot already knows how to do this. It has a service and timer that renews the all certs and restarts httpd. You could see how certbot solves the problem or just use certbot if it suitable. Barry
Re: [systemd-devel] Random freeze at booting Fedora 38
> On 18 Jul 2023, at 13:37, Georges Leichtmann wrote: > > Hi, > > After upgrading Fedora 37 Workstation (which was fine) to Fedora 38 WS, I > see occasional (random) freezing when booting. The freeze occurs generally in > the screen where to select the user, where nothing is possible, only long > press on the power button to stop the computer. > > I join 2 screenshots from Logs with an error message. > > What's the meaning, and how to correct it. > > Thanks for your help (I amn't a technician, only a regular user) Suggest you ask on https://discussion.fedoraproject.org <https://discussion.fedoraproject.org/> that is where lots of poeple helpo users get support. Barry > > GL > 15-22-04.png>
Re: [systemd-devel] One shot service failure on Fedora 37
On 18 Apr 2023, at 14:54, Bill Steinberg wrote:"Directly" means *not using wrapper scripts.* You can put command line arguments in ExecStart.Is there a way to run a shell script in a systemd which runs this type of command: "eval $DCC_LIBEXEC/dccifd $DCCIFD_ARGS”. The Distributed Checksum Clearinghouses shell scripts end up running this command. I’d rather use their scripts directly instead of having to extract the necessary parts required for a systemd forking type.Yes. You do not need the eval.You do need to read the file that sets the env var using EnvironmentFile=.Then you can use ExecStart=${DDC_LIB}/ddcifd $DDCIFD_ARGSNote the use of {} in only one place.BarryOn Apr 18, 2023, at 12:02 AM, Mantas Mikulėnas wrote:On Tue, Apr 18, 2023, 02:59 Bill Steinberg <b...@ponusridge.com> wrote:Hi Barry,Thanks for the response. Answers inline below.On Apr 17, 2023, at 5:09 PM, Barry <ba...@barrys-emacs.org> wrote:On 17 Apr 2023, at 19:05, Bill Steinberg <b...@ponusridge.com> wrote:Hello systemd devel,I have a systemd service that I’ve run on prior versions of fedora which fails to start via systemd on Fedora release 37. It is a oneshot service that starts the distributed checksum clearing house’s dccifd service via a shell script. Here is the definition of the service:[Unit]Description=Distributed Checksum Clearinghouses dccifd daemonAfter=syslog.target network.target[Service]Type=oneshotOneshot seems wrong.RemainAfterExit=yesExecStart=/var/dcc/libexec/rcDCC -m dccifd startDoes this run a background daemon?Yes, the rcDCC shell script starts and runs a linux executable, a background daemon as you call it.A "background daemon" is just Type=forking.Can you just run that daemon directly?I could run the shell script directly to start the dccifd executable however if the fedora linux server is rebooted I would need to remember to run the shell script manually. I’d like the dccifd daemon to start automatically when the fedora linux server is started. Isn’t systemd meant for this?"Directly" means *not using wrapper scripts.* You can put command line arguments in ExecStart.Hopefully that program can be run without demonising.ExecStop=/var/dcc/libexec/rcDCC -m dccifd stopIf it is oneshot it does not need a stopIs there another type that should be used besides oneshot? I may want to run systemctl stop dccifd.service, for example when dccifd is being upgraded to a new version.The dccifd executable is started and stopped using a shell script. It is not run directly. One reason is that the shell script contains the arguments that are passed to the dccifd linux executable.That's still just Type=forking.Make sure the script `exec`s the main process rather than spawning it underneath as usual.But why put those arguments in a shell script? Isn't systemd meant for this?Restart=no[Install]WantedBy=multi-user.targetThe error in the journalctl log is:systemd[1]: Starting dccifd.service - Distributed Checksum Clearinghouses dccifddaemon…systemd[1]: dccifd.service: Main process exited, code=killed, status=11/SEGVsystemd[1]: dccifd.service: Failed with result 'signal’.systemd[1]: Failed to start dccifd.service - Distributed Checksum Clearinghouses dccifddaemon.The two scripts in ExecStart and ExecStop run successfully outside of systemd. Any info as to why systemd fails when executing these scripts would be appreciated.Best,Bill Steinberg
Re: [systemd-devel] One shot service failure on Fedora 37
> On 17 Apr 2023, at 19:05, Bill Steinberg wrote: > > Hello systemd devel, > > I have a systemd service that I’ve run on prior versions of fedora which > fails to start via systemd on Fedora release 37. It is a oneshot service that > starts the distributed checksum clearing house’s dccifd service via a shell > script. Here is the definition of the service: > > [Unit] > Description=Distributed Checksum Clearinghouses dccifd daemon > After=syslog.target network.target > > [Service] > Type=oneshot Oneshot seems wrong. > RemainAfterExit=yes > ExecStart=/var/dcc/libexec/rcDCC -m dccifd start Does this run a background daemon? Can you just run that daemon directly? Hopefully that program can be run without demonising. > ExecStop=/var/dcc/libexec/rcDCC -m dccifd stop If it is oneshot it does not need a stop > Restart=no > > [Install] > WantedBy=multi-user.target > > > The error in the journalctl log is: > > systemd[1]: Starting dccifd.service - Distributed Checksum Clearinghouses > dccifddaemon… > systemd[1]: dccifd.service: Main process exited, code=killed, status=11/SEGV > systemd[1]: dccifd.service: Failed with result 'signal’. > systemd[1]: Failed to start dccifd.service - Distributed Checksum > Clearinghouses dccifddaemon. > > The two scripts in ExecStart and ExecStop run successfully outside of > systemd. Any info as to why systemd fails when executing these scripts would > be appreciated. > > Best, > Bill Steinberg
Re: [systemd-devel] systemctl daemon-reexec forgets running services and starts everything new
> On 4 Apr 2023, at 09:33, Wasser, Erik wrote: > > Hello List, > > I'm posting this here because the official bugtracker at > https://github.com/systemd/systemd/issues accepts only reports for new > versions of systemd. This is a bug report for version 249. > > # Our problem # > > During a regular update of our container environment, `systemd` (and > the related packages libpam-systemd, libsystemd0, libudev1, > systemd-sysv and udev) were updated from `249.11-0ubuntu3.6` to > `249.11-0ubuntu3.7`. We're talking only about Ubuntu 22.04. Our Ubuntu > 20.04 is working fine with `systemctl daemon-reexec`. > > In my opinion, the update was not the problem because we've tried > downgrading and tried these versions: (current) `249.11-0ubuntu3.7`, > `249.11-0ubuntu3.6`, `249.11-0ubuntu3.4` and `249.11-0ubuntu3.3`. The > symptoms were the same. The last working version is version > `245.4-4ubuntu3.19`. > > # Symptoms # > > The `/var/lib/dpkg/info/systemd.postinst` executes a `systemctl > daemon-reexec` and that ended in a disaster. Seems it is a packaging issue that ubuntu or debian needs to help you with not systemd? Barry > It seems that `systemd` > is forgetting all it started children and tries to start nearly every > configured service again. Naturally, the old services are still > running, and the ports can't be opened twice and `systemd` won't give > up. Here are some(!) of the logfiles: > > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Starting Create Volatile > Files and Directories... > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: systemd-udevd.service: Found > left-over process 130 (systemd-udevd) in control group while starting > unit. Ignoring. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: This usually indicates > unclean termination of a previous run, or service implementation > deficiencies. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: systemd-udevd.service: Found > left-over process 31475 (systemd-udevd) in control group while > starting unit. Ignoring. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: This usually indicates > unclean termination of a previous run, or service implementation > deficiencies. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: systemd-udevd.service: Found > left-over process 31476 (systemd-udevd) in control group while > starting unit. Ignoring. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: This usually indicates > unclean termination of a previous run, or service implementation > deficiencies. > > And... > > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Reached target System > Initialization. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Daily apt download > activities. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Daily apt upgrade > and clean activities. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Daily dpkg database > backup timer. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Periodic ext4 Online > Metadata Check for All Filesystems. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Condition check resulted in > Discard unused blocks once a week being skipped. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Daily rotation of log files. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Daily man-db regeneration. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Message of the Day. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Clean PHP session > files every 30 mins. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Update the plocate > database daily. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Daily Cleanup of > Temporary Directories. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Reached target Basic System. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: System is tainted: cgroupsv1 > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Reached target Timer Units. > > And... > > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: atd.service: Found left-over > process 206 (atd) in control group while starting unit. Ignoring. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: This usually indicates > unclean termination of a previous run, or service implementation > deficiencies. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Starting Deferred execution > scheduler... > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: cron.service: Found > left-over process 164 (cron) in control group while starting unit. > Ignoring. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: This usually indicates > unclean termination of a previous run, or service implementation > deficiencies. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Regular background > program processing daemon. > Mar 31 12:51:39 FQDN_REDACTED systemd[1]: dbus.service: Found > left-over process 177 (dbus-daemon) in control gr
Re: [systemd-devel] how to let systemd hibernate start/stop the swap area?
> On 31 Mar 2023, at 00:51, Michael Chapman wrote: > > On Fri, 31 Mar 2023, Phillip Susi wrote: >> >> Michael Chapman writes: >> >>> What specifically is the difference between: >>> >>> * swap does not exist at all; >>> * swap is full of data that will not be swapped in for weeks or months; >> >> That's the wrong question. > > Nevertheless it was the question I was faced with. I had servers with a > huge amount of memory, a fair bit of swap, and ALL of that swap filled > with stuff that would need to be entirely swapped back in at some point at > a moments notice. > > The solution was simple: turn off swap. Now there was no "swap everything > back in" penalty, and since there was plenty of RAM anyway the change had > little impact on the behaviour of the rest of the system. If you want to run in ram only then you must turn off the kernel overcommit. Have you done that? If not then you risk processes getting SEGV signals. There is a lot of moving parts that affect the robustness of a big server. Swap is one of them that is important to allow efficient use of all the hardware resources. I work on servers with 400G of ram, but it is all used. Swap is a critical part of tuning the performance with the network heavy work load that disk I/O impacts. Barry >
[systemd-devel] network interface stuck in configuring
of the status commands unstuck networkd? The last event on the system was a dns update 2023-03-18 that includes these packages: ---> Package systemd.x86_64 251.13-5.fc37 will be upgraded ---> Package systemd.x86_64 251.13-6.fc37 will be an upgrade ---> Package systemd-boot-unsigned.x86_64 251.13-5.fc37 will be upgraded ---> Package systemd-boot-unsigned.x86_64 251.13-6.fc37 will be an upgrade ---> Package systemd-libs.x86_64 251.13-5.fc37 will be upgraded ---> Package systemd-libs.x86_64 251.13-6.fc37 will be an upgrade ---> Package systemd-networkd.x86_64 251.13-5.fc37 will be upgraded ---> Package systemd-networkd.x86_64 251.13-6.fc37 will be an upgrade ---> Package systemd-oomd-defaults.noarch 251.13-5.fc37 will be upgraded ---> Package systemd-oomd-defaults.noarch 251.13-6.fc37 will be an upgrade ---> Package systemd-pam.x86_64 251.13-5.fc37 will be upgraded ---> Package systemd-pam.x86_64 251.13-6.fc37 will be an upgrade ---> Package systemd-resolved.x86_64 251.13-5.fc37 will be upgraded ---> Package systemd-resolved.x86_64 251.13-6.fc37 will be an upgrade ---> Package systemd-rpm-macros.noarch 251.13-5.fc37 will be upgraded ---> Package systemd-rpm-macros.noarch 251.13-6.fc37 will be an upgrade ---> Package systemd-udev.x86_64 251.13-5.fc37 will be upgraded ---> Package systemd-udev.x86_64 251.13-6.fc37 will be an upgrade Why was the interface stuck in configuring? Barry
Re: [systemd-devel] mkosi dnf install packages failed
> On 17 Mar 2023, at 21:54, William Roberts wrote: > > I am on Fedora 37, I did a dnf up and rebooted to make sure that's not > the issue. > > With the mkosi from the pkg manager, I am getting: > mkosi > mkosi: error: unrecognized arguments: > --kernel-command-line-extra=systemd.crash_shell > systemd.log_level=debug > udev.log_level=info > systemd.journald.forward_to_console > systemd.journald.max_level_console=warning > systemd.mask=auditd > > Which reports as mkosi version 14 > mkosi --version > mkosi 14 > > I grabbed the current main and installed it > python3 -m pip install --user git+https://github.com/systemd/mkosi.git > > And when I run the mkosi command, I ensure its picking up the right one: > sudo -E $(which mkosi) > > And it seems to be building along, but then it gets to a point where > the packages are > being verified with dnf (see below). I am not really sure how to proceed. > > Thanks for any help. > Bill > > > xfsprogs-6.1.0-1.fc37.x86_64 > xkeyboard-config-2.36-3.fc37.noarch > xxhash-libs-0.8.1-3.fc37.x86_64 > xz-5.4.1-1.fc37.x86_64 > xz-libs-5.4.1-1.fc37.x86_64 > zchunk-libs-1.3.0-1.fc37.x86_64 > zlib-1.2.12-5.fc37.x86_64 > zsh-5.9-2.fc37.x86_64 > Failed: > NetworkManager-1:1.40.10-1.fc37.x86_64 > ca-certificates-2023.2.60-1.0.fc37.noarch dbus-broker-33-1.fc37.x86_64 > dhcp-server-12:4.4.3-4.P1.fc37.x86_64 dnsmasq-2.89-1.fc37.x86_64 > gdb-13.1-1.fc37.x86_64 groff-base-1.22.4-10.fc37.x86_64 > kexec-tools-2.0.25-1.fc37.x86_64 > libutempter-1.2.1-7.fc37.x86_64 polkit-121-4.fc37.x86_64 > rpm-4.18.0-1.fc37.x86_64 tpm2-tss-3.2.2-1.fc37.x86_64 > > Error: Transaction failed > ‣ Error: "dnf -y > --config=/home/test/systemd2/.mkosi.tmp5lla7668/dnf.conf --best > --allowerasing --releasever=37 > --installroot=/home/test/systemd2/.mkosi.tmp5lla7668/root > --setopt=keepcache=1 --setopt=install_weak_deps=0 > '--setopt=cachedir=/home/test/systemd2/mkosi.cache/fedora~37' > --setopt=reposdir= > --setopt=varsdir=/home/test/systemd2/.mkosi.tmp5lla7668/vars > --noplugins --nodocs install acl alsa-lib bash-completion btrfs-progs > compsize coreutils cryptsetup dhcp-server diffutils dnf dnsmasq > dosfstools dracut dracut-config-generic e2fsprogs f2fs-tools findutils > fuse gcc gdb glib2 glibc-minimal-langpack gnutls grep iproute > iproute-tc kbd kernel-core kernel-modules kexec-tools kmod less > libasan libbpf libcap-ng libcap-ng-utils libfido2 libgcrypt > libmicrohttpd libmnl libubsan libxcrypt libxkbcommon mtools nano > netcat nftables numactl-libs openssl pam passwd polkit popt procps-ng > python3 'python3dist(pefile)' qrencode quota rpm sed strace systemd > tpm2-tss tree util-linux util-linux valgrind vim-common > wireguard-tools xfsprogs zsh '(systemd-networkd if systemd)' > '(systemd-udev if systemd)'" returned non-zero exit code 1. > That is odd. Where is that "'(systemd-networkd if systemd)" coming from? I would suspect a package install script, mkosi logic, maybe dnf, but not systemd itself. Barry
Re: [systemd-devel] Extend systemd-resolved service to override DNS response
> On 15 Feb 2023, at 10:31, Aditya Sharma wrote: > > Hi Kevin, > > When the TTLs expire, those records in the cache become 'stale', and are > normally purged. Your request is to have an option in systemd-resolved to > *not* purge those records, but to continue serving them in case it is unable > to communicate with the configured recursive resolver(s). > > Sorry for the ambiguity. > What I meant was to keep serving the record after the resolvers are not > operational or during some outage. > We were thinking of an approach where we keep on serving the last known good > FQDNs even after the TTL has expired (only when we are unable to communicate > with the resolvers). For that, we need to intercept the DNS calls and > maintain some kind of local cache. So, wanted to understand how we can extend > systemd-resolved service to serve the purpose. I would be worried that breaking the TTL caching rules will create more problems then it solves. Isn't the underlying issue that you have unreliable DNS servers that are important to your application? Barry > > Thanks > Aditya > > > On Tue, 14 Feb 2023 at 16:46, Kevin P. Fleming > <mailto:lists.systemd-de...@kevin.km6g.us>> wrote: >> On Tue, Feb 14, 2023, at 04:04, Aditya Sharma wrote: >>> Hi Kevin, >>> >>> If what you mean is that you want to serve 'stale' records from a cache >>> when their TTLs have expired and the authoritative servers which provided >>> them are not reachable, that's something that a number of existing >>> recursive resolvers are able to do and it could be logical for >>> systemd-resolved to offer it too. >>> We are looking to prepare a solution similar to this, to serve back records >>> for FQDNs in case of timeout from the DNS server. >>> We want to understand how we can extend systemd-resolved to override >>> response from DNS server in case of timeouts/failures. >> >> Again, you need to be very specific in your request. >> >> systemd-resolved communicates with one or more recursive resolvers (what you >> are calling "DNS server", but that term is ambiguous). If those resolvers >> are not operational, systemd-resolved will continue serving records from its >> cache (if the cache is enabled), until their TTLs expire. >> >> When the TTLs expire, those records in the cache become 'stale', and are >> normally purged. Your request is to have an option in systemd-resolved to >> *not* purge those records, but to continue serving them in case it is unable >> to communicate with the configured recursive resolver(s). >> >> In your original message you referred to a 'negative response' from the "DNS >> server", but that's a completely different situation. >>
Re: [systemd-devel] mkosi Unable to locate embedded .linux section: Load Error
> On 20 Jan 2023, at 20:40, William Roberts wrote: > > On Thu, Jan 19, 2023 at 1:41 PM Barry wrote: >> >> >> >>>> On 19 Jan 2023, at 19:19, Roberts, William C >>>> wrote: >>> >>> >>> >>>> -Original Message- >>>> From: Roberts, William C >>>> Sent: Thursday, January 19, 2023 10:45 AM >>>> To: Lennart Poettering >>>> Cc: systemd-devel@lists.freedesktop.org >>>> Subject: RE: [systemd-devel] mkosi Unable to locate embedded .linux >>>> section: >>>> Load Error >>>> >>>> >>>> >>>>> -Original Message- >>>>> From: Lennart Poettering >>>>> Sent: Thursday, January 19, 2023 3:30 AM >>>>> To: Roberts, William C >>>>> Cc: systemd-devel@lists.freedesktop.org >>>>> Subject: Re: [systemd-devel] mkosi Unable to locate embedded .linux >>>>> section: >>>>> Load Error >>>>> >>>>> On Di, 17.01.23 20:09, Roberts, William C (william.c.robe...@intel.com) >>>> wrote: >>>>> >>>>>> I am on current main branch: >>>>>> 0eb635ef4bc1 (HEAD -> main, origin/main, origin/HEAD) units: don't >>>>>> install pcrphase-related units without gnu-efi >>>>>> >>>>>> And I cannot get the mkosi qemu to work, mkosi boot does work. It >>>>>> looks like it's not finding the relevant section to boot from the image: >>>>>> Unable to locate embedded .linux section: Load Error Failed to >>>>>> execute Ubuntu 22.04 LTS (22.04 (Jammy Jellyfish)) >>>>>> (\EFI\Linux\mkosi-ubuntu-5.15.0-58-generic.efi): Load Error >>>>> >>>>> (Note, older mkosi didn#t use the "ukify" infra to generate UKIs, and >>>>> there was a chance this would result in overlapping PE sections which >>>>> might be the issue here. but that's just a guess. please try current >>>>> mkosi git, and see if that works) >>>>> >>>>> (I guess most mkosi upstreams use fedora, not ubuntu, so this might be >>>>> less >>>>> tested) >>>> >>>> On mkosi commit 6332528, it used bootctl --root which seems to not be >>>> available On my Ubuntu 20.04 system (bootctl --version yields system 245) . >>>> I'll set up a Fedora machine and test there. >>> >>> Could anyone recommend a version of Fedora to test on, Ie should I pick 32, >>> 34, 37, etc? >> >> Use 37 its current and you can get support. >> Note fedora release only have support for a year, so 32 and 34 have been EOL >> for a while. >> >> Barry > > Ok so I installed F37, built systemd and ran mkosi, but it failed as well. > mkosi version 14 from package manager: > - dnf issues > - https://gist.github.com/williamcroberts/492f29132582aa363710878e85f7db13 > built from source (commit 6332528b0) > - dnf issues > - https://gist.github.com/williamcroberts/8923ac33413a448c737b6534f2a7c4c7 I guess you have to create an empty database to get things going? > mkosi-13 from package manager: > - failed to find meson (meson is installed and sudo env can see it) > - https://gist.github.com/williamcroberts/f2ace4cb3ab053b2d6ff547309b7b563 Check the PATH at the point in code it tries to run meson. Barry > > Any ideas? > > Thanks, > Bill >
Re: [systemd-devel] mkosi Unable to locate embedded .linux section: Load Error
> On 19 Jan 2023, at 19:19, Roberts, William C > wrote: > > > >> -Original Message- >> From: Roberts, William C >> Sent: Thursday, January 19, 2023 10:45 AM >> To: Lennart Poettering >> Cc: systemd-devel@lists.freedesktop.org >> Subject: RE: [systemd-devel] mkosi Unable to locate embedded .linux section: >> Load Error >> >> >> >>> -Original Message- >>> From: Lennart Poettering >>> Sent: Thursday, January 19, 2023 3:30 AM >>> To: Roberts, William C >>> Cc: systemd-devel@lists.freedesktop.org >>> Subject: Re: [systemd-devel] mkosi Unable to locate embedded .linux section: >>> Load Error >>> >>> On Di, 17.01.23 20:09, Roberts, William C (william.c.robe...@intel.com) >> wrote: >>> >>>> I am on current main branch: >>>> 0eb635ef4bc1 (HEAD -> main, origin/main, origin/HEAD) units: don't >>>> install pcrphase-related units without gnu-efi >>>> >>>> And I cannot get the mkosi qemu to work, mkosi boot does work. It >>>> looks like it's not finding the relevant section to boot from the image: >>>> Unable to locate embedded .linux section: Load Error Failed to >>>> execute Ubuntu 22.04 LTS (22.04 (Jammy Jellyfish)) >>>> (\EFI\Linux\mkosi-ubuntu-5.15.0-58-generic.efi): Load Error >>> >>> (Note, older mkosi didn#t use the "ukify" infra to generate UKIs, and >>> there was a chance this would result in overlapping PE sections which >>> might be the issue here. but that's just a guess. please try current >>> mkosi git, and see if that works) >>> >>> (I guess most mkosi upstreams use fedora, not ubuntu, so this might be >>> less >>> tested) >> >> On mkosi commit 6332528, it used bootctl --root which seems to not be >> available On my Ubuntu 20.04 system (bootctl --version yields system 245) . >> I'll set up a Fedora machine and test there. > > Could anyone recommend a version of Fedora to test on, Ie should I pick 32, > 34, 37, etc? Use 37 its current and you can get support. Note fedora release only have support for a year, so 32 and 34 have been EOL for a while. Barry >
Re: [systemd-devel] service dependencies
> On 10 Jan 2023, at 13:56, Markus Rathgeb wrote: > > > Thank you both for your replies and suggestions. > I assume this one is related: https://github.com/systemd/systemd/issues/1312 > And yes, I found a lot of posts about this, but no real solution. > > I will further read further details about 'Upholds' and 'PropagatesStopTo. > > The real use case I need to solve involves another service. > > test2 not only requires test1 but also test0. > So, test2 should only be actived if test1 and test0 are activated. > > The optimal solution IMHO does not require to change test0 or test1. As test2 > is the one with the requirements. > > I assume I can use WantedBy in the install section of test2, but this would > require that the service is enabled / installed and not only started (for my > use case okay, but IMHO not optimal). WantedBy may not do what you think, see systemd.unit man page. Note: WantedBy= and RequiredBy= are used in the [Install] section to create symlinks in .wants/ and .requires/ directories. They cannot be used directly as a unit configuration setting. Barry
Re: [systemd-devel] Issue with systemd / journalctl
> On 26 Dec 2022, at 14:02, syst...@sioban.net wrote: > > Hi, > > I'm sorry if I'm at the wrong place but I feel I have a big issue with > systemd and journalctl. > Basically I know no more journal logs since 24/10 and I have no real idea why. I would ask on a debian mailing list. They will know the detail of how rsyslog service is packaged. Its not systemd itself that is likely to be the source of the problem It will most likely be the service unit files that you have installed that need debugging. > > Here is the full story, if I'm at the wrong place, please tell me so. > > I've discovered I have an issue with systemd on my Debian server. I've seen > that some logging service don't want to start through systemd but the daemon > itself start without issues: > > > ❯ systemctl start rsyslog.service > > A dependency job for rsyslog.service failed. See 'journalctl -xe' for > > details. > > If I start manually rsyslogd, it's working: > > > ❯ /usr/sbin/rsyslogd > > ❯ ps awx | grep rsyslog > > 45995 ?Ssl0:00 /usr/sbin/rsyslogd > > So I tried to understand what's wrong with systemd. > > First, journalctl -xe shows only lines from 24 Oct, nothing recent. > > I've tried timedatectl to ensure the date is correct but got this message > > > ❯ timedatectl > > Failed to connect to bus: No such file or directory > > I've searched a lot on Internet and ended up running systemctl --failed > command and it shown many failed services: > > > ❯ systemctl --failed > > UNITLOAD ACTIVE SUBDESCRIPTION > > ● dbus.socket loaded failed failed D-Bus System Message > > Bus Socket > > ● syslog.socket loaded failed failed Syslog Socket > > ● systemd-fsckd.socketloaded failed failed fsck to fsckd > > communication Socket > > ● systemd-journald-audit.socket loaded failed failed Journal Audit Socket > > ● systemd-journald-dev-log.socket loaded failed failed Journal Socket > > (/dev/log) > > ● systemd-journald.socket loaded failed failed Journal Socket > > ● systemd-udevd-control.socketloaded failed failed udev Control Socket > > ● systemd-udevd-kernel.socket loaded failed failed udev Kernel Socket > > ● uuidd.socketloaded failed failed UUID daemon > > activation socket > > > > LOAD = Reflects whether the unit definition was properly loaded. > > ACTIVE = The high-level unit activation state, i.e. generalization of SUB. > > SUB= The low-level unit activation state, values depend on unit type. > > 9 loaded units listed. > > > I've re-installed systemd-sysv and rebooted, cleaned old journalctl entries > but same issues. Why do you need the sysv package on a systemd system at all? Barry > > Basically, I'm clueless here :/ If someone have an idea :D >
Re: [systemd-devel] systemd-cgtop doesn't show Input/Output
> On 6 Dec 2022, at 06:45, Vladimir Mokrozub wrote: > > Thank you, I added "systemd.unified_cgroup_hierarchy=1 " to the kernel's > command line and systemd-cgtop now shows Input/Output. > However, I ran into a problem with LXC containers after switching to unified > mode and though I managed to solve it, I'm worried that something else might > break in the future. > Is it safe to switch to v2 mode? Better question is this; Is it safe to stay on the legacy V1 with its missing features and no new development? At some point you will have to fix the issues if you depend on legacy v1 cgroups. The v1 support is being dropped from systemd at some point I think. Barry > > > > On Mon, Dec 5, 2022 at 4:16 PM Michal Koutný <mailto:mkou...@suse.com>> wrote: >> Hello. >> >> On Mon, Dec 05, 2022 at 09:38:18AM +0300, Vladimir Mokrozub >> mailto:mogaba2...@gmail.com>> wrote: >> > $ systemctl --version >> > systemd 245 (245.4-4ubuntu3.19) >> > +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP >> > +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN >> > +PCRE2 default-hierarchy=hybrid >>^^ >> Unless you override this on kernel cmdline, it means (blk)io controller >> is in v1 mode. >> >> > systemd-cgtop always has "-" in both Input/s and Output/s columns. There >> > are no spikes, even under a high disk load. >> > I was testing it with "dd if=/dev/sda of=/dev/null". Here's the output: >> > >> > Control GroupTasks %CPU Memory Input/s Output/s >> > / 214 101.5 3.7G -- >> > user.slice 15 99.6 2.9G -- >> > system.slice 97 0.4 95.4M -- >> >> 1) It won't have proper hierarchical behavior (thus no values for .slice >>units, cgtop defaults to depth of 3 thus you may not see the active >>leaves), >> 2) it won't charge writeback IO properly (just FYI, it's not relevant >>to your example). >> >> If you can, I'd suggest you to switch to the unified mode if you want >> hierarchical IO accounting. >> >> HTH, >> Michal
Re: [systemd-devel] can't start shell script in the background
> On 2 Dec 2022, at 14:56, Lentes, Bernd > wrote: > > [Service] > ExecStart=/root/skripte/dev_shm_inotifywait.sh > Type=exec > # ExecStart=/usr/bin/inotifywait "-e delete -d -o /var/log/monitordev_shm.log > -r --timefmt %d.%m.%Y-%H:%M:%S --format %w%f:%e:%T /dev/shm" > # Restart=always The Type= does not match how inotifywait is being run. You would need Type=fork (I think). But use Type=simple and remove the -d. With systemd its not necessary to use a "daemon" mode. Daemon mode is legacy in an systemd wolld and will just make maintaining the service harder then is necessary. Barry
Re: [systemd-devel] dependent services status
> On 17 Nov 2022, at 20:03, Ted Toth wrote: > > The comment about inotify was just an example, I understand that there > is a 'notify' service type but I'm not using it because of its > documented shortcomings. I thought using sd_notify would be all advantages. Service gets to set its state explicitly, no need for systemd to guess. What are the shortcomings you are referring to? Barry > > >> On Thu, Nov 17, 2022 at 11:34 AM Alvin Šipraga wrote: >> >> Hi Ted, >> >>> On Thu, Nov 17, 2022 at 08:52:00AM -0600, Ted Toth wrote: >>> I have a set of services that depend on each other however when >>> services are started and considered 'active' that does not necessarily >>> mean they are in a state that a dependent service requires them to be >>> in to operate properly (for example an inotify watch has been >>> established). systemd services, I think, have a substate, is there a >>> way I can set that to a custom value to indicate the services idea of >>> its own state? >> >> If you set Type=notify in the [Service] block of the service definition >> file, you can use the sd_notify(3) API: >> >> https://www.freedesktop.org/software/systemd/man/sd_notify.html >> >> Is that what you are looking for? >> >> Kind regards, >> Alvin >
Re: [systemd-devel] systemd-resolved/NetworkManager resolv.conf handling
> On 7 Nov 2022, at 10:24, Thomas HUMMEL wrote: > > > > On 11/6/22 22:30, Barry wrote: > > >> So a dirty hack is to replace /sbin/resolvconf with a script that >> does-the-right-thing. >> Uses resolvectl on the correct interface etc. But only when called by F5. > > Hello, > > thanks for your answer. > > I just do it manually for now. But maybe one could user NM dispatcher > mechanism to run resolvectl at the right time without touching resolvconf ? > This would still be a workaround though. I do not know enough about how that works. I use a hack that is not so hacky with my work VPN client. I pass --resolver /usr/local/override/resolvectl to the VPN client and its uses my command in a resolvectl way. There are config issues that I fix up locally coz IT ... Barry > > Thanks for your help > > -- > Thomas HUMMEL >
Re: [systemd-devel] systemd-resolved/NetworkManager resolv.conf handling
> On 2 Nov 2022, at 15:20, Thomas HUMMEL wrote:
>
> On 10/31/22 12:19, Petr Menšík wrote:
>
> Hello, thank you and Barry as well for your answers
>
>
>> I would suggest using strace to find what exactly it does and what it tries
>> to modify. I expect sources for that client are not available.
>
> Well, digging a little deeper, here's what I've found out:
>
> 1) in the default case (described in my initial post), i.e.
>
>/etc/resolv.conf symlinked to systemd-resolved
> /run/systemd/resolve/stub-resolv.conf
>no dns nor rc.manager directives in NM config
>no F5 client NM profile
>
> The vpn client:
>
>a) backs up /etc/resolv.conf to /etc/resolv.conf.fp-saved
>b) readlinks the symlink
>c) execve's /sbin/resolvconf providing nameservers (thus trying to play
> along with systemd-resolved) but on the wrong interface on my Fedora (eth0.f5
> instead of tun0) [besides with a deprecated and not used arg (-m)]
>
>execve("/sbin/resolvconf", ["/sbin/resolvconf", "-a", "eth0.f5", "-m 0"],
> 0x7ffd13bf8568 /* 30 vars */
So a dirty hack is to replace /sbin/resolvconf with a script that
does-the-right-thing.
Uses resolvectl on the correct interface etc. But only when called by F5.
Clearly F5 vpn software is in need of updating to support options for modern
linux.
Have you tried raising an issue with F5?
Barry
>
>d) set up tun0 interface and bring it up
>
> -> hence we end up with:
>
>a) /etc/resolv.conf.fp-saved as a regular file, copy of
> /run/systemd/resolve/stub-resolv.conf
>b) NM managed tun0 interface without and dns property in its profile nor
> any disk persistent profile
>c) unchanded /etc/resolv.conf (still linked to
> /run/systemd/resolve/stub-resolv.conf
>
> so, systemd-resolved not knowing about vpn nameservers and vpn nameresolution
> fails without workaround (like resolvectl dns adding the tun0 nameserver for
> instance)
>
> 2) with NM handling /etc/resolv.conf as a regular file, i.e.
>
> /etc symlink rm-ed
> dns=default
> rc.manager=file
>
> the F5 client consider it a 'legacy' setting and overwrite (which is wrong to
> me) NM managed /etc/resolv.conf regular file
>
> it restores it when stopped by copying back /etc/resolv.conf.fp-saved
>
> So, basically I'd say there are 2 bugs :
>
> 1) legacy handling which seems to consider pre-NM era legacy
> 2) resolvconf call when systemd-resolved is used (at least on Fedora)
>
> In any case, I don't understand why it does not set the NM profile ipv4.dns
> property, which would let much more chances for NM and/or resolved to work
>
> Anyway, this leaves 2 unanswered questions, the first of which was my initial
> one:
>
> 1) how could, when all resolv.conf-as-a-file-by-NM conf has been removed (by
> me) and symlink to stub has been restored (by me) systemd-resolved, with *no
> trace* of the vpn nameservers in its own /run/systemd/resolv/resolv.conf nor
> seemingly nowhere else, can be still aware of the vpn nameservers (as
> described in my initial post scenario) ?
>
> -> is there a persistent systemd-resolved cache on disk somewhere ?
>
> 2) when running resolvconf by hand (resolvconf ) providing specific
> interface specific nameservers (on stdin), it seems to update the **global**
> /run/systemd/resolve/resolv.conf (hence making those nameservers available
> for all interfaces ?)
>
> -> Is there any other place where the specific ns <-> interface is persited
> or stored or is this global updating all there is ?
>
> Thanks for your help
>
> --
> Thomas HUMMEL
>
Re: [systemd-devel] systemd-resolved/NetworkManager resolv.conf handling
> On 26 Oct 2022, at 20:17, Thomas HUMMEL wrote: > > Hello, > > I'm not sure if this is a systemd-resolved or NetworkManager question but it > involves both (I know Thomas HALLER is a member of this list too) > > on > > Fedora release 36 (Thirty Six) using the following kernel and packages > >5.19.16-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC > >systemd-250.8-1.fc36.x86_64 >systemd-resolved-250.8-1.fc36.x86_64 >NetworkManager-1.38.4-1.fc36.x86_64 > > I'm using a proprietary vpn client which does not seem to work very well with > systemd-resolved. As a matter of fact it seems to create a manual NM profile > which does not include dns properties and it seems to (try to) set > /etc/resolv.conf aside (F5 vpn linux client f5fpc for the record) > > Making it work is not the question here. I'm trying to understand how the 2 > nameservers it configures may end up in /run/systemd/resolve/resolv.conf (and > global systemd-resolved config as shown by resolvectl status) ONLY when I > switch from a non systemd-resolved config then back to a systemd-resolved > config Can you hook into the vpn client and intercept it doing the dns changes? I do that for the vpn client used a work to solve integration issues. In my case its a matter of the right options to use a wrapper around resolvectl that fixes things before calling the real resolvectl. Barry > > Here's exactly what I'm doing/experiencing: > > Starting from > > a) default NetworkManager config: > > # grep -iE 'dns|rc\.manager' NetworkManager.conf > # ls -l conf.d/ > total 0 > > b) systemd-resolved stub-resolv.conf mode: > > # ls -l /etc/resolv.conf > lrwxrwxrwx 1 root root 37 Oct 26 19:15 /etc/resolv.conf -> > /run/systemd/resolve/stub-resolv.conf > > and with (not linked from /etc/resolv.conf) : > > /run/systemd/resolve/resolve.conf following content: > > nameserver 192.168.1.1 > nameserver 2a01:cb00:7e1:3300:aa6a:bbff:fe6e:190 > search home > > matching my auto wireless NM profile > > 1) I start the vpn client > > obviously it does not work very well with systemd-resolved as I don't get > corresponding nameserver (10.33.1.2,10.33.1.3) anywhere and name resolution > does not work for corresponding zones > > /run/systemd/resolve/resolve.conf content has not changed > > 2) I stop the vpn client, and switch to the following setup > > # rm /etc/resolv.conf > rm: remove symbolic link '/etc/resolv.conf'? y > > # cat < /etc/NetworkManager/conf.d/foo.conf > > [main] > > dns=default > > rc.manager=file > > EOF > > # reboot > > -> after the reboot the /etc/resolv.conf link as been recreated : why ? > > (/run/systemd/resolve/resolv.conf hasn't changed, which seems normal to me) > > 3) I remove it again and reboot > > # rm /etc/resolv.conf > rm: remove symbolic link '/etc/resolv.conf'? y > > # reboot > > -> this time /etc/resolv.conf is as expected a regular file which content is > handled by NM: > > $ ls -l /etc/resolv.conf > -rw-r--r-- 1 root root 114 Oct 26 20:22 /etc/resolv.conf > $ cat /etc/resolv.conf > # Generated by NetworkManager > search home > nameserver 192.168.1.1 > nameserver 2a01:cb00:7e1:3300:aa6a:bbff:fe6e:190 > > > 4) I start the vpn client > > it wrote to /etc/resolv.conf (which seems wrong to me but is out of scope > here) > > $ cat /etc/resolv.conf > #F5 Networks Inc. :File modified by VPN process > search pasteur.fr home > nameserver 10.33.1.2 > nameserver 10.33.1.3 > > the 2 nameservers it provided do not appear in > /run/systemd/resolve/resolv.conf > > 6) I stop the vpn client switch back to my orgininal config, and reboot > > # rm /etc/NetworkManager/conf.d/foo.conf > rm: remove regular file '/etc/NetworkManager/conf.d/foo.conf'? y > > # rm /etc/resolv.conf > rm: remove regular file '/etc/resolv.conf'? y > > # ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf > > # reboot > > -> everything looks as expected > > 7) I start the vpn client > > -> its provided nameserver appear in /run/systemd/resolv/resolv.conf (and > resolution of related zones work) > > -> why ? Where does the info come from ? > > nameserver 10.33.1.2 > nameserver 10.33.1.3 > nameserver 192.168.1.1 > # Too many DNS servers configured, the following entries may be ignored. > nameserver 2a01:cb00:7e1:3300:aa6a:bbff:fe6e:190 > search pasteur.fr home > > Can you help me figure out what's happening or at least how can the behavior > seem to change with what seem a rollback to the initial state ? > > Thanks for your help > > -- > Thomas HUMMEL >
Re: [systemd-devel] limiting NFS activity
> On 17 Oct 2022, at 20:11, Weatherby,Gerard wrote: > > > We have a requirement to limit / throttle the IO activity to an NFS mount for > a particular system slice. I’m trying to use cgroups v2 > > Does IODeviceLatencyTargetSec work for NFS mounts? > > Does cgroups v2 support net_prio? Can I set it in a > /etc/systemd/system/*slice.d/*conf file? Maybe you can use traffic shaping? Barry
Re: [systemd-devel] Connect /usr/bin/init to docker container's STDOUT/STDIN
> On 30 Sep 2022, at 14:30, Nicola Mori wrote:
>
> # Save the long-running PID on file
> ps aux | grep "sleep infinity" | head -n 1 | awk '{ print $2 }' >
> /container-pipes-pid
echo $! >/container-pipes-pid
See man bash for $! definition.
Barry
Re: [systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?
> On 18 Sep 2022, at 13:08, Yuri Kanivetsky wrote: > > >> >>> $ ls -al >>> /usr/lib/systemd/user/multi-user.target.wants/infinite-tsukuyomi.service >>> lrwxrwxrwx 1 root root 29 Sep 18 08:45 >>> /usr/lib/systemd/user/multi-user.target.wants/infinite-tsukuyomi.service >>> -> ../infinite-tsukuyomi.service >>> >>> And rebooted the machine. The service didn't start. But starts >>> manually if I tell it to. Is there anything I'm missing here? >>> >> >> There is no multi-user.target for user systemd instances (nothing >> prevents you from creating one, but it does not exist by default). > > Good point. When I symlink it into > /usr/lib/systemd/user/default.target.wants it starts on boot. > > Also, I've created a simple perl server: > > https://gist.github.com/x-yuri/45f53c16a99337ba0716a988290491bd > > And if I put perl-server.socket and perl-server.service into > /usr/lib/systemd/user, and symlink perl-server.socket into > /usr/lib/systemd/user/sockets.target.wants, it autoactivates on boot. > > The confusing thing though is: > > $ systemctl --user is-enabled perl-server.socket > disabled Enabled does mean that it will or will not run. It means that it is wanted by the default target. Barry > > And the fact that enable/preset/disable create/remove symlinks in > ~/.config/systemd/user/sockets.target.wants. > > Which doesn't happen with a service (e.g. infinite-tsukuyomi) when the > service is in /usr/lib/systemd/user. > > Regards, > Yuri >
Re: [systemd-devel] systemd-nspawn container not starting on RHEL9.0
> On 10 Aug 2022, at 21:10, Lennart Poettering wrote: > > On Mi, 10.08.22 10:13, Thomas Archambault (t...@tparchambault.com) wrote: > >> Thank you again Lennart, and thx Kevin. >> >> That makes total sense, and accounts for the application's high level >> start-up delay which appears to be what we are stuck with if we are over >> xfs. Unfortunately, it's difficult to dictate to the client to change their >> fs type, consequently we can't develop / ship a tool with that baseline >> latency on our primary target platform (RHEL xx.) >> >> So the next obvious question would be, is XFS reflink support on the >> systemd-nspawn roadmap or actually, (and even better) has support been >> incorporated already in the latest and greatest src and I'm just behind the >> curve working with the older version of nspawn as shipped in RHEL90? >> >> I'm asking because according to the RHEL 9 docs >> (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/managing_file_systems/index#the-xfs-file-system_assembly_overview-of-available-file-systems) >> it's the current default fs and is configured for "Reflink-based file >> copies." > > We issue copy_file_range() syscall, which should do reflinks on xfs, > if it supports that. Question is if your kernel supports that too. I > have no experience with xfs though, no idea how xfs hooked up reflink > initially. And we never tested that really. I don't think outside RHEL > many people use xfs. Isn’t XFS the default for fedora server? Barry > > If you provide a more complete strace output, you should see the > copy_file_range() stuff there. > > Lennart > > -- > Lennart Poettering, Berlin >
Re: [systemd-devel] Waiting for network routes to appear
> On 15 Jun 2022, at 12:32, Kevin P. Fleming wrote: > > I've got a number of systems that use BIRD to learn the routes > available on their networks, and as a result some services on those > systems attempt to start up before the routes have been learned. If > those services attempt to make network connections (even just DNS > queries), they will fail, and that's unpleasant. To be robust why not make the services recover from network issues? Then you do not need to care about the routes. Of course you will need to know if services have outages. Even if a route was working at some point what do you do if the route goes down later? Barry > > I can't use existing systemd facilities to make these services wait, > because there's no mechanism available for BIRD to indicate that any > specific route has been learned, or a way to configure a service to > wait for a specific route. > > I'm considering just writing a smallish Python program which will > accept (via configuration) a list of routes, and will listen to > netlink to wait for all of those routes to appear. I'd then make my > services dependent on this service reporting success. However, since > networkd already listens to netlink, it would certainly be possible > for it to provide this facility in some way. > > If you'll pardon the analogy, I'm thinking of something like > RequiresMountsFor=, which makes service startup wait until mount units > have succeeded. Of course following this analogy we'd end up creating > the concept of a 'route unit', and I'm not sure that's really the > right thing to do here. > > Is it worth trying to design some way for networkd to provide this > facility? if not, I'll just continue down the road of doing this > outside of systemd proper. >
Re: [systemd-devel] MaxRetentionSec does not delete entries older than the specified time
> On 29 May 2022, at 12:36, baba wrote: > > - Mail original - > De: "Andrei Borzenkov" > >> In which case? Current active journal file gets archived when it is >> full. Retention policies apply only to these archived files. > > In the case where MaxRetentionSec=3day. > And what do you mean by full?. > There are size limits on the journal files. I think that is what is being referred to. See man journald.conf and the SystemMaxFileSize for example. Barry
Re: [systemd-devel] certificate and trust store feature for systemd
> On 25 May 2022, at 19:22, SCOTT FIELDS wrote: > > If you’re referring to files in /etc/pki, that’s not a management API, like > CAPI or CNG provides in Windows (and a like API in OSX). There are tools that you run that manage the files. Sorry I do not have the details in front of me. The tools are the API at least for trust store from what I recall when I set it up. > > There’s a keychain solution in Gnome (GNOME/Keyring) but not widely adopted > that I’ve seen. I use KDE and the kwallet is used in most apps I use. If there is an app in gnome that is not using the keyring then that a problem with the app surely, not the API? > > This just seems a good match to have available within systemd I do not speak for systemd, just curious about why you think this is needed. Barry > > From: Barry Scott mailto:ba...@barrys-emacs.org>> > Sent: Wednesday, May 25, 2022 1:16 PM > To: SCOTT FIELDS mailto:scott.fie...@kyndryl.com>> > Cc: systemd-devel@lists.freedesktop.org > <mailto:systemd-devel@lists.freedesktop.org> > Subject: [EXTERNAL] Re: [systemd-devel] certificate and trust store feature > for systemd > > On 25 May 2022, at 14:06, SCOTT FIELDS <mailto:scott.fie...@kyndryl.com>> wrote: I apologize for the very general > inquiry. Are there any plans to have system natively support its own trust > store for items like CAs, x509 certs, passwords & > > > > On 25 May 2022, at 14:06, SCOTT FIELDS <mailto:scott.fie...@kyndryl.com>> wrote: > > I apologize for the very general inquiry. > > Are there any plans to have system natively support its own trust store for > items like CAs, x509 certs, passwords & truststores akin to the keychain in > Windows and OS X? > > But these are solved problems on modern Linux systems aren't they? > > At least with RHEL and Fedora they have trust store and keychains. > > > > I still find the management of PKIs in /etc/pki to be problematic. > > For my home network I have my own DNS domain and CA setup. It was easy to add > the CA to > Fedora's trust store. > > > > Having this available as a core service within systemd using like APIs either > in (mostly deprecated) CAPI or the new CNG > > Barry > > > > > Scott Fields > IBM/Kyndryl > SRE – BNSF > 817-593-5038 (BNSF) > scott.fie...@kyndryl.com <mailto:scott.fie...@kyndryl.com> > scott.fie...@bnsf.com <mailto:scott.fie...@bnsf.com>
Re: [systemd-devel] certificate and trust store feature for systemd
> On 25 May 2022, at 14:06, SCOTT FIELDS wrote: > > I apologize for the very general inquiry. > > Are there any plans to have system natively support its own trust store for > items like CAs, x509 certs, passwords & truststores akin to the keychain in > Windows and OS X? But these are solved problems on modern Linux systems aren't they? At least with RHEL and Fedora they have trust store and keychains. > > I still find the management of PKIs in /etc/pki to be problematic. For my home network I have my own DNS domain and CA setup. It was easy to add the CA to Fedora's trust store. > > Having this available as a core service within systemd using like APIs either > in (mostly deprecated) CAPI or the new CNG Barry > > > Scott Fields > IBM/Kyndryl > SRE – BNSF > 817-593-5038 (BNSF) > scott.fie...@kyndryl.com <mailto:scott.fie...@kyndryl.com> > scott.fie...@bnsf.com <mailto:scott.fie...@bnsf.com>
Re: [systemd-devel] Antw: [EXT] [systemd‑devel] Query degraded state
> On 29 Apr 2022, at 07:06, Ulrich Windl > wrote: > > >> >>>> Barry Scott schrieb am 28.04.2022 um 17:03 in > Nachricht : >> Is there a command I can use to test for the degraded state? >> >> I could parsing the output of systemctl‑failed or >> syetemctl status but was looking for something less fragile. > > Do you mean "systemctl --state=failed list-units"? I use systemctl —failed Barry > >> >> Barry > > >
Re: [systemd-devel] Query degraded state
On 28/04/2022 16:15, Alvin Šipraga wrote: Hi, On Thu, Apr 28, 2022 at 04:03:01PM +0100, Barry Scott wrote: Is there a command I can use to test for the degraded state? I could parsing the output of systemctl-failed or syetemctl status but was looking for something less fragile. I think the correct way to do this programatically is via the dbus API, but if you want something moderately greppable, try: # systemctl show | grep SystemState SystemState=running Thanks that will work well in a bash script. I put off using dbus for a little longer :-) Barry Hope that helps. Kind regards, Alvin
[systemd-devel] Query degraded state
Is there a command I can use to test for the degraded state? I could parsing the output of systemctl-failed or syetemctl status but was looking for something less fragile. Barry
Re: [systemd-devel] Waiting for all jobs to finish
> On 28 Apr 2022, at 09:47, Lennart Poettering wrote: > > On Mi, 27.04.22 18:29, Barry Scott (ba...@barrys-emacs.org > <mailto:ba...@barrys-emacs.org>) wrote: > >> I have two target files that I use. >> >> prod.target is used to start up all the production services. >> When I use systemctl start prod.target it blocks until all the >> services are running. >> >> I also have prod-upgrade.target that is used to stop service >> via Conflicts=. When I use systemctl start prod-upgrade.target >> it returns immediately but there are stop jobs running. >> >> I believe that this is expected as all the services that need to >> be started have been. >> >> Is there a systemctl command that will wait for all the stop jobs >> without the need to poll for the systemctl list-jobs to be empty? > > There is not. > > But the correct way to solve this is by combining Conflicts= with an > order dep (After= or Before=). > > In systemd the ordering deps After=/Before= control three things: > > 1. The literally define the start-up order if two units are started, > i.e. this is the obvious case: if b.service has After=a.service > this means a.service has to finish startup first, before b.service > is started. > > 2. If two units are stopped they define the order too, but in > reverse. if b.service has After=a.service this hence means that if > both are shutdown, then b.service has to stop *before* a.service is > stopped, i.e. the opposite order of the start-up order. > > 3. If one unit is started and one is stopped then the existance of an > ordering dep means the stopped unit must complete stopping first, > before the starting of the other is initiated. Note that it doesn't > mattre if you set After= or Before= here, that doesn#t matter. What > matters is that you ordered the unit at all, regardless in which > direction. > > Now, this third rule is what matters here: if your target unit has > Conflicst= on some service, then the target unit should not enter > active state until the service fully shutdown. Thus you can place > After= *or* Before= between the two (your choice) and get the desired > behaviour. I'd have never reasoned my way to this solution. It work as you described. But only if I use After= as Before= got a cyclic deps error. Here is the pattern I now have: [Unit] Description=prod.target Wants=serv1.service After=serv1.service [Unit] Description=prod-upgrade.target Conflicts=prod.target Conflicts=serv1.service # Need a After= so that systemctl start prod-upgrade.target # will block until conflicting services have stopped After=serv1.service Barry > > Lennart > > -- > Lennart Poettering, Berlin
[systemd-devel] Waiting for all jobs to finish
I have two target files that I use. prod.target is used to start up all the production services. When I use systemctl start prod.target it blocks until all the services are running. I also have prod-upgrade.target that is used to stop service via Conflicts=. When I use systemctl start prod-upgrade.target it returns immediately but there are stop jobs running. I believe that this is expected as all the services that need to be started have been. Is there a systemctl command that will wait for all the stop jobs without the need to poll for the systemctl list-jobs to be empty? The pattern I'm implementing is to do this on a server upgrade: systemctl start prod-upgrade.target # need to wait for stop jobs to finish dnf update --refresh -y systemctl start prod.target Barry
Re: [systemd-devel] unable to attach pid to service delegated directory in unified mode after restart
> On 21 Feb 2022, at 21:16, Felip Moll wrote: > > > >> You could invoke a man:systemd-run for each new process. Than you can >> put every single job in a seperate .slice with its own >> man:systemd.resource-control applied. >> This would also mean that you don't need to compile against libsystemd. >> Just exec() accordingly if a systemd-system is detected. >> >> BR >> Silvio > > Silvio, > > As I commented in my previous post, creating every single job in a separate > slice is an overhead I cannot assume. > An HTC system could run thousands of jobs per second, and doing extra > fork+execs plus waiting for systemd to fill up its internal structures and > manage it all is a no-no. Are you assuming this or did you measure the cost? Barry > > One other option that I am thinking about is extending the parameters of a > unit file, for example adding a DelegateCgroupLeaf=yes option. > > DelegateCgroupLeaf=. If set to yes an extra directory will be created > into the unit cgroup to place the newly spawned service process. This is > useful for services which need to be restarted while its forked pids remain > in the cgroup and the service cgroup is not a leaf anymore. This option is > only valid when using Delegate=yes and under a system in unified mode. > > E.g. in my example, that would end up like this: > /sys/fs/cgroup/system.slices/sgamba1.service <-- This is Delegated=yes > DelegateMultiCgroups=yes > ├── sgamba1 <-- The spawned process would be always put in here by > systemd. > ├── user1_stuff > ├── user2_stuff > └── user3_stuff > > I think this idea could work for cases like the one exposed here, and I see > this would be quite useful. >
[systemd-devel] Add LUKS disk to an Raspberry Pi 4 install
[I originally ask this question on the Fedora ARM list, but got no reply]
I'm trying to build a RPi4 system that uses a LUKS encrypted disk.
But I cannot get the volume to be unlocked when the system boots.
I have installed Fedora-Minimal-34-1.2.aarch64.raw.xz to with
arm-image-installer --target=rpi4 and that boots.
Then I have added a new partition to that sdcard that I setup using this
command on a Fedora 34 x86_86 system.
cryptsetup \
--type luks2 \
--cipher xchacha20,aes-adiantum-plain64 \
--hash sha256 \
--iter-time 5000 \
--pbkdf argon2i \
luksFormat ${DEVICE}
I got these settings from a blog on setting up LUKS for debian on raspberry
pi.
I add an entry to /etc/crypttab for the volume.
When I boot the system I am not prompted for the password to unlock the
volume as I was expecting.
Looking in journalctl -b 0 I see these lines:
Apr 06 01:01:36 clef.chelsea.private systemd[1]: dev-disk-
by\x2duuid-8c2519ae\x2d78a9\x2d44b0\x2d871f\x2d0aa2422de03a.device: Job dev-
disk-by\x2duuid-8c2519ae\x2d78a9\x2d44b0\x2d871f\x2d0aa2422de03a.device/start
timed out.
Apr 06 01:01:36 clef.chelsea.private systemd[1]: Timed out waiting for device
/dev/disk/by-uuid/8c2519ae-78a9-44b0-871f-0aa2422de03a.
Apr 06 01:01:36 clef.chelsea.private systemd[1]: Dependency failed for
Cryptography Setup for clef-root.
Apr 06 01:01:36 clef.chelsea.private systemd[1]: Dependency failed for Local
Encrypted Volumes.
Once I login I can open the volume and mount it
$ cryptsetup luksOpen /dev/mmcblk0p4 clef-root
$ mount /dev/mapper/clef-root /mnt
I have tried updating the initrd with:
dracut --force.
And also adding to the kernel command line:
# cat /proc/cmdline
BOOT_IMAGE=(hd0,msdos2)/vmlinuz-5.11.12-300.fc34.aarch64
root=UUID=67ca2085-9dab-405b-a042-ff6269816fbc ro rhgb quiet console=tty0
rd.luks.uuid=8c2519ae-78a9-44b0-871f-0aa2422de03a
I have a other systems that use full disk encryption that work. But I have
failed to spot the difference between the RPi config and the working systems
config.
Do you know what is missing or not configured?
Hmm, just noticed that the kernel command says console is tty0.
But when I log in on the console its tty1.
Barry
Re: [systemd-devel] Xorg or Wayland Environment
> On 19 Sep 2021, at 14:48, Ed Greshko wrote: > > > On 19/09/2021 21:39, Michael Biebl wrote: >> A useful command in this context is >> >> systemctl --user show-environment > > OK, that was helpful. But leads to another question. > > How to run the service only if KDE_FULL_SESSION=true? Use ExecCondition to do the test I think. https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecCondition= Barry > > >> >> Am So., 19. Sept. 2021 um 11:53 Uhr schrieb Mantas Mikulėnas >> : >>>> On Sun, Sep 19, 2021 at 4:05 AM Ed Greshko wrote: >>>> Not a everyday systemd service writer >>>> >>>> I've written a user service file to start an app on login. It works well >>>> for Xorg with Environment=DISPLAY=:0. >>>> >>>> But I've found that under Wayland the DISPLAY=:1 after a logout of Xorg >>>> and login to a >>>> Wayland session. >>>> >>>> What would be the proper way to get the DISPLAY environment varible use it >>>> as opposed >>>> to "hard" coding it? >>> >>> The proper way is to have the desktop environment upload DISPLAY (and >>> whatever else is relevant, such as XAUTHORITY or WAYLAND_DISPLAY or >>> XDG_SESSION_TYPE) into systemd --user, so that it would be automatically >>> available to your service without doing anything special. >>> >>> For example, gnome-session does this for GNOME (it calls systemd's >>> UnsetAndSetEnvironment in gsm-util.c), and >>> /etc/X11/xinit/xinitrc.d/50-systemd-user.sh handles the bare minimum for >>> other Xorg-based desktops (when startx is used). >>> >>> If KDE integrates with systemd --user in any way (i.e. if it actually has a >>> "plasma-core.target" that you mention), I'd really expect it to do the same >>> before it tries to start its own targets, otherwise they would be kind of >>> useless. >>> >>> -- >>> Mantas Mikulėnas >
Re: [systemd-devel] Xorg or Wayland Environment
> On 19 Sep 2021, at 14:48, Ed Greshko wrote: > > > On 19/09/2021 21:39, Michael Biebl wrote: >> A useful command in this context is >> >> systemctl --user show-environment > > OK, that was helpful. But leads to another question. > > How to run the service only if KDE_FULL_SESSION=true? Have the service run a script that checks the env var before starting the app? Barry > >> >> Am So., 19. Sept. 2021 um 11:53 Uhr schrieb Mantas Mikulėnas >> : >>>> On Sun, Sep 19, 2021 at 4:05 AM Ed Greshko wrote: >>>> Not a everyday systemd service writer >>>> >>>> I've written a user service file to start an app on login. It works well >>>> for Xorg with Environment=DISPLAY=:0. >>>> >>>> But I've found that under Wayland the DISPLAY=:1 after a logout of Xorg >>>> and login to a >>>> Wayland session. >>>> >>>> What would be the proper way to get the DISPLAY environment varible use it >>>> as opposed >>>> to "hard" coding it? >>> >>> The proper way is to have the desktop environment upload DISPLAY (and >>> whatever else is relevant, such as XAUTHORITY or WAYLAND_DISPLAY or >>> XDG_SESSION_TYPE) into systemd --user, so that it would be automatically >>> available to your service without doing anything special. >>> >>> For example, gnome-session does this for GNOME (it calls systemd's >>> UnsetAndSetEnvironment in gsm-util.c), and >>> /etc/X11/xinit/xinitrc.d/50-systemd-user.sh handles the bare minimum for >>> other Xorg-based desktops (when startx is used). >>> >>> If KDE integrates with systemd --user in any way (i.e. if it actually has a >>> "plasma-core.target" that you mention), I'd really expect it to do the same >>> before it tries to start its own targets, otherwise they would be kind of >>> useless. >>> >>> -- >>> Mantas Mikulėnas >
Re: [systemd-devel] Exception safety od sd-bus
> On 22 Jul 2021, at 13:04, Stanislav Angelovič wrote: > > > Hi guys! > > Assuming sd-bus is used in a C++ application, is sd-bus safe against > exceptions flying from e.g. a sd-bus vtable callback handler (provided by the > C++ application) and catching them in the caller of sd_bus_process() (which > is the same C++ app)? > > Or this is not supported (so leaks or whatever obscure situations may happen > then)? I though that Systemd is written in C so it will not know what an exception is. You will need to code your C++ accordingly. Prevent exceptions escaping from any call back function. And remember that your call back functions need to use external “C” declaration. Barry > Thanks, > > Stanislav Angelovič. > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-ask-password causes systemd to use very high CPU
Is there any work around that I can use? Barry > On 23 Jan 2021, at 14:32, Barry Scott wrote: > > I opened this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1919538 > <https://bugzilla.redhat.com/show_bug.cgi?id=1919538> > > I'd love to know if there is a work around until you have time to make a fix. > > Barry > > > >> On 16 Jan 2021, at 15:42, Barry Scott > <mailto:ba...@barrys-emacs.org>> wrote: >> >> I have a reproducible problem with systemd-ask-password. >> >> # rpm -q systemd >> systemd-246.7-2.fc33.x86_64 >> >> 1. boot fedora 33 >> 2. login to KDE >> 3. start a terminal and run top >> 4. start a terminal and run: >> systemctl >before >> systemd-ask-password 'testing: ' p >> 5. Observe that top is showing systemd using ~80% CPU >> 6. stop systemd-ask-password and CPU returns to idle >> systemctl >after >> 7. Check journal: >> >> Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted >> in Forward Password Requests to Plymouth being skipped. >> Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted >> in Forward Password Requests to Plymouth being skipped. >> Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted >> in Forward Password Requests to Plymouth being skipped. >> Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted >> in Forward Password Requests to Plymouth being skipped. >> Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted >> in Forward Password Requests to Plymouth being skipped. >> Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted >> in Forward Password Requests to Plymouth being skipped. >> etc... >> >> # journalctl -b | grep Condition | wc -l >> 37555 >> >> 8. run again: >> systemd-ask-password 'testing: ' p >> 9. messgae sent to all terminals: >> Broadcast message from root@vmf33.chelsea.private >> <mailto:root@vmf33.chelsea.private> (Sat 2021-01-16 15:28:02 GMT): >> >> Password entry required for 'testing:' (PID 1862). >> Please enter password with the systemd-tty-ask-password-agent tool. >> >> - >> >> Looking at the services before and after running systemd-ask-password once I >> see this diff: >> >> # diff -u before after | grep '^[-+]' >> --- before 2021-01-16 15:35:51.850438282 + >> +++ after 2021-01-16 15:36:08.875736785 + >> - systemd-ask-password-plymouth.path >>loaded active waiting Forward Password >> Requests to Plymouth Directory Watch >> >> - systemd-ask-password-wall.path >>loaded active waiting Forward Password >> Requests to Wall Directory Watch >> >> + systemd-ask-password-wall.path >>loaded active running Forward Password >> Requests to Wall Directory Watch >> >> - fprintd.service >>loaded active running Fingerprint >> Authentication Daemon >> >> + systemd-ask-password-wall.service >>loaded active running Forward Password >> Requests to Wall >> >> -196 loaded units listed. Pass --all to see loaded but inactive units, too. >> +195 loaded units listed. Pass --all to see loaded but inactive units, too. >> >> I am seeing this behaviour on two systems. A dell laptop and a VMware VM. >> >> Is there anything I can do to help debug this? >> Or just raise a big report? >> >> What work around would you suggest I use until this is fixed? >> >> Barry >> >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> <mailto:systemd-devel@lists.freedesktop.org> >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel >> > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-ask-password causes systemd to use very high CPU
I opened this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1919538 <https://bugzilla.redhat.com/show_bug.cgi?id=1919538> I'd love to know if there is a work around until you have time to make a fix. Barry > On 16 Jan 2021, at 15:42, Barry Scott wrote: > > I have a reproducible problem with systemd-ask-password. > > # rpm -q systemd > systemd-246.7-2.fc33.x86_64 > > 1. boot fedora 33 > 2. login to KDE > 3. start a terminal and run top > 4. start a terminal and run: > systemctl >before > systemd-ask-password 'testing: ' p > 5. Observe that top is showing systemd using ~80% CPU > 6. stop systemd-ask-password and CPU returns to idle > systemctl >after > 7. Check journal: > > Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted in > Forward Password Requests to Plymouth being skipped. > Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted in > Forward Password Requests to Plymouth being skipped. > Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted in > Forward Password Requests to Plymouth being skipped. > Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted in > Forward Password Requests to Plymouth being skipped. > Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted in > Forward Password Requests to Plymouth being skipped. > Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted in > Forward Password Requests to Plymouth being skipped. > etc... > > # journalctl -b | grep Condition | wc -l > 37555 > > 8. run again: > systemd-ask-password 'testing: ' p > 9. messgae sent to all terminals: > Broadcast message from root@vmf33.chelsea.private (Sat 2021-01-16 15:28:02 > GMT): > > Password entry required for 'testing:' (PID 1862). > Please enter password with the systemd-tty-ask-password-agent tool. > > - > > Looking at the services before and after running systemd-ask-password once I > see this diff: > > # diff -u before after | grep '^[-+]' > --- before 2021-01-16 15:35:51.850438282 + > +++ after 2021-01-16 15:36:08.875736785 + > - systemd-ask-password-plymouth.path > loaded active waiting Forward Password > Requests to Plymouth Directory Watch > > - systemd-ask-password-wall.path > loaded active waiting Forward Password > Requests to Wall Directory Watch > > + systemd-ask-password-wall.path > loaded active running Forward Password > Requests to Wall Directory Watch > > - fprintd.service > loaded active running Fingerprint > Authentication Daemon > > + systemd-ask-password-wall.service > loaded active running Forward Password > Requests to Wall > > -196 loaded units listed. Pass --all to see loaded but inactive units, too. > +195 loaded units listed. Pass --all to see loaded but inactive units, too. > > I am seeing this behaviour on two systems. A dell laptop and a VMware VM. > > Is there anything I can do to help debug this? > Or just raise a big report? > > What work around would you suggest I use until this is fixed? > > Barry > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-ask-password causes systemd to use very high CPU
I have a reproducible problem with systemd-ask-password. # rpm -q systemd systemd-246.7-2.fc33.x86_64 1. boot fedora 33 2. login to KDE 3. start a terminal and run top 4. start a terminal and run: systemctl >before systemd-ask-password 'testing: ' p 5. Observe that top is showing systemd using ~80% CPU 6. stop systemd-ask-password and CPU returns to idle systemctl >after 7. Check journal: Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted in Forward Password Requests to Plymouth being skipped. Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted in Forward Password Requests to Plymouth being skipped. Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted in Forward Password Requests to Plymouth being skipped. Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted in Forward Password Requests to Plymouth being skipped. Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted in Forward Password Requests to Plymouth being skipped. Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted in Forward Password Requests to Plymouth being skipped. etc... # journalctl -b | grep Condition | wc -l 37555 8. run again: systemd-ask-password 'testing: ' p 9. messgae sent to all terminals: Broadcast message from root@vmf33.chelsea.private (Sat 2021-01-16 15:28:02 GMT): Password entry required for 'testing:' (PID 1862). Please enter password with the systemd-tty-ask-password-agent tool. - Looking at the services before and after running systemd-ask-password once I see this diff: # diff -u before after | grep '^[-+]' --- before 2021-01-16 15:35:51.850438282 + +++ after 2021-01-16 15:36:08.875736785 + - systemd-ask-password-plymouth.path loaded active waiting Forward Password Requests to Plymouth Directory Watch - systemd-ask-password-wall.path loaded active waiting Forward Password Requests to Wall Directory Watch + systemd-ask-password-wall.path loaded active running Forward Password Requests to Wall Directory Watch - fprintd.service loaded active running Fingerprint Authentication Daemon + systemd-ask-password-wall.service loaded active running Forward Password Requests to Wall -196 loaded units listed. Pass --all to see loaded but inactive units, too. +195 loaded units listed. Pass --all to see loaded but inactive units, too. I am seeing this behaviour on two systems. A dell laptop and a VMware VM. Is there anything I can do to help debug this? Or just raise a big report? What work around would you suggest I use until this is fixed? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Workaround for system upgrade bug suggestions
> On 3 Nov 2020, at 15:00, Lennart Poettering wrote: > > On Mo, 02.11.20 22:20, Barry (ba...@barrys-emacs.org) wrote: > >> What is the work around until the bug is fixed? > > First step is to understand the bug. I still don't. > > At very early boot-up systemd-tmpfiles.service creates the file > /run/nologin, which the PAM module pam_nologin.so checks for, and if > it exists it will deny login attempts. During regular boots this file > is removed by "systemd-user-sessions.service" which runs much later > during boot: right before gdm is started, but after logind, after > /home is started, after all network file systems are mounted. > > The file thus ensures that users definitely cannot log in while the > system is still in the process of booting up. > > Normally, I'd assume that systemd-user-sessions.service is not pulled > in during system update boots. The question is, is it pulled in > anyway? From upstream it's pulled in by multi-user.target, and that > shouldn't end up in the system upgrade boot mode. But I have no idea > what your distros offline update logic precisely puts into its initial > transaction. > > Or maybe on your distro pam_nologin.so is missing from the PAM stack > that systemd --user is invoked through, i.e. from > /etc/pam.d/system-user. Can you check if it's there? (And any includes > referenced therein)? If so, the existance of /run/nologin of course > won't block the systemd --user instance. I'm seeing this with Fedora. First on upgrade from 30 to 31 then upgrade from 31 to 32. Does the journalctl output that I put on the bug report give any clues? If not what should I hunt for in the journal to help? I think I still have the journal from the last upgrade. > >> From upstream we only provide a very minimal PAM stack by default, > downstreams likely have to patch it, since they generalize parts of > the stack in include files, but they all do it differently, hence we > can't really carry that upstream. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Workaround for system upgrade bug suggestions
> On 3 Nov 2020, at 12:39, Colin Guthrie wrote: > > Barry wrote on 02/11/2020 22:20: >> What is the work around until the bug is fixed? > > I'd imagine you could just disable lingering for the users in question > before running the dnf upgrade command? Not ideal but it's a workaround > as you asked! Yep I guessed that would be the only thing to do. How do I get a list of all users with linger enabled? Barry > > Col > > -- > > Colin Guthrie > gmane(at)colin.guthr.ie > http://colin.guthr.ie/ > > Day Job: > Tribalogic Limited http://www.tribalogic.net/ > Open Source: > Mageia Contributor http://www.mageia.org/ > PulseAudio Hacker http://www.pulseaudio.org/ > Trac Hacker http://trac.edgewall.org/ > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Workaround for system upgrade bug suggestions
> On 2 Nov 2020, at 14:45, Lennart Poettering wrote: > > On Do, 29.10.20 20:32, Barry Scott (ba...@barrys-emacs.org) wrote: > >> There is a bug with the system upgrade of fedora that >> user services run while the system is doing the upgrade. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1829799 >> >> Clearly I do not want to have my user's user services running >> when I do the F33 upgrade. >> >> What workaround do you suggest that I use while updating >> my systems to F33? > > Hmm, the user services get run only if user sessions are instantiated > (or if you enabled "lingering" for users, via "loginctl enable-linger"). Yes. > So what sessions are those? Or do you have lingering enabled? I use them for fetching mail and other tasks. Linger is enabled. > Do you maybe have cronjobs for the user installed? System use timer units. The key fact is that I am doing a system upgrade from old fedora to a new release. During a system upgrade it is a bug that user services are running. dnf system-upgrade reboot System reboots Dnf is installling rpms but user services are running. I am repeating this, but it is the bug report. I provided the logs that show this is true. What is the work around until the bug is fixed? Barry > > Lennart > > -- > Lennart Poettering, Berlin > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Workaround for system upgrade bug suggestions
There is a bug with the system upgrade of fedora that user services run while the system is doing the upgrade. https://bugzilla.redhat.com/show_bug.cgi?id=1829799 Clearly I do not want to have my user's user services running when I do the F33 upgrade. What workaround do you suggest that I use while updating my systems to F33? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vt220 default for serial console still relevant?
> On 11 Jul 2020, at 20:31, Daan De Meyer wrote: > > > > TERM=linux means Linux console, but that's just too much, as it not > > only implies a multitude of ESC sequences specific to the Linux > > console, but also indicates that certain ioctls might work. In our own > > code we also bind certain behaviour to TERM=linux, as indicator if we > > are on the Linux console. > > > > I am not aware of any widely-supported TERM value that would be a > > reasonable subset of all currently used terminals and does color. > > I did some more research and it turns out VT220 does support colors. My > terminal emulator (Konsole) just doesn't seem to support it. I installed > xterm (which explicitly advertises support for VT220 escape codes) and got > colored output as expected. I guess this means it's up to Konsole to support > more of VT220 if I want this to work seamlessly (or I switch terminals to > xterm). > No vt220 does not support colour. I used to work on one and it is monochrome hardware. Xterm and konsole support extensions beyond vt220 that add in the colour support. Barry > Thanks for the extra info and context. > > Daan > >> On Sat, 11 Jul 2020 at 20:04, Lennart Poettering >> wrote: >> On Sa, 11.07.20 17:51, Daan De Meyer (daan.j.deme...@gmail.com) wrote: >> >> > Hi, >> > >> > I was playing around with mkosi's qemu support, more specifically adding >> > the -nographic option to have the virtual machine output in my terminal >> > instead of a separate window. After figuring out that I had to add >> > console=ttyS0 to mkosi's kernel command line, I got the output from the vm >> > in my terminal as expected. However, because systemd defaults to TERM=vt220 >> > for serial consoles, the output is not colorized. I searched around a bit >> > and found that this is done for compatibility reasons. Will there ever be a >> > point where we can switch the default to something that supports colors >> > (like TERM=linux)? >> >> TERM=linux means Linux console, but that's just too much, as it not >> only implies a multitude of ESC sequences specific to the Linux >> console, but also indicates that certain ioctls might work. In our own >> code we also bind certain behaviour to TERM=linux, as indicator if we >> are on the Linux console. >> >> I am not aware of any widely-supported TERM value that would be a >> reasonable subset of all currently used terminals and does color. >> >> > I managed to get around the problem by overriding serial-getty@ttyS0 and >> > setting Environment=TERM=linux explicitly but it's a bit of a pain and has >> > to be added to every rootfs that wants to support colored output on its >> > serial console. >> >> Unfortunately we can't guess the right terminal, we cannot propagate >> TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or >> from a Linux console, hence the best thing we can do is stick to a >> reasonably powerful subset that is likely going to exist everywhere, >> and that's vt220 right now, as noone had a better suggestion so far... >> >> Lennart >> >> -- >> Lennart Poettering, Berlin > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Umbrella unit for a group of application components
Hi All, Sorry for asking a user question, but it seems there is no user list. I came here after reading the thread about writing an umbrella unit: https://lists.freedesktop.org/archives/systemd-devel/2015-July/033610.html I have similar requirements to the person who asked that question and want to find the best solution. The application on a server comprises a few services. I would like an umbrella unit to start those services. Checking the status of the umbrella unit should only return 0 if all of the services are up. I want to be able to start or stop individual components without bringing down the others. Is this possible with systemd units? I have run into the following problems: If the umbrella is a target, it starts the services, but still thinks it is "up" if I stop one or more of the individual components. So I tried making it into a service (oneshot, /bin/true, RemainAfterExit - I know this is a hack). If I say it "Wants" the individual components, then it starts them correctly, but still thinks it is up even if individual components (which have "PartOf=" set) are stopped. If I try instead to say it "Requires" (or "BindsTo"), then the umbrella correctly shows it is not up when one of the components is stopped, but it also stops all of the other components. I would like to be able to stop one component and have that reflected in the status of the umbrella, but without stopping other components. Is this possible? Sorry for the long email and I appreciate it if anyone takes the time to read it. Thanks. Kevin Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to stop systemctl --user processes before backup runs then restart
On Thursday, 4 January 2018 13:08:33 GMT Colin Guthrie wrote: > Barry Scott wrote on 31/12/17 17:41: > > I think that for my backups to run for a user I will need to stop their > > systemd user services. > Out of curiosity, why do you think that the process needs to be stopped > for the backups to run? The process of concern are running fetchmail that is calling into dovecot. If I do not stop dovecot the Mail dir will not be consistent. If I do not stop the fetchmail process then dovecot will be called and the backup can see an inconsistent state. How do I know this? Becuase I created bad backups in the past. systemd --user is great at running the fetchmail processes for the sand boxed email users. I just need to figure out how to stop them in a way that is "systemd" smart. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to stop systemctl --user processes before backup runs then restart
I think that for my backups to run for a user I will need to stop their systemd user services. How do you recommend that I do that and after the backup has completed how do I startup the syetemd user services again, just as happened at system boot? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] why does bootctl default to /boot and not to /boot/efi?
On Monday 30 May 2016 18:47:22 Lennart Poettering wrote: > On Sun, 29.05.16 19:39, Barry Scott (ba...@barrys-emacs.org) wrote: > > I just came across the bootctl command. Atleast on Fedora 23 and 24 > > it errors out because /boot is not FAT EFI. I thought that if you are EFI > > then the EFI was always in /boot/efi. > > /boot and the ESP exist for the same reasons really, and do the same > job. Hence, systemd by default mounts the ESP to /boot and installs > sd-boot there. > > /boot/efi is a really crazy idea, as this means you always have to > mount /boot (and actually have it!) before you can mount the ESP, and > that's just off. After all in sd-boot the kernels are simply placed in > the ESP, and there's really no point in having /boot at all... > > Some distros patch sd-boot/bootctl to use /boot/efi instead, and the > other's don't but don't mount the ESP to /boot either. Given that it > is that way, it might make sense to revisit the idea of making /boot > and the ESP the same thing. But I am pretty sure /boot/efi is really > the worst idea, hence an acceptable alternatively might be to > introduce /efi and mount the esp there, and simply not have /boot on > legacy free systems. Thank you for the background. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] why does bootctl default to /boot and not to /boot/efi?
I just came across the bootctl command. Atleast on Fedora 23 and 24 it errors out because /boot is not FAT EFI. I thought that if you are EFI then the EFI was always in /boot/efi. Is there something I'm missing or is the default path wrong on Fedora? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd seems to kill mount.ntfs started in rules scripts?
On Thu 03 Apr 2014 17:27:44 Thomas Bächler wrote: Am 03.04.2014 17:13, schrieb Barry Scott: But as soon as the script exits the mount.ntfs process is killed off by something? systemd-udevd maybe? From man udev's section on RUN: This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device. Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. Instead of using RUN, use SYSTEMD_WANTS to start a .mount or .service unit that does your job. In the remove case, use RUN+=/usr/bin/systemctl stop --no-block foo.mount or similar. (Not that I think this is a good idea at all: Your volume will be unmounted after it has been remove already - you are asking for data corruption.) I did not set out to run a daemon. Its looks on the surface like I'm just mounting a device. It was a partial a surprise that the mount.ntfs process was considered part of the udev CG (but I not sure where else it might be put). What I have done is created a service that does the mount and umount actions triggered by the udev rule. I need the udev rule as I have cannot depend on any of the important properties of the USB device, its name, the FS type etc. I'm not using the template mechanism, but will investigate it. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-udevd seems to kill mount.ntfs started in rules scripts?
More of my porting from F16 to F20.
I have the following in /etc/udev/rules.d
ACTION==add, SUBSYSTEM==block, SUBSYSTEMS==usb,
RUN+=/usr/local/onelan/ntb/bin/ntb_mount_usb
ACTION==remove, SUBSYSTEM==block, SUBSYSTEMS==usb,
RUN+=/usr/local/onelan/ntb/bin/ntb_mount_usb
This run the ntb_mount_usb script as expected.
The script on the ADD action ends up doing:
mount -t ntfs -o uid=onelan,gid=onelan,noatime,noexec ${DEVNAME} /my-mount-
point
I have had the script do ps afx and systemd-cgls and see the
mount.ntfs process is running.
├─systemd-udevd.service
│ ├─ 409 /usr/lib/systemd/systemd-udevd
│ ├─14863 /usr/lib/systemd/systemd-udevd
│ ├─14867 /usr/lib/systemd/systemd-udevd
│ ├─14868 /usr/lib/systemd/systemd-udevd
│ ├─14869 /usr/lib/systemd/systemd-udevd
│ ├─14876 /bin/bash /usr/local/onelan/ntb/bin/ntb_mount_usb
│ ├─14886 /sbin/mount.ntfs /dev/sdb1 /data/data/external/USB_Memory_Stick -...
│ └─14890 systemd-cgls
But as soon as the script exits the mount.ntfs process is killed off by
something?
systemd-udevd maybe?
How should I be doing this?
Barry
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] StartTransientService problems
On Wed 05 Mar 2014 04:47:13 Lennart Poettering wrote: On Tue, 25.02.14 17:59, Barry Scott (barry.sc...@onelan.co.uk) wrote: Which should make them available via the bus for transient units. If you need other props like this, just let me know and I'll add them too... I just tried to set LimitCORE and that was rejected. Can you add this and the other related LimitXXX items please? Done, in git. Thanks. I did not find detailed docs on how to call StartTransientUnit() I have been reading the systemd sources to figure out the signatures of the call and its parameters. Did I miss API documentation? I would like to test these changes but I have failed to update a F20 system to newer code drops. Do you plan to have a F20 build of the newer systemd at least for testing? I also updated systemd-run to take arbitrary settable properties with a new -p switch to set on the unit that is created. I used that as a testcase for LimitCORE and friends. But this enables a lot of other cool things: # systemd-run -p BlockIOWeight=10 updatedb Is an awesome way to run updatedb in the background without taking much resources, totally cgroup-enabled... Lennart Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] StartTransientService problems
On Wed 05 Feb 2014 02:07:33 Lennart Poettering wrote: On Fri, 31.01.14 16:42, Barry Scott (barry.sc...@onelan.co.uk) wrote: I have finally managed to get StartTransientService to run a process for me but I'm encountering issues: we start a daemon that calls StartTransientService as required. The daemon does not run as root, it runs as onelan. We configure dbus to allow onelan to call all systemd Manager APIs. I want to set the User, Nice and Type of the service. I get the errors: DBusException: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set property User, or unknown property. DBusException: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set property Type, or unknown property. DBusException: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set property Nice, or unknown property. What do I need to do to allow these properties to be set? I also need to set the Environment. I can pass the environment in as a property but it does not show up the the process created or in systemctl status for the transient service. I do not see any messages in the systemd logging. These options weren't settable so far for transient units, because I was too lazy to make them settable. ;-) I have added this in now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=c7040b5d1c2c148f12b6a 5eef3dfce1661805131 Which should make them available via the bus for transient units. If you need other props like this, just let me know and I'll add them too... I just tried to set LimitCORE and that was rejected. Can you add this and the other related LimitXXX items please? Barry Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] StartTransientService problems
On Wed 05 Feb 2014 02:07:33 Lennart Poettering wrote: On Fri, 31.01.14 16:42, Barry Scott (barry.sc...@onelan.co.uk) wrote: I have finally managed to get StartTransientService to run a process for me but I'm encountering issues: we start a daemon that calls StartTransientService as required. The daemon does not run as root, it runs as onelan. We configure dbus to allow onelan to call all systemd Manager APIs. I want to set the User, Nice and Type of the service. I get the errors: DBusException: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set property User, or unknown property. DBusException: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set property Type, or unknown property. DBusException: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set property Nice, or unknown property. What do I need to do to allow these properties to be set? I also need to set the Environment. I can pass the environment in as a property but it does not show up the the process created or in systemctl status for the transient service. I do not see any messages in the systemd logging. These options weren't settable so far for transient units, because I was too lazy to make them settable. ;-) I have added this in now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=c7040b5d1c2c148f12b6a 5eef3dfce1661805131 Thanks you for adding this. I'm attempting to test the patch. I have built from git the latest code on a F20 system. I then created a tar ball of the make install DESTDIR=tmp and explored that tar ball over a F20 working system. But I am hitting 2 issues: 1) We cannot call sched_setscheduler() in spite of the cpu cgroup being setup correctly (e.g. works with systemd-208): # grep . /sys/fs/cgroup/cpu/onelan.slice/onelan-screen.slice/cpu.rt* /sys/fs/cgroup/cpu/onelan.slice/onelan- screen.slice/cpu.rt_period_us:10 /sys/fs/cgroup/cpu/onelan.slice/onelan- screen.slice/cpu.rt_runtime_us:9 2) When I call StartTransientUnit I get a permission error: DBusException: org.freedesktop.DBus.Error.AccessDenied: Access to org.freedesktop.systemd1.Manager.StartTransientUnit() not permitted. I have the following setup (copied from /etc/dbus-1/system.d/org.freedesktop.systemd1.conf): # cat /etc/dbus-1/system.d/ONELAN-systemd.conf ?xml version=1.0? !DOCTYPE busconfig PUBLIC -//freedesktop//DTD D-BUS Bus Configuration 1.0//EN http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd; busconfig policy user=onelan allow own=org.freedesktop.systemd1/ !-- Onelan clients can do everything -- allow send_destination=org.freedesktop.systemd1/ allow receive_sender=org.freedesktop.systemd1/ !-- systemd may receive activator requests -- allow receive_interface=org.freedesktop.systemd1.Activator receive_member=ActivationRequest/ /policy /busconfig Which should have allowed the process running as onelan user to call StartTransientUnit. Which should make them available via the bus for transient units. If you need other props like this, just let me know and I'll add them too... And lastly what do I have to do to remove the transient service from systemd after the last process in the service exits? RemainAfterExit=no RemainAfterExit=no is already available? Transient services that fail persist until you reboot the system. This can be shown by using systemd-run to run /bin/true and /bin/false all the /bin/true are removed but the /bin/false cannot be removed. # systemd-run --desc false /bin/false Running as unit run-1073.service. # systemctl status run-1073.service run-1073.service - false Loaded: loaded (/run/systemd/system/run-1073.service; static) Drop-In: /run/systemd/system/run-1073.service.d └─90-Description.conf, 90-ExecStart.conf, 90-RemainAfterExit.conf, 90-SendSIGHUP.conf Active: failed (Result: exit-code) since Wed 2014-02-05 18:21:51 GMT; 12s ago Process: 1074 ExecStart=/bin/false (code=exited, status=1/FAILURE) Main PID: 1074 (code=exited, status=1/FAILURE) Feb 05 18:21:51 localhost.localdomain systemd[1]: Starting false... Feb 05 18:21:51 localhost.localdomain systemd[1]: Started false. Feb 05 18:21:51 localhost.localdomain systemd[1]: run-1073.service: main process exited, code=exited, status=1/FAILURE Feb 05 18:21:51 localhost.localdomain systemd[1]: Unit run-1073.service entered failed state. # systemctl --full |grep ^run run-1073.service loaded failed failedfalse # systemctl stop run-1073.service # systemctl --full |grep ^run run-1073.service loaded failed failedfalse Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org
[systemd-devel] [PATCH] Use normal English elide in place of ellipsize
Change the messages output and also all internal
function names and variables to match.
---
man/journalctl.xml | 2 +-
man/loginctl.xml | 2 +-
man/machinectl.xml | 2 +-
man/systemctl.xml | 4 ++--
man/systemd-cgls.xml | 2 +-
src/cgls/cgls.c| 2 +-
src/cgtop/cgtop.c | 2 +-
src/journal/journalctl.c | 6 +++---
src/libsystemd/sd-bus/busctl.c | 2 +-
src/login/loginctl.c | 2 +-
src/login/sysfs-show.c | 4 ++--
src/machine/machinectl.c | 2 +-
src/shared/logs-show.c | 28 ++--
src/shared/logs-show.h | 4 ++--
src/shared/util.c | 16
src/shared/util.h | 4 ++--
src/systemctl/systemctl.c | 38 +++---
src/test/test-ellipsize.c | 2 +-
18 files changed, 62 insertions(+), 62 deletions(-)
diff --git a/man/journalctl.xml b/man/journalctl.xml
index 3b05e80..78417f1 100644
--- a/man/journalctl.xml
+++ b/man/journalctl.xml
@@ -156,7 +156,7 @@
termoption--full/option/term
termoption-l/option/term
-listitemparaEllipsize fields when
+listitemparaElide fields when
they do not fit in available columns.
The default is to show full fields,
allowing them to wrap or be truncated
diff --git a/man/loginctl.xml b/man/loginctl.xml
index 13105d4..682ed1d 100644
--- a/man/loginctl.xml
+++ b/man/loginctl.xml
@@ -163,7 +163,7 @@
termoption-l/option/term
termoption--full/option/term
-listitemparaDo not ellipsize
+listitemparaDo not elide
process tree entries./para
/listitem
/varlistentry
diff --git a/man/machinectl.xml b/man/machinectl.xml
index 6e991ee..1d62ff0 100644
--- a/man/machinectl.xml
+++ b/man/machinectl.xml
@@ -153,7 +153,7 @@
termoption-l/option/term
termoption--full/option/term
-listitemparaDo not ellipsize
+listitemparaDo not elide
process tree entries./para
/listitem
/varlistentry
diff --git a/man/systemctl.xml b/man/systemctl.xml
index ed1bf48..efa1d28 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -174,7 +174,7 @@ along with systemd; If not, see
http://www.gnu.org/licenses/.
termoption--full/option/term
listitem
- paraDo not ellipsize unit names, process tree entries,
+ paraDo not elide unit names, process tree entries,
journal output, or truncate unit descriptions in the output
of commandstatus/command, commandlist-units/command,
commandlist-jobs/command, and
@@ -731,7 +731,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
paraThis function is intended to generate human-readable
output. If you are looking for computer-parsable output,
use commandshow/command instead. By default this
-function only shows 10 lines of output and ellipsizes
+function only shows 10 lines of output and elides
lines to fit in the terminal window. This can be changes
with option--lines/option and option--full/option,
see above. In addition, commandjournalctl
diff --git a/man/systemd-cgls.xml b/man/systemd-cgls.xml
index 955e0da..c570269 100644
--- a/man/systemd-cgls.xml
+++ b/man/systemd-cgls.xml
@@ -116,7 +116,7 @@
termoption-l/option/term
termoption--full/option/term
-listitemparaDo not ellipsize
+listitemparaDo not elide
process tree members./para
/listitem
/varlistentry
diff --git a/src/cgls/cgls.c b/src/cgls/cgls.c
index b8e275d..7e04912 100644
--- a/src/cgls/cgls.c
+++ b/src/cgls/cgls.c
@@ -50,7 +50,7 @@ static int help(void) {
--versionShow package version\n
--no-pager Do not pipe output into a pager\n
-a --allShow all groups, including empty\n
- -l --full Do not ellipsize output\n
+ -l --full Do not elide output\n
-k Include kernel threads in output\n
-M --machineShow container\n,
Re: [systemd-devel] [PATCH] Use normal English elide in place of ellipsize
On Tue 04 Feb 2014 19:36:34 Andrey Borzenkov wrote: В Tue, 4 Feb 2014 15:31:58 + Barry Scott barry.sc...@onelan.co.uk пишет: Change the messages output and also all internal function names and variables to match. As a non-native English speaker I must admit ellipsize was more understandable. I am not sure I would understand elide if it was not used in this context. Ellipsize is not in any dictionary for any language. Elide is the English word describing what is meant by the ... ellipsis and can be looked up in any dictionary, which is better the a word that cannot be looked up. Using a well defined word will allow translators to create good quality translations of the systemd UI. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Use normal English elide in place of ellipsize
Change the messages output and also all internal
function names and variables to match.
---
man/journalctl.xml | 2 +-
man/loginctl.xml | 2 +-
man/machinectl.xml | 2 +-
man/systemctl.xml | 4 ++--
man/systemd-cgls.xml | 2 +-
src/cgls/cgls.c| 2 +-
src/cgtop/cgtop.c | 2 +-
src/journal/journalctl.c | 6 +++---
src/libsystemd/sd-bus/busctl.c | 2 +-
src/login/loginctl.c | 2 +-
src/login/sysfs-show.c | 4 ++--
src/machine/machinectl.c | 2 +-
src/shared/logs-show.c | 28 ++--
src/shared/logs-show.h | 4 ++--
src/shared/util.c | 16
src/shared/util.h | 4 ++--
src/systemctl/systemctl.c | 38 +++---
src/test/test-ellipsize.c | 2 +-
18 files changed, 62 insertions(+), 62 deletions(-)
diff --git a/man/journalctl.xml b/man/journalctl.xml
index 3b05e80..78417f1 100644
--- a/man/journalctl.xml
+++ b/man/journalctl.xml
@@ -156,7 +156,7 @@
termoption--full/option/term
termoption-l/option/term
-listitemparaEllipsize fields when
+listitemparaElide fields when
they do not fit in available columns.
The default is to show full fields,
allowing them to wrap or be truncated
diff --git a/man/loginctl.xml b/man/loginctl.xml
index 13105d4..682ed1d 100644
--- a/man/loginctl.xml
+++ b/man/loginctl.xml
@@ -163,7 +163,7 @@
termoption-l/option/term
termoption--full/option/term
-listitemparaDo not ellipsize
+listitemparaDo not elide
process tree entries./para
/listitem
/varlistentry
diff --git a/man/machinectl.xml b/man/machinectl.xml
index 6e991ee..1d62ff0 100644
--- a/man/machinectl.xml
+++ b/man/machinectl.xml
@@ -153,7 +153,7 @@
termoption-l/option/term
termoption--full/option/term
-listitemparaDo not ellipsize
+listitemparaDo not elide
process tree entries./para
/listitem
/varlistentry
diff --git a/man/systemctl.xml b/man/systemctl.xml
index ed1bf48..efa1d28 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -174,7 +174,7 @@ along with systemd; If not, see
http://www.gnu.org/licenses/.
termoption--full/option/term
listitem
- paraDo not ellipsize unit names, process tree entries,
+ paraDo not elide unit names, process tree entries,
journal output, or truncate unit descriptions in the output
of commandstatus/command, commandlist-units/command,
commandlist-jobs/command, and
@@ -731,7 +731,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
paraThis function is intended to generate human-readable
output. If you are looking for computer-parsable output,
use commandshow/command instead. By default this
-function only shows 10 lines of output and ellipsizes
+function only shows 10 lines of output and elides
lines to fit in the terminal window. This can be changes
with option--lines/option and option--full/option,
see above. In addition, commandjournalctl
diff --git a/man/systemd-cgls.xml b/man/systemd-cgls.xml
index 955e0da..c570269 100644
--- a/man/systemd-cgls.xml
+++ b/man/systemd-cgls.xml
@@ -116,7 +116,7 @@
termoption-l/option/term
termoption--full/option/term
-listitemparaDo not ellipsize
+listitemparaDo not elide
process tree members./para
/listitem
/varlistentry
diff --git a/src/cgls/cgls.c b/src/cgls/cgls.c
index b8e275d..7e04912 100644
--- a/src/cgls/cgls.c
+++ b/src/cgls/cgls.c
@@ -50,7 +50,7 @@ static int help(void) {
--versionShow package version\n
--no-pager Do not pipe output into a pager\n
-a --allShow all groups, including empty\n
- -l --full Do not ellipsize output\n
+ -l --full Do not elide output\n
-k Include kernel threads in output\n
-M --machineShow container\n,
Re: [systemd-devel] [PATCH] Use normal English elide in place of ellipsize
On Tue 04 Feb 2014 16:15:52 Colin Guthrie wrote: If we do want to describe the action taken rather than the effect, then I would use the word truncate here, rather than elide as this is really what happens now as implemented. But the output is not truncated. Here is example from my system: home-build\x2dvm-de...onelan\x2df16\x2d5-home-bscott.mount loaded active mounted /home/build-vm/dev64-onelan-f16-5/home/bscott The middle has been removed, not the end. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] StartTransientService problems
I have finally managed to get StartTransientService to run a process for me but I'm encountering issues: we start a daemon that calls StartTransientService as required. The daemon does not run as root, it runs as onelan. We configure dbus to allow onelan to call all systemd Manager APIs. I want to set the User, Nice and Type of the service. I get the errors: DBusException: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set property User, or unknown property. DBusException: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set property Type, or unknown property. DBusException: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set property Nice, or unknown property. What do I need to do to allow these properties to be set? I also need to set the Environment. I can pass the environment in as a property but it does not show up the the process created or in systemctl status for the transient service. I do not see any messages in the systemd logging. And lastly what do I have to do to remove the transient service from systemd after the last process in the service exits? RemainAfterExit=no Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What do I need to do to force systemd to create folders in the cgroups tree?
On Tue 28 Jan 2014 08:23:35 David Timothy Strauss wrote: You're using both onelan-player.slice and onelan-players.slice in your example. Correct this first. Doh! Fixing that mistake makes the cgroup appear. Thanks for taking the time to look at this. systemd does not report an issue with the missing .slice file. Is it considered to be valid to refer to a .slice that is not backed up with a .slice file on disk? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] What do I need to do to force systemd to create folders in the cgroups tree?
For my application I have three slices. Two of these are working,
onelan.slice and onelan-screen.slice, but onelan-player.slice is
not causing the cgroup folders to come into existence.
I put a dependency on workaround-systemd-cgroup-limitations-onelan-player-
slice.service to cause onelan-player.slice to be created. That slice will
be used later to hold processes create via the dbus start transient interface.
But when that services run I see the following cgroups:
# find /sys/fs/cgroup -name '*.slice' -print
/sys/fs/cgroup/memory/onelan.slice
/sys/fs/cgroup/cpuacct/onelan.slice
/sys/fs/cgroup/cpuacct/onelan.slice/onelan-screen.slice
/sys/fs/cgroup/cpuacct/onelan.slice/onelan-player.slice
/sys/fs/cgroup/cpu/onelan.slice
/sys/fs/cgroup/cpu/onelan.slice/onelan-screen.slice
/sys/fs/cgroup/cpu/onelan.slice/onelan-player.slice
/sys/fs/cgroup/systemd/user.slice
/sys/fs/cgroup/systemd/onelan.slice
/sys/fs/cgroup/systemd/onelan.slice/onelan-screen.slice
/sys/fs/cgroup/systemd/onelan.slice/onelan-player.slice
/sys/fs/cgroup/systemd/system.slice
/sys/fs/cgroup/systemd/system.slice/system-lvm2\x2dpvscan.slice
/sys/fs/cgroup/systemd/system.slice/system-systemd\x2dfsck.slice
/sys/fs/cgroup/systemd/system.slice/system-systemd\x2dbacklight.slice
/sys/fs/cgroup/systemd/system.slice/system-getty.slice
I expect to have /sys/fs/cgroup/memory/onelan.slice/onelan-player.slice
but it does not exist.
What do I need to do to force it to be created?
Here is the content of involved unit files and status from systemd.
# cat /etc/systemd/system/workaround-systemd-cgroup-limitations-onelan-player-
slice.service
[Unit]
Description=workaround systemd cgroup limitations service
After=workaround-systemd-cgroup-limitations-onelan-slice.service
Requires=workaround-systemd-cgroup-limitations-onelan-slice.service
[Service]
Slice=onelan-player.slice
Type=oneshot
StandardOutput=syslog
ExecStart=/usr/local/onelan/systemd/workaround-systemd-cgroup-limitations
onelan-player.slice
RemainAfterExit=yes
# cat /usr/local/onelan/systemd/workaround-systemd-cgroup-limitations
#!/bin/bash
#
# Copyright 2014 (c) ONELAN Ltd. www.onelan.co.uk
# All rights reserved.
#
#
# workaround-systemd-cgroup-limitations
#
# As of systemd 208 it is not possible to setup all
# the cgroup attributes that we need.
#
# As soon as systemd aquires a method of doing the
# additional cgroup setup this module and its .service
# can be deleted.
#
set -e
function set_attr {
VALUE=$1
CGATTR=$2
echo Info: Set ${VALUE} into ${CGATTR}
echo ${VALUE} ${CGATTR}
}
case $1 in
onelan.slice)
find /sys/fs/cgroup -name '*.slice' -print /root/onelan.slice.log
CGROUP=/sys/fs/cgroup/cpu/onelan.slice
set_attr 10 ${CGROUP}/cpu.rt_period_us
set_attr 9 ${CGROUP}/cpu.rt_runtime_us
;;
onelan-player.slice)
find /sys/fs/cgroup -name '*.slice' -print /root/onelan-player.slice.log
CGROUP=/sys/fs/cgroup/memory/onelan.slice/onelan-players.slice
LINE=$( grep '#SwapMemoryLimit' /etc/onelan/ntb/systemd-player-memory-
limits.include )
LIMIT=${LINE#*=}
set_attr ${LIMIT} ${CGROUP}/memory.memsw.limit_in_bytes
;;
*)
exit 1
;;
esac
# cat /etc/systemd/system/onelan-players.slice
[Unit]
Description=ONELAN Players Slice
DefaultDependencies=no
Before=slices.target
Wants=onelan.slice
After=onelan.slice
[Slice]
CPUAccounting=true
MemoryAccounting=true
.include /etc/onelan/ntb/systemd-player-memory-limits.include
# cat /etc/onelan/ntb/systemd-player-memory-limits.include
[Slice]
MemoryLimit=3217719296
#SwapMemoryLimit=5365202944
# systemctl status onelan-player.slice
onelan-player.slice
Loaded: loaded
Active: active since Mon 2014-01-27 10:43:20 GMT; 24min ago
Barry
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Set cgroup attributes not supported by systemd - what do you recommend?
On Fri 24 Jan 2014 11:37:49 Lennart Poettering wrote: On Thu, 23.01.14 11:55, Barry Scott (barry.sc...@onelan.co.uk) wrote: I am running systemd 208 on Fedora 20. There are 2 cpu cgroup attributes that I need to set to allow realtime for some daemons: cpu.rt_period_us and cpu.rt_runtime_us. For the memory cgroup I need to set memory.memsw.limit_in_bytes for one of my slices. Do you plan to add support for setting these attributes in a future systemd update? Yes, but don't hold your breath... Basically, we are currently only exposing attributes that Tejun (the kernel cgroups maintainer) considers to be attributes that are going to be available after the cgroup rework is finished. The memsw and RT stuff does not really fall into that category, it is not clear that they will be available after the kernel clean-up, and if they will, then not necessarily with the same semantics. Thanks we'll keep track of what Tejun is planning. Just for the record we don't care if cgroups manages the RT stuff all we need to be able to do is have the ability to call setrlimit() and sched_setscheduler(). We have a use case for memsw as a cgroup attribute, however we are open to arguments that its not needed. Until there is support I could have a .service run code to setup the attributes for the .slice's before services that need the changes. Would that be a suitable workaround until there is support in systemd? For now, I recommend adding a small ExecStartPre= script into the respective services, that gets passed %c which resolves to the cgroup path. Then, in that script simply echo the values you need into the right attributes. I have the moral equivalent that I'm getting going now. Lennart Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Set cgroup attributes not supported by systemd - what do you recommend?
I am running systemd 208 on Fedora 20. There are 2 cpu cgroup attributes that I need to set to allow realtime for some daemons: cpu.rt_period_us and cpu.rt_runtime_us. For the memory cgroup I need to set memory.memsw.limit_in_bytes for one of my slices. Do you plan to add support for setting these attributes in a future systemd update? Until there is support I could have a .service run code to setup the attributes for the .slice's before services that need the changes. Would that be a suitable workaround until there is support in systemd? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hangs after Welcome message when LogLevel=debug
On Fri 17 Jan 2014 21:17:04 Lennart Poettering wrote: On Tue, 14.01.14 13:31, Barry Scott (barry.sc...@onelan.co.uk) wrote: systemd-208-9.fc20.x86_64 We have been porting a working configuration from fedora 19 to fedora 20. After systemd prints the Welcome message it then hangs. What do you mean by hangs? Is it just the output that doesn't continue anymore or does the entire system lock up? After a few minutes nothing is output after the Welcome message. No evidence that any unit start. Note that during really early boot the journal is not available yet, which means we can only log to kmsg then (and thus the console). However, as soon as the journal is available we then start logging directly to the journal. This might appear from the outside as if only during the first part of the boot output is generated if you only look at the console. Understood and recall that I'm porting from F19 to F20 and this works in F19. With my engineer hat on I wonder why info messages can be output but not one debug message? You can use LogTarget=kmsg to redirect output to kmsg unconditionally, so that you get everything in kmsg and thus the console. And by using the kernel option log_buf_len=128M we can make sure all the messages are kept. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hangs after Welcome message when LogLevel=debug
On Mon 20 Jan 2014 13:21:14 Lennart Poettering wrote: On Mon, 20.01.14 11:22, Barry Scott (barry.sc...@onelan.co.uk) wrote: On Fri 17 Jan 2014 21:17:04 Lennart Poettering wrote: On Tue, 14.01.14 13:31, Barry Scott (barry.sc...@onelan.co.uk) wrote: systemd-208-9.fc20.x86_64 We have been porting a working configuration from fedora 19 to fedora 20. After systemd prints the Welcome message it then hangs. What do you mean by hangs? Is it just the output that doesn't continue anymore or does the entire system lock up? After a few minutes nothing is output after the Welcome message. No evidence that any unit start. It would be good to if I could have a look at the output of journalctl -o short-monotonic -b of the log messages around the time where this happens... With my engineer hat on I wonder why info messages can be output but not one debug message? Not following? Given this problem has not trigger an insight from your selves I clearly need to dig deeper to get more information. I'm very busy at work at the moment but hope to come back to this to help bottom out what is happening. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hangs after Welcome message when LogLevel=debug
I drafted this last week, sorry for the delay. On Wed 15 Jan 2014 16:44:21 Holger Schurig wrote: Educated guess (!) With LogLevel=debug, you generate huge amounts of output. With LogTarget=syslog-or-kmsg and kernel not quiet I would expect to see the first few debug messages before it hung up. But nothing appears. With DefaultStandardOutput=syslog, you're asking systemd to send it's output to syslog. But while systemd is starting your system the syslog might not be ready. Probably systemd has some buffer, where it buffers the output. Once syslog becomes available, it will be fed with the buffer's contents first. If the output is small enought, as with LogLevel=info, this actually works. But when you generate gobs of output, the buffer will overflow and the output routine will wait until the buffer get's emptied, which it never will ... So, you might try to use DefaultStandardOutput=syslog-or-kmsg or DefaultStandardOutput=journal instead. The latter will eventually also send the output to syslog, which is why it's a default. I guess you are saying that because all output must go to syslog and syslog is not running that systemd will hang. But why does the configuration work if LogLevel=info in that case? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd hangs after Welcome message when LogLevel=debug
systemd-208-9.fc20.x86_64 We have been porting a working configuration from fedora 19 to fedora 20. After systemd prints the Welcome message it then hangs. We found that changing the LogLevel from debug to info fixes the hang. As does setting LogTarget=console. It would seem that the default LogTarget cannot be used to log debug messages. Does the default log target use debug itself and deadlock or loop? Here is the full system.conf: [Manager] LogLevel=debug DumpCore=yes DefaultStandardOutput=syslog JoinControllers= Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hangs on shutdown
On Thursday 13 October 2011 20:02:48 Daniel Drake wrote: On Tue, Oct 11, 2011 at 1:44 AM, Lennart Poettering lenn...@poettering.net wrote: So this is a the big issue here I believe. If you look at 87.293308 you'll see that tmp.mount is suddenly mounted again for some reason, which systemd then takes as hint to get rid of poweroff.target/poweroff.service, since they conflict with that. It key to the mystery here is figuring out why systemd suddenly sees those mount points coming back. It would be good to figure out what the mount table is when that happens. Is this related to the problem I'm seeing with swapoff being called at the wrong time in shutdown? Barry Thanks for looking carefully at this! It looks like the problem is that we had /tmp mounted as tmpfs, then mounted as tmpfs again on top. We've had this for a long time (unintentionally), but it hadn't surfaced as an issue until now - we didn't even realise. After removing the duplicate mount setup so that /tmp is only mounted once, the system shuts down. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Seeking Advice on debugging failure to reboot
On Wednesday 12 October 2011 17:54:27 Barry Scott wrote: On Wednesday 12 October 2011 16:42:38 Michal Schmidt wrote: On 10/12/2011 04:54 PM, Barry Scott wrote: What dependency is supposed to cause the swapoff to be after the production processes are stopped? The units' ordering should be something like this: *.swap Before swap.target Before sysinit.target Before basic.target Before production.service This ordering is used for startup. When shutting down, they should get stopped in the reverse order. I think I see what the issue is. My default target contains: Requires=basic.target After=basic.target But it also contains lines like: Requires=start-signage.service After=start-signage.service This means that start-signage can run in parallel with basic.target. What I need to do is find all the production services and tell them to run after basic.target. I'll work on that and see where I get. Using systemctl dump I can see that my production services all have the suggested properties: ... - Unit daemon-network-manager-controller.service: Requires: basic.target After: basic.target References: basic.target - Unit daemon-layout.service: Requires: basic.target After: basic.target References: basic.target ... Does this point to a bug in systemd-26-8.fc15.i686 reboot code? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Seeking Advice on debugging failure to reboot
Thanks to Michal's observation that swapoff failed we have now found the root cause. swapoff is called while all our production processes are still running. We would have expected systemd to turn off swap after stopping most if not all processes and thus freeing up as much memory as possible. swapoff fails becuase there is not enough ram available to load the pages from swap into. Is this a systemd problem or an issue with the way we wrote our services and targets? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Seeking Advice on debugging failure to reboot
On Wednesday 12 October 2011 15:27:10 Michal Schmidt wrote: On 10/12/2011 03:46 PM, Barry Scott wrote: Thanks to Michal's observation that swapoff failed we have now found the root cause. swapoff is called while all our production processes are still running. We would have expected systemd to turn off swap after stopping most if not all processes and thus freeing up as much memory as possible. swapoff fails becuase there is not enough ram available to load the pages from swap into. Is this a systemd problem or an issue with the way we wrote our services and targets? Do you use DefaultDependencies=false in any of your service unit files? That could explain the missing ordering. No, not in any of our files. What dependency is supposed to cause the swapoff to be after the production processes are stopped? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Seeking Advice on debugging failure to reboot
On Wednesday 12 October 2011 16:42:38 Michal Schmidt wrote: On 10/12/2011 04:54 PM, Barry Scott wrote: What dependency is supposed to cause the swapoff to be after the production processes are stopped? The units' ordering should be something like this: *.swap Before swap.target Before sysinit.target Before basic.target Before production.service This ordering is used for startup. When shutting down, they should get stopped in the reverse order. I think I see what the issue is. My default target contains: Requires=basic.target After=basic.target But it also contains lines like: Requires=start-signage.service After=start-signage.service This means that start-signage can run in parallel with basic.target. What I need to do is find all the production services and tell them to run after basic.target. I'll work on that and see where I get. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Seeking Advice on debugging failure to reboot
On Tuesday 11 October 2011 12:37:23 Michal Schmidt wrote: On 10/11/2011 12:44 PM, Barry Scott wrote: The full log is here: http://onelanftp.co.uk/bscott/ntb10117.netconsole.txt The first boot sequence from lines 1-182 works. The second from 188-1182 has the problem. If the kernel is at fault then I would expect to see the About to execute: /bin/systemctl --force reboot line and a failure to reboot. But given that line is not output I suspect its more likely to be an issue with systemd not getting to that point. And question is what stops this happening? In the second run umount.target is not reached. It is not obvious why. The log shows only /data, /boot and /media being unmounted in both runs. There may be a mountpoint that refuses to die. Did you try waiting a few minutes to see if any timeout kicks in? We do not see any timeout. It is unfortunate that we only see the messages after syslog is stopped. Try with systemd.log_target=console, or just stop rsyslog.service manually before invoking reboot. This way netconsole should show more of the events. I have uploaded full netconsole logs with the options you suggested: http://onelanftp.co.uk/bscott/netconsole.noreboot.txt http://onelanftp.co.uk/bscott/netconsole.reboot.txt Here is the output of mount from the same system after power-fail reboot: # mount /proc on /proc type proc (rw,relatime) /sys on /sys type sysfs (rw,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=509736k,nr_inodes=127434,mode=755) devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /dev/shm type tmpfs (rw,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) /dev/mapper/NTBgroup-System4 on / type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu) cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) systemd-1 on /dev/mqueue type autofs (rw,relatime,fd=23,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) systemd-1 on /dev/hugepages type autofs (rw,relatime,fd=24,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=25,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) systemd-1 on /sys/kernel/debug type autofs (rw,relatime,fd=26,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) systemd-1 on /sys/kernel/security type autofs (rw,relatime,fd=28,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) /dev/mapper/NTBgroup-Data on /data type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered) /dev/sda1 on /boot type ext3 (rw,noatime,errors=continue,user_xattr,acl,barrier=0,data=ordered) Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Seeking Advice on debugging failure to reboot
On Tuesday 11 October 2011 16:35:00 Michal Schmidt wrote: On 10/11/2011 05:09 PM, Barry Scott wrote: I have uploaded full netconsole logs with the options you suggested: http://onelanftp.co.uk/bscott/netconsole.noreboot.txt http://onelanftp.co.uk/bscott/netconsole.reboot.txt A suspicious moment occurring only in the failing case is: [ 751.743255] swapoff[7788]: swapoff: /dev/dm-1: swapoff failed: Cannot allocate memory ... [ 751.830279] systemd[1]: dev-dm\x2d1.swap changed deactivating - failed I wonder if this could prevent the reaching of umount.target. Aha. I'll work on findout out what is using up all the memory. Maybe I have a process that has eaten up lots of ram preventing swapoff from succeeding. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Seeking Advice on debugging failure to reboot
On Thursday 06 October 2011 15:56:43 Barry Scott wrote: We can reproducably get an F15 system in a state that it fails to complete a reboot. Becuase all the logging, network and getty's has been stopped all we can see is the kernel messages on the console. What we need to know is why systemd is not completing the reboot. What advice do you have on how to debug this situation please? Barry We have got a bit further along using netconsole to see the kmsg after systemd turns off syslog. The obvious difference between a reboot that works and one that fails is that I see these lines in the good case: [ 135.391206] systemd[1]: final.target changed dead - active [ 135.391217] systemd[1]: Job final.target/start finished, result=done [ 135.391249] systemd[1]: About to execute: /bin/systemctl --force reboot But this never happens in the bad case. How do I track down why final.target is not activated? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] .include directive does not include as textual include it includes by parsing the include file.
This means that section headers must be used inside of a .include file otherwise all the lines are ignored. Signed-off-by: Barry Scott barry.sc...@onelan.co.uk --- man/systemd.unit.xml |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index bf8de32..e47c146 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -121,8 +121,9 @@ paraIf a line starts with option.include/option followed by a file name, the specified file will be -read as if its contents were listed in place of the -option.include/option directive./para +parsed at this point. Make sure that the file that is +included has the appropiate section headers before +any directives./para paraAlong with a unit file filenamefoo.service/filename a directory -- 1.7.6 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2-V2] For ExecStart= provide more details on env var substitution and how that turns into arguments.
For EnvironmentFile= explain that double quotes can be used
to protect whitespace.
Signed-off-by: Barry Scott barry.sc...@onelan.co.uk
---
Change since V1:
* fix wording to be normal english
man/systemd.exec.xml|5 +
man/systemd.service.xml | 23 ---
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index 609484b..96260cd 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -279,6 +279,11 @@
assignments. Empty lines and lines
starting with ; or # will be ignored,
which may be used for commenting. The
+parser for will strip leading and
+trailing whitespace from the values
+of assignments, unless you use
+double quotes ().
+The
argument passed should be an absolute
file name, optionally prefixed with
-, which indicates that if the file
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 4f11020..7e3679d 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -311,18 +311,19 @@
main process of the daemon. The
command line accepts % specifiers as
described in
-
citerefentryrefentrytitlesystemd.unit/refentrytitlemanvolnum5/manvolnum/citerefentry.
On
-top of that basic environment variable
-substitution is supported, where
-literal${FOO}/literal is replaced
-by the string value of the environment
-variable of the same name. Also
-literal$FOO/literal may appear as
-separate word on the command line in
-which case the variable is replaced by
-its value split at whitespaces. Note
+
citerefentryrefentrytitlesystemd.unit/refentrytitlemanvolnum5/manvolnum/citerefentry./para
+paraOn top of that basic environment variable
+substitution is supported. Use
literal${FOO}/literal
+as part of a word, or as word of its own on the
+command line, in which case it will be replaced
+by the value of the env var including all
+whitespace it contains, resulting in 1
argument.
+Use literal$FOO/literal as a separate word
+on the command line, in which case it will be
+replaced by the value of the env var split up
at
+whitespace, resulting in 0 or more arguments.
Note
that the first argument (i.e. the
-binary to execute) may not be a
+program to execute) may not be a
variable, and must be a literal and
absolute path name./para/listitem
/varlistentry
--
1.7.6
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] start service only on specific exit status of some prog
On Wednesday 24 August 2011 17:25:40 Marius Tolzmann wrote: On 24.08.2011 16:01, Lennart Poettering wrote: On Tue, 02.08.11 17:06, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote: is there a way to execute a program and take its exit status to evaluate the condition? like ConditionExec or whatever. is this already possible without getting a failed service? Hmm, so I think we should make sure that systemd unit files don't become a programming language. i.e. there needs to be a limit on what we want to allow to be expressed in unit files. I am tempted to say that checks like this are probably beyond that limit, and fall into the domain where shell scripts should be used. I.e. write a tiny shell script that is executed in ExecStartPre invokes your tool, checks the return code and then fails if needed. Hi... thanks for the reply.. i really don't want to implement complex checks within unit files.. but currently systemd lacks a clean possibility to implement complex checks outside of unit files. snip... Why not have the complex logic run before the system reboots and chaneg the systemd dependancies? For example in our application a TV card is optional. We could check at run time during boot, but it seemed cleaner to us to change the dependancies. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Real Time access in a systemd control group
On Friday 29 July 2011 13:50:49 Marius Perjeru wrote: Hi, We configured a systemd environment, but we cannot have real time access when running an application. We have defined a xorg.service which starts the X, and every script runned gets under systemd/xorg.service control group, and because this control group does not have real time access (cpu.rt_runtime_us contains 0 value), we cannot run real time applications. I tryied to create a system_at_marius.service containing: [Unit] Description=Systemd for marius user [Service] User=marius PAMName=systemd ExecStart=/bin/systemd --user [Install] WantedBy=multi-user.target But it won't start: Starting Systemd for marius user... 29systemd[1]: systemd_at_marius.service: main process exited, code=exited, status=1 29systemd[1]: Unit systemd_at_marius.service entered failed state. Is there anyway that I could give real time access to some control groups (or services)? I know there is LimitRTTIME variable which I set it to infinity, but the behavior does not change. I also tried to create a realtime group, added it to /etc/security/limits.d/99-realtime.conf @realtime - rtprio99 @realtime - memlock unlimited And add marius user to this group. But that also did not change anything. Best Regards, Marius ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel We do this: [Service] StandardOutput=syslog WorkingDirectory=/data/data/logs ControlGroup=cpu:/ cpuacct:/screen LimitRTPRIO=2 LimitRTTIME=6000 CPUSchedulingPolicy=rr CPUSchedulingPriority=1 ExecStartPre=/usr/local/onelan/ntb/bin/ntb_apply_screen_settings /etc/onelan/ntb/x.conf ExecStartPre=-/bin/plymouth quit --retain-splash ExecStart=/usr/bin/Xorg :0 -noreset -nolisten tcp -background none vt1 -dpi 75 -logfile /data/data/logs/screen-server.log -dumbSched -config /etc/onelan/ntb/x.conf Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Documentation: Clarify env var handling
Can I have feedback on the patch please? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What is the recommended way to replace hald hooks in the systemd world?
On Friday 15 July 2011 13:58:16 Lennart Poettering wrote: On Fri, 15.07.11 11:14, Barry Scott (barry.sc...@onelan.co.uk) wrote: In F13 days we used HAL to call out to our code to handle adding and removal of USB storage with this /etc/hal/fdi/policy/90-onelan-mount.fdi policy file. ?xml version=1.0 encoding=UTF-8? deviceinfo version=0.2 device match key=volume.fsusage string=filesystem match key=@info.parent:storage.bus string=usb append key=info.callouts.add type=strlistntb_mount_usb -v/append append key=info.callouts.remove type=strlistntb_mount_usb -v/append /match /match /device /deviceinfo Do you recommmend staying with hal in F15 or using some other mechanism? You can use udev rules. to pull this in. Thanks for the pointer. I used udev and created these rules: ACTION==add, SUBSYSTEM==block, SUBSYSTEMS==usb, RUN+=/usr/local/onelan/ntb/bin/ntb_mount_usb ACTION==remove, SUBSYSTEM==block, SUBSYSTEMS==usb, RUN+=/usr/local/onelan/ntb/bin/ntb_mount_usb Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] What is the recommended way to replace hald hooks in the systemd world?
In F13 days we used HAL to call out to our code to handle adding and removal of USB storage with this /etc/hal/fdi/policy/90-onelan-mount.fdi policy file. ?xml version=1.0 encoding=UTF-8? deviceinfo version=0.2 device match key=volume.fsusage string=filesystem match key=@info.parent:storage.bus string=usb append key=info.callouts.add type=strlistntb_mount_usb -v/append append key=info.callouts.remove type=strlistntb_mount_usb -v/append /match /match /device /deviceinfo Do you recommmend staying with hal in F15 or using some other mechanism? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] FYI: glibc getaddrinfo problem with boot
As systemd is helping get to a fully dynamic plug-n-play world this might interest you. I encounted a problem getting httpd to startup reliably on Fedora 15 because of failures of the getaddrinfo function in glibc. I have raised this bug to track the issue. https://bugzilla.redhat.com/show_bug.cgi?id=721350 Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] FYI: glibc getaddrinfo problem with boot
On Thursday 14 July 2011 12:16:58 Michal Schmidt wrote: On Thu, 14 Jul 2011 12:03:30 +0100 Barry Scott wrote: As systemd is helping get to a fully dynamic plug-n-play world this might interest you. I encounted a problem getting httpd to startup reliably on Fedora 15 because of failures of the getaddrinfo function in glibc. I have raised this bug to track the issue. https://bugzilla.redhat.com/show_bug.cgi?id=721350 Ah yes, the AI_ADDRCONFIG flag... The problem came up before with privoxy: https://bugzilla.redhat.com/show_bug.cgi?id=711587 I'd expect many network aware packages to suffer from this issue. As you say all that was offered is a work around, that in my case will not work. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Documentation: Clarify env var handling
For ExecStart= provide more details on env var substitution
and how that turns into arguments.
For EnvironmentFile= explain that double quotes can be used
to protect whitespace.
Signed-off-by: Barry Scott barry.sc...@onelan.co.uk
---
I think the docs could be improved with the extra
details you provided in you email replay to me about
arguments and the env var handling.
man/systemd.exec.xml|5 +
man/systemd.service.xml | 23 ---
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index b9a37da..7691e00 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -279,6 +279,11 @@
assignments. Empty lines and lines
starting with ; or # will be ignored,
which may be used for commenting. The
+parser for will strip leading and
+trailing whitespace from the values
+of assignments, unless you use
+double quotes ().
+The
argument passed should be an absolute
file name, optionally prefixed with
-, which indicates that if the file
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 4f11020..7e3679d 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -311,18 +311,19 @@
main process of the daemon. The
command line accepts % specifiers as
described in
-
citerefentryrefentrytitlesystemd.unit/refentrytitlemanvolnum5/manvolnum/citerefentry.
On
-top of that basic environment variable
-substitution is supported, where
-literal${FOO}/literal is replaced
-by the string value of the environment
-variable of the same name. Also
-literal$FOO/literal may appear as
-separate word on the command line in
-which case the variable is replaced by
-its value split at whitespaces. Note
+
citerefentryrefentrytitlesystemd.unit/refentrytitlemanvolnum5/manvolnum/citerefentry./para
+paraOn top of that basic environment variable
+substitution is supported. Use
literal${FOO}/literal
+as part of a word, or as word of its own on the
+command line, in which case it will be replaced
+by the value of the env var including all
+whitespace it contains, resulting in 1
argument.
+Use literal$FOO/literal as a separate word
+on the command line, in which case it will be
+replaced by the value of the env var split up
at
+whitespace, resulting in 0 or more arguments.
Note
that the first argument (i.e. the
-binary to execute) may not be a
+program to execute) may not be a
variable, and must be a literal and
absolute path name./para/listitem
/varlistentry
--
1.7.5.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd environment variable handling and spaces bug?
I would like to take advantage of ${var} in the ExecStart lines.
However I find that there is a issue with handling of while space.
If I code this
ExecStart=/myservice --arg ${optional_arg}
If option_arg is not defined argv is ['/myservice', '--arg', '']
Is it a bug that you do not strip trailing whitespace after substituion?
If I code this
ExecStart=/myservice --arg${optional_arg}
and define
option_arg= --debug
argv is ['/myservice', '--arg--debug']
Is it a bug that the whitespace after = was stripped?
Barry
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Services started realtime exit with 214
On Monday 11 July 2011 17:27:26 Lennart Poettering wrote: On Mon, 11.07.11 12:40, Barry Scott (barry.sc...@onelan.co.uk) wrote: Do we have to configure something else to get this working like cgroup stuff? Running X under RR privs? That's bold. It is the only way we found to guarentee that Xorg will keep up with 60Hz frame rates. We found that it is stable in our use at RR. I figure this fails due to the fact that by default we place every service in its own cgroup in the cpu hierarchy, in order to distribute the available CPU time evenly among the available processes. However, because the cpu controller currently isn't that nice to use this breaks RT, since if you create a group to allow it RT you need to assign an RT budget to it, which we however cannot really do, since we cannot come up with any sane default for it. There are two ways out of this: a) disable the implicit sortining into separate cpu cgroups globally, by setting DefaultControllers= (i.e. setting it to the empty string) in /etc/systemd/system.conf or b) disable the automatic creation of a cpu cgroup only for this one service, by placing ControlGroup=cpu:/ in it. I recommend the latter. Done and it works. Thanks. That this is necessary is very unfortunate and I really hope the cpu controller can be fixed one day, so that RT budgets and normal scheduling budgets are independent. I second that. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
