Package: systemd
Version: 242-8~bpo10
Severity: important
listing the contents of systemd_242-8~bpo10+1_amd64.deb shows that
org.freedesktop.systemd1.service is missing from this package
please add this service file as it is needed for systemctl --user commands
thanks
Bugreport relayed to the dbus package, immediately closes bug with the
following response,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945561
""
Even if systemd --user was suitable for being started by a D-Bus service
file org.freedesktop.systemd1.service, it would be systemd (not dbus)
tha
somehow it got fixed with-> "dbus-launch systemctl --user"
for some reason that did something and I now just use "systemctl --user"
(even after a reboot)
I'm able to see user-specific unit files I created in
~/.config/systemd/user , so I know I am really looking at the user
context entries..
somehow it got fixed with-> "dbus-launch systemctl --user"
for some reason that did something and I now just use "systemctl --user"
(even after a reboot)
I'm able to see user-specific unit files I created in
~/.config/systemd/user , so I know I am really looking at the user
context entries..
ce in /etc/systemd/user is not getting
overrided by ~/.config/systemd/user
$ systemd-analyze --user unit-paths
/home/westlake/.config/systemd/user.control
/run/user/1000/systemd/user.control
/run/user/1000/systemd/transient
/run/user/1000/systemd/generator.early
/home/westlake/.config/systemd/user
/e
Package: systemd
Version: 247.3-6
Severity: normal
Upon booting up with "systemd.unit=emergency.target" to the kernel
bootline, there are no systemd-journald services running.
However if the user boots normally into multi-user or graphical targets,
and types "systemctl isolate emergency" or "
Package: systemd
Version: 247.3-6
Severity: important
systemd-networkd causes issues around services that do not have
"network-online.target" as part of "Wanted=" in their unit file.
For example,
apache2.service has the following under their [Unit] in apache2.service,
"After=network.target re
On 2021-11-15 10:10 a.m., Michael Biebl wrote:
I think, what you see is that systemd-journald.service *is* actually
stopped when you run `systemctl emergency`.
systemctl isolate emergency and systemctl emergency have the same
results unfortunately..
Could you check the following:
- When you
Package: systemd
Version: 247.3
Severity: normal
"systemctl isolate emergency" fails to stop systemd-journald..
it's not an upstream issue since the problem does not occurr with other
distributions.
having systemd-journald to be stopped is desirable since the
administrator can then use e2fsc