Re: [systemd-devel] Antw: Re: Antw: Re: failing unmounts during reboot
>>> Lennart Poettering schrieb am 29.07.2019 um 14:16
in
Nachricht <20190729121614.GG19185@gardel-login>:
> On Mo, 29.07.19 14:14, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de)
> wrote:
>
>> OK: The "abandoned" scope most likely is a daemon process started in an
>> interactive session that does no longer exist ("logout").
>> Is there a command to display the actual processes abelonging to each
scope?
>
> Use "systemctl status" on a service, scope, mount, swap, … unit to see
> the processes belonging to it.
OK, I didn't know that it also works for non-units (or units I didn't know
that they are units). I could confirm that the abandoned state refers to a user
process that is still running in the background.
>
> Use "systemd-cgls" to get an idea of the tree organization of the
> cgroup tree, showing all its service, scope, … units.
OK & Thanks!
Regards,
Ulrich
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] KExecWatchdogSec NEWS entry needs work
Particularly the following sentence: This option defaults to off, since it depends on drivers and software setup whether the watchdog is correctly reset again after the kexec completed, and thus for the general case not clear if safe (since it might cause unwanted watchdog reboots after the kexec completed otherwise). I can't quite work out what intent is, otherwise I'd take a stab myself. -- Clinton Roy Senior Scientific Software Engineer Australian Synchrotron ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Logs from a service is not showing up in journalctl but showing up in syslog
On Do, 25.07.19 19:16, Debraj Manna (subharaj.ma...@gmail.com) wrote: > Thanks Mantas for replying. > > ExecStartPre=-/bin/su ubuntu -c "/home/ubuntu/build-target/ > kafka/kafka-systemd-prestart.sh" > ExecStart=/bin/su ubuntu -c "/home/ubuntu/build-target/ > kafka/kafka-systemd-health.sh" > ExecStopPost=-/bin/bash /home/ubuntu/build-target/ > kafka/kafka-systemd-poststop.sh > > If I specify User= then all the scripts will be executed with that user. > Can you let me know if I only need to execute > kafka-systemd-prestart.sh and kafka-systemd-health.sh > with let's say ubuntu user and kafka-systemd-poststop.sh with root user > what is the recommended way to do this? Use "ExecStartPre=+…" for running some ExecXYZ= lines with full privileges. See documentation for details. You may combine "+" and "-" if you like. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Logs from a service is not showing up in journalctl but showing up in syslog
On Do, 25.07.19 14:20, Mantas Mikulėnas (graw...@gmail.com) wrote: > Take a look at `journalctl -o verbose SYSLOG_IDENTIFIER=su _PID=38464`. > > I suspect the messages *are* in the journal, just not tagged with > UNIT=kafka.service anymore. In some distros, `su` is actually configured to > call pam_systemd and set up a new systemd-logind session – when this > happens, the process is moved out of kafka.service into a user session > scope, and its syslog messages are grouped accordingly. It shouldn't just be "some distros" btw, it hopefully should be all. Everything else would be a bug. > Consider replacing `su` with `runuser`, or indeed with systemd's [Service] > User= option. "runuser" creates a PAM session too. "setpriv" is the command to use. (Yes don't ask me why we have all three of su, runuser and setpriv being different but also the same...) Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Logs from a service is not showing up in journalctl but showing up in syslog
On Do, 25.07.19 15:55, Debraj Manna (subharaj.ma...@gmail.com) wrote: > I have unit file which looks like below. I am seeing some of the echo are > showing up in syslog but not in journalctl. Can someone let me know what is > going on? > systemd version 229 running on Ubuntu 16. > > ExecStartPre=-/bin/su ubuntu -c > "/home/ubuntu/build-target/kafka/kafka-systemd-prestart.sh" > ExecStart=/bin/su ubuntu -c > "/home/ubuntu/build-target/kafka/kafka-systemd-health.sh" If you use "su" this creates a new login session (and thus a scope unit) for your program, and thus any processes/logs will be associated with that login session scope unit, and not with the service unit you are writing here. Use "User=" to run services under specific user identities. Or at least use "setpriv" rather than "su" since the former just changes privs, but doesn't actually acquire a PAM session and everything. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Health check for a service managed by systemd
On Fr, 26.07.19 19:07, Debraj Manna (subharaj.ma...@gmail.com) wrote: > Thanks Reindl for replying. > > Can we make use of the watchdog & systemd-notify functionality of systemd? > I mean something like this. > > [Unit] > Description=Test service > After=network.target > > [Service] > Type=notify > # test.sh wrapper script to call the service > ExecStart=/opt/test/test.sh > Restart=always > RestartSec=1 > TimeoutSec=5 > WatchdogSec=5 > > [Install] > WantedBy=multi-user.target > > Then in test.sh can we do something like > > #!/bin/bash > trap 'kill $(jobs -p)' EXIT > > # Start the actual service > /opt/test/service & > PID=$! > > /bin/systemd-notify --ready > while(true); do > FAIL=0 > kill -0 $PID > if [[ $? -ne 0 ]]; then FAIL=1; fi > > #curl http://localhost/test/ > #if [[ $? -ne 0 ]]; then FAIL=1; fi > > if [[ $FAIL -eq 0 ]]; then /bin/systemd-notify WATCHDOG=1; fi > > sleep 1 > done Hmm, I am not sure how I feel about such uses for WATCHDOG=1. The assumpion is always that his comes from the app itself as a hang check. But this isn't really like that, hence I'd advise against this, but of course, it's up to you how you solve this... Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: failing unmounts during reboot
On Mo, 29.07.19 14:14, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:
> OK: The "abandoned" scope most likely is a daemon process started in an
> interactive session that does no longer exist ("logout").
> Is there a command to display the actual processes abelonging to each scope?
Use "systemctl status" on a service, scope, mount, swap, … unit to see
the processes belonging to it.
Use "systemd-cgls" to get an idea of the tree organization of the
cgroup tree, showing all its service, scope, … units.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: failing unmounts during reboot
>>> Lennart Poettering schrieb am 29.07.2019 um 14:11
in
Nachricht <20190729121150.GE19185@gardel-login>:
> On Mo, 29.07.19 14:05, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de)
> wrote:
>
>> > Key here is that these scope units are ordered after
>> > systemd‑user‑sessions.service, which also means they are terminated
>> > before that service is terminated (since in systemd the shutdown order
>> > is always the inverse of the startup order).
>>
>> I'm afraid the original answer was wrong: "We automatically kill all
unpriv
>> user programs on shutdown."
>>
>> If a user started a process outside of systemd, systemd does not
>> list that.
>
> I am not sure what "outside of systemd" is supposed to mean? If
> systemd is PID 1 all userspace runs under systemd's supervision.
>
>> I'm also surprised who _few_ scopes are being shown:
>
> How many should be there? It shows active sessions. i.e. for each
> entry in "loginctl list-sessions"'s output one (plus one for each
> session that ended but still has processes running, i.e. is abandoned,
> see below).
>
> Consider using "systemd-cgls" to see the general structure of your
> system in regards to services, scopes and such.
>
>> 3 loaded units listed.
>> To show all installed unit files use 'systemctl list-unit-files'.
>>
>> Where is the rest?
>
> Not sure what the "rest" is supposed to mean.
>
>> Also, the "abandonded" session has a process that is very much active:
>
> An "abandoned" scope is one the app that created it has lost interest
> in or died. logind is one such app, and as mentioned creates a scope
> unit for each session. And it abandons the scope for a session it
> manages when a session ends but there are still processes in the scope
> left.
OK: The "abandoned" scope most likely is a daemon process started in an
interactive session that does no longer exist ("logout").
Is there a command to display the actual processes abelonging to each scope?
>
> Lennart
>
> --
> Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Antw: failing unmounts during reboot
On Mo, 29.07.19 14:08, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > >> And just repeating the unmount without further actions is not a > >> hack? > > > > Hmm? we tend to give up when we can't unmount something, log about it > > and go on. We also have a second shutdown phase, which is a dumb and > > brutal kill/umount loop that kills remaining processes and removes > > mounts in a tight loop until nothing changes anymore. This second > > phase is a safety net only though: it takes care of stuff that somehow > > survive the first phase, i.e. the clean phase. > > > >> Why not stop when unmount fails? > > > > We do that. > > But it seems to be a better idea for the second phase to kill processes > blocking unmount. Hmm? The second phase kills *all* processes still remaining, in a tight loop, under the assumption this will unblock mounts. When it notices that doing so doesn#t help it eventually gives up too... But again, the second phase is just a safety net, it should only get involved if there are issues with the first phase. If the first phase works correctly the second phase does exactly nothing anymore. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: failing unmounts during reboot
On Mo, 29.07.19 14:05, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > > Key here is that these scope units are ordered after > > systemd‑user‑sessions.service, which also means they are terminated > > before that service is terminated (since in systemd the shutdown order > > is always the inverse of the startup order). > > I'm afraid the original answer was wrong: "We automatically kill all unpriv > user programs on shutdown." > > If a user started a process outside of systemd, systemd does not > list that. I am not sure what "outside of systemd" is supposed to mean? If systemd is PID 1 all userspace runs under systemd's supervision. > I'm also surprised who _few_ scopes are being shown: How many should be there? It shows active sessions. i.e. for each entry in "loginctl list-sessions"'s output one (plus one for each session that ended but still has processes running, i.e. is abandoned, see below). Consider using "systemd-cgls" to see the general structure of your system in regards to services, scopes and such. > 3 loaded units listed. > To show all installed unit files use 'systemctl list-unit-files'. > > Where is the rest? Not sure what the "rest" is supposed to mean. > Also, the "abandonded" session has a process that is very much active: An "abandoned" scope is one the app that created it has lost interest in or died. logind is one such app, and as mentioned creates a scope unit for each session. And it abandons the scope for a session it manages when a session ends but there are still processes in the scope left. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Antw: failing unmounts during reboot
>>> Lennart Poettering schrieb am 29.07.2019 um 13:55 in Nachricht <20190729115524.GB19185@gardel-login>: > On Mo, 29.07.19 08:16, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) > wrote: > >> >>> Lennart Poettering schrieb am 25.07.2019 um 13:37 >> in >> Nachricht <20190725113724.GC12912@gardel-login>: >> > On Do, 25.07.19 12:52, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) >> wrote: >> > >> >> > "try to kill all processes using a filesystem before unmounting it" >> >> > isn't that easy when it comes to namespaces, "lsof" even don't tell you >> >> > the root cause preventing unmount but the ernel still refuses to do so >> >> >> >> Does systemd even try to use lsof? >> > >> > No, of course not. We tend to avoid hacks like that. >> >> And just repeating the unmount without further actions is not a >> hack? > > Hmm? we tend to give up when we can't unmount something, log about it > and go on. We also have a second shutdown phase, which is a dumb and > brutal kill/umount loop that kills remaining processes and removes > mounts in a tight loop until nothing changes anymore. This second > phase is a safety net only though: it takes care of stuff that somehow > survive the first phase, i.e. the clean phase. > >> Why not stop when unmount fails? > > We do that. But it seems to be a better idea for the second phase to kill processes blocking unmount. > > Lennart > > -- > Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: failing unmounts during reboot
On Mo, 29.07.19 08:38, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > Sorry I hit "send" too quickly: > That would mean the problem of not being unable to umnount /home is not that > the network is down, but that some process still has open files on /home. > > However from the original problem report: > > [ OK ] Stopped target Host and Network Name Lookups. >Stopping Name Service Cache Daemon... > [ OK ] Stopped target Network. >Stopping wicked managed network interfaces... > [ OK ] Stopped Name Service Cache Daemon. > [ OK ] Stopped wicked managed network interfaces. >Stopping wicked network nanny service... > [ OK ] Stopped Check if the profile matches the system. > [ OK ] Stopped wicked network nanny service. >Stopping wicked network management service daemon... > [ OK ] Stopped wicked network management service daemon. >Stopping wicked DHCPv4 supplicant service... >Stopping wicked AutoIPv4 supplicant service... >Stopping wicked DHCPv6 supplicant service... > [ OK ] Stopped wicked DHCPv4 supplicant service. > [ OK ] Stopped wicked DHCPv6 supplicant service. > [ OK ] Stopped wicked AutoIPv4 supplicant service. >Stopping D-Bus System Message Bus... > [ OK ] Stopped SuSEfirewall2 phase 1. > [ OK ] Stopped D-Bus System Message Bus. > [ OK ] Stopped target Basic System. > [ OK ] Stopped target Sockets. > ... I would call that a "network shutdown"... > [ OK ] Stopped target Host and Network Name Lookups. >Stopping Name Service Cache Daemon... > [ OK ] Stopped target Network. >Stopping wicked managed network interfaces... > [ OK ] Stopped Name Service Cache Daemon. > [ OK ] Stopped wicked managed network interfaces. >Stopping wicked network nanny service... > [ OK ] Stopped Check if the profile matches the system. > [ OK ] Stopped wicked network nanny service. >Stopping wicked network management service daemon... > [ OK ] Stopped wicked network management service daemon. >Stopping wicked DHCPv4 supplicant service... >Stopping wicked AutoIPv4 supplicant service... >Stopping wicked DHCPv6 supplicant service... > [ OK ] Stopped wicked DHCPv4 supplicant service. > [ OK ] Stopped wicked DHCPv6 supplicant service. > [ OK ] Stopped wicked AutoIPv4 supplicant service. >Stopping D-Bus System Message Bus... > [ OK ] Stopped SuSEfirewall2 phase 1. > [ OK ] Stopped D-Bus System Message Bus. > [ OK ] Stopped target Basic System. > [ OK ] Stopped target Sockets. > ... > I don't see unmounting of /home at all. The unmount errors reported were: > ... > [ OK ] Unmounted Lock Directory. > [FAILED] Failed unmounting Runtime Directory. >Unmounting /var... > [ OK ] Unmounted /opt. > [ OK ] Stopped File System Check on /dev/v04/opt. > [FAILED] Failed unmounting /var. > [ OK ] Stopped File System Check on /dev/v04/var. > (The /var thing has different reasons) > ... > [ OK ] Stopped Remount Root and Kernel File Systems. > [ OK ] Reached target Shutdown. > ...At this point nothing more happened... > Shutdown did not complete within two and a half minute. > > I don't understand. > 2019-04-17T13:20:01.313610+02:00 v04 systemd[32708]: Stopped target Default. > 2019-04-17T13:20:01.320158+02:00 v04 systemd[32708]: Stopped target Basic > System. > 2019-04-17T13:20:01.320715+02:00 v04 systemd[32708]: Stopped target Paths. > 2019-04-17T13:20:01.321092+02:00 v04 systemd[32708]: Stopped target Sockets. > 2019-04-17T13:20:01.321459+02:00 v04 systemd[32708]: Stopped target Timers. > 2019-04-17T13:20:01.321835+02:00 v04 systemd[32708]: Reached target Shutdown. > 2019-04-17T13:20:01.322197+02:00 v04 systemd[32708]: Starting Exit the > Session... Please have a look at https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1. i.e. turn on debugging log output via kernel cmdline option and collect the data in the shutdown hook. This should be helpful. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: failing unmounts during reboot
>>> Lennart Poettering schrieb am 29.07.2019 um 13:53 in Nachricht <20190729115308.GA19185@gardel-login>: > On Mo, 29.07.19 08:17, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) wrote: > >> >> What this "solution" fails to see is that any user can start a >> >> process that may prevent clean unmount. It's completely far away >> >> from reality to believe that such a user will write (or even know >> >> how to write) a systemd service! >> > >> > We automatically kill all unpriv user programs on shutdown. >> >> Which part of systemd does that? And is that "rather new"? > > PID 1 does that. All sessions are managed as so called "scope" units > by PID 1, that's why they show up in "systemct ‑t scope". These scope > units are ordered so that they are terminated before the system goes > down. For example, I am currently logged in as session "1" on my > machine, hence: > > > $ systemctl cat session‑1.scope > # /run/systemd/transient/session‑1.scope > # This is a transient unit file, created programmatically via the systemd > API. Do not edit. > [Scope] > Slice=user‑1000.slice > > [Unit] > Description=Session 1 of user lennart > Wants=user‑runtime‑dir@1000.service > Wants=user@1000.service > After=systemd‑logind.service > After=systemd‑user‑sessions.service > After=user‑runtime‑dir@1000.service > After=user@1000.service > RequiresMountsFor=/home/lennart > > [Scope] > SendSIGHUP=yes > TasksMax=infinity > > > Key here is that these scope units are ordered after > systemd‑user‑sessions.service, which also means they are terminated > before that service is terminated (since in systemd the shutdown order > is always the inverse of the startup order). I'm afraid the original answer was wrong: "We automatically kill all unpriv user programs on shutdown." If a user started a process outside of systemd, systemd does not list that. I'm also surprised who _few_ scopes are being shown: # systemctl -t scope --all UNIT LOAD ACTIVE SUB DESCRIPTION init.scope loaded active running System and Service Manager session-178.scope loaded active abandoned Session 178 of user windl session-3180.scope loaded active running Session 3180 of user windl 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. 3 loaded units listed. To show all installed unit files use 'systemctl list-unit-files'. Where is the rest? Also, the "abandonded" session has a process that is very much active: # cat /proc/16413/cgroup 12:freezer:/ 11:hugetlb:/ 10:rdma:/ 9:cpuset:/ 8:memory:/ 7:devices:/user.slice 6:perf_event:/ 5:pids:/user.slice/user-1025.slice/session-178.scope 4:net_cls,net_prio:/ 3:cpu,cpuacct:/ 2:blkio:/ 1:name=systemd:/user.slice/user-1025.slice/session-178.scope I still fail to understand. Regards, Ulrich Windl ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: failing unmounts during reboot
On Mo, 29.07.19 08:23, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > >>> Frank Steiner schrieb am 25.07.2019 um > >>> 14:14 in > Nachricht <913a3c04-a666-b44b-c6ec-fe3d8a7fe...@bio.ifi.lmu.de>: > > Ulrich Windl wrote: > > > >> *1: I have a support call open with SUSE: > >> Before systemd (almost) all processes were killed before unmounting. > >> With systemd I'm seeing excessive reboot delays due to unmount timing out. > > For example if you have a process started from NFS that has a log file on > > NFS > > open, too. > >> It seems the order is roughly like this: > >> 1) Shutdown the network > >> 2) Try unmounting filesystems, including NFS > >> 3) Kill remaining processes > > > > I cannot confirm that, at least not for SLES/D 15. All mount units > > for NFS filesystems created from fstab get "Before=remote-fs.target", > > so they are shutdown before the network goes down. Check in > > /run/systemd/generator to see if this entry is missing in your units. > > In SLES12 SP4 (originally reported for SP3) I have: > # Automatically generated by systemd-fstab-generator > > [Unit] > SourcePath=/etc/fstab > Documentation=man:fstab(5) man:systemd-fstab-generator(8) > Before=remote-fs.target > > [Mount] > What=server:/exports/home > Where=/home > Type=nfs Note that PID 1 adds in further, automatic dependencies that just these. See "systemctl show home.mount -p After". Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Antw: failing unmounts during reboot
On Mo, 29.07.19 08:16, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > >>> Lennart Poettering schrieb am 25.07.2019 um 13:37 > in > Nachricht <20190725113724.GC12912@gardel-login>: > > On Do, 25.07.19 12:52, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) > wrote: > > > >> > "try to kill all processes using a filesystem before unmounting it" > >> > isn't that easy when it comes to namespaces, "lsof" even don't tell you > >> > the root cause preventing unmount but the ernel still refuses to do so > >> > >> Does systemd even try to use lsof? > > > > No, of course not. We tend to avoid hacks like that. > > And just repeating the unmount without further actions is not a > hack? Hmm? we tend to give up when we can't unmount something, log about it and go on. We also have a second shutdown phase, which is a dumb and brutal kill/umount loop that kills remaining processes and removes mounts in a tight loop until nothing changes anymore. This second phase is a safety net only though: it takes care of stuff that somehow survive the first phase, i.e. the clean phase. > Why not stop when unmount fails? We do that. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: failing unmounts during reboot
On Mo, 29.07.19 08:17, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > >> What this "solution" fails to see is that any user can start a > >> process that may prevent clean unmount. It's completely far away > >> from reality to believe that such a user will write (or even know > >> how to write) a systemd service! > > > > We automatically kill all unpriv user programs on shutdown. > > Which part of systemd does that? And is that "rather new"? PID 1 does that. All sessions are managed as so called "scope" units by PID 1, that's why they show up in "systemct -t scope". These scope units are ordered so that they are terminated before the system goes down. For example, I am currently logged in as session "1" on my machine, hence: $ systemctl cat session-1.scope # /run/systemd/transient/session-1.scope # This is a transient unit file, created programmatically via the systemd API. Do not edit. [Scope] Slice=user-1000.slice [Unit] Description=Session 1 of user lennart Wants=user-runtime-dir@1000.service Wants=user@1000.service After=systemd-logind.service After=systemd-user-sessions.service After=user-runtime-dir@1000.service After=user@1000.service RequiresMountsFor=/home/lennart [Scope] SendSIGHUP=yes TasksMax=infinity Key here is that these scope units are ordered after systemd-user-sessions.service, which also means they are terminated before that service is terminated (since in systemd the shutdown order is always the inverse of the startup order). Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd.journald.forward_to doesn't forward all journal messages
On So, 28.07.19 22:11, Chris Murphy (li...@colorremedies.com) wrote: > Using either of the following: > > systemd.log_level=debug systemd.journald.forward_to_kmsg log_buf_len=8M > > systemd.log_level=debug systemd.log_target=kmsg log_buf_len=8M Note that this is not sufficient. You also have to pass "printk.devkmsg=on" too, otherwise the kernel ratelimits log output from usperspace ridiculously a lot, and you will see lots of dropped messages. I have documented this now here: https://github.com/systemd/systemd/pull/13208 Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: device enumeration by systemd user instances
On Mon, Jul 29, 2019 at 08:57:26AM +0200, Ulrich Windl wrote: > >>> Greg KH schrieb am 25.07.2019 um 17:45 in > Nachricht <20190725154555.ga6...@kroah.com>: > > On Thu, Jul 25, 2019 at 05:29:33PM +0200, Pawel Szewczyk wrote: > >> On 7/17/19 23:14, Greg KH wrote: > >> > > >> > 100ms seems like a really long time, what exactly is it doing during > >> > that time? Is the kernel spending too much time regenerating the > >> > uevents? > >> > > >> > How many devices are you talking about? Any chance to see what really > >> > is happening here by running perf to see where the hot-spots are? > >> > >> There are ~80 devices being enumerated and 1ms per device still seem a > >> little too long. Note, that we are running this on arm architecture. > > I wonder: Doesn't that depend on the individual devices? I can > remember that "Scanning the SCSI bus" in HP-UX had always been a > matter of minutes... This _after_ the devices are all found by the kernel, not before :) And odds are, if this is a random ARM device, these are all platform devices and there should not be any bus scannning time involved by the kernel as all of the device information is available in the DT file ahead of time. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is fd = journal_fd() common across all daemons
On So, 28.07.19 21:25, Vaibhav Dahiya (vdah...@ncsu.edu) wrote: > Hello , > > My question is related to changing some flags on fd = journal_fd(), > basically > I want to make this socket descriptor to get a flag for non-blocking. > As I am preparing a patch for this. I have generic query , is this common > across all the daemons ? > Meaning setting a flag to fd will likely cause each daemon to take > necessary > provisions like message drops etc ? > Looking at the code i could not get a clarity so I just wanted to ask. No, each client linking to libsystemd gets its own socket fd. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
