ferm: suggested systemd unit file
I just ran into this: Ferm was not started at boot. Running 'journalctl
-b' revealed the following:
Oct 20 13:18:37 traxus systemd[1]: Found ordering cycle on
basic.target/start
Oct 20 13:18:37 traxus systemd[1]: Found dependency on sysinit.target/start
Oct 20 13:18:37 traxus systemd[1]: Found dependency on ferm.service/start
Oct 20 13:18:37 traxus systemd[1]: Found dependency on
network-online.target/start
Oct 20 13:18:37 traxus systemd[1]: Found dependency on network.target/start
Oct 20 13:18:37 traxus systemd[1]: Found dependency on
systemd-networkd.service/start
Oct 20 13:18:37 traxus systemd[1]: Found dependency on dbus.service/start
Oct 20 13:18:37 traxus systemd[1]: Found dependency on basic.target/start
Oct 20 13:18:37 traxus systemd[1]: Breaking ordering cycle by deleting job
ferm.service/start
Oct 20 13:18:37 traxus systemd[1]: Job ferm.service/start deleted to break
ordering cycle starting with basic.target/start
I am now using the following unit file to start ferm at boot. I use
WantedBy=network.target in the [Install] section because it seems like
a reasonable thing to do, rather than hook into multi-user.target; I
have CCd pkg-systemd-maintainers for a second opinion.
The unit also uses {Wants,Before}=network-pre.target as advised in the
Debian wiki page linked for firewall/network type services in the
original bug report.
[Unit]
Description=ferm firewall configuration
DefaultDependencies=no
Wants=network-pre.target
Before=network-pre.target shutdown.target
Conflicts=shutdown.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/ferm /etc/ferm/ferm.conf
ExecReload=/usr/sbin/ferm /etc/ferm/ferm.conf
ExecStop=/usr/sbin/ferm -F /etc/ferm/ferm.conf
[Install]
WantedBy=network.target
I know you'd prefer to keep backwards-compatibility with
CACHE/FAST/OPTIONS in /etc/default/ferm. You could do so by changing
the unit file to match more closely what is output by 'systemctl cat
ferm.service' on a system that booted with systemd but does _not_ have
a ferm.service unit file in place. The values in [Unit] should be taken
from my example, above, however, or the resulting unit file will not
fix this bug.
The biggest problem with that approach is that you would also pick up
the default handling of DISABLED which is annoying and not necessary
under systemd. Your init script would have to be modified to disregard
the setting for DISABLED when it's being launched by systemd. The
proper way to do that in a /bin/sh script is '[ -d /run/systemd/systemd
]' as used in /lib/lsb/init-functions.d/40-systemd and documented in
sd_booted(3).
Or you could just drop DISABLED which is not even necessary under
sysvinit: 'update-rc.d ferm disable' should work just fine for those
that don't want to rename the symlink in /etc/rcS.d themselves.
--
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
signature.asc
Description: This is a digitally signed message part
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: ferm: suggested systemd unit file
On Tue, 2015-10-20 at 12:34 -0300, Felipe Sateler wrote:
> On 20 October 2015 at 10:23, Sam Morris wrote:
> > I just ran into this: Ferm was not started at boot. Running
> > 'journalctl
> > -b' revealed the following:
> >
> > Oct 20 13:18:37 traxus systemd[1]: Found ordering cycle on
> > basic.target/start
> > Oct 20 13:18:37 traxus systemd[1]: Found dependency on
> > sysinit.target/start
> > Oct 20 13:18:37 traxus systemd[1]: Found dependency on
> > ferm.service/start
> > Oct 20 13:18:37 traxus systemd[1]: Found dependency on
> > network-online.target/start
> > Oct 20 13:18:37 traxus systemd[1]: Found dependency on
> > network.target/start
> > Oct 20 13:18:37 traxus systemd[1]: Found dependency on
> > systemd-networkd.service/start
> > Oct 20 13:18:37 traxus systemd[1]: Found dependency on
> > dbus.service/start
> > Oct 20 13:18:37 traxus systemd[1]: Found dependency on
> > basic.target/start
> > Oct 20 13:18:37 traxus systemd[1]: Breaking ordering cycle by deleting
> > job ferm.service/start
> > Oct 20 13:18:37 traxus systemd[1]: Job ferm.service/start deleted to
> > break ordering cycle starting with basic.target/start
> >
> > I am now using the following unit file to start ferm at boot. I use
> > WantedBy=network.target in the [Install] section because it seems like
> > a reasonable thing to do, rather than hook into multi-user.target; I
> > have CCd pkg-systemd-maintainers for a second opinion.
>
> No, network.target is a synchronization point, not a place to pull
> units from. You should instead use multi-user.target if it is required
> only for normal operation, and sysinit.target if it is required in
> maintainance mode as well. (Is this part unclear in the wiki page? If
> so we should clarify this. Suggestions welcome).
I originally skim-read the wiki page and missed the part where it's
explained that either sysinit.target or multi-user.target should be
used.
> > The unit also uses {Wants,Before}=network-pre.target as advised in the
> > Debian wiki page linked for firewall/network type services in the
> > original bug report.
>
> Well, this will depend on each service. In this case, the original
> init script has Required-Start: $networking which makes it dubious
> that we want to start ferm before the network is configured. (but I do
> not use ferm so I don't know for sure).
I'd want firewall rules to be in place before any other process is able
to start using the network. I think that is the intent of the original
init script being linked into /etc/rcS.d. Hence network-pre.target
sounds right to me.
> I note that upstream ferm already has a service file[1] that does not
> run at early boot. This suggests that the init script should not run
> in runlevel S either.
>
> [1] http://sources.debian.net/src/ferm/2.2-3/ferm.service/
Yes, I saw this. I decided to try to stay closer to the intent of the
existing init script. I guess it's up to the (Debian) maintainer which
gets used. Which, I guess, leaves us with the question of 'should ferm
be started in maintenence mode'?
AIUI the existing init script would be run if booting into single-user
mode, so I'd lean towards sysinit.target, not multi-user.target.
Thanks for the input!
--
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
signature.asc
Description: This is a digitally signed message part
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: ferm: suggested systemd unit file
On Tue, 2015-10-20 at 14:36 -0300, Felipe Sateler wrote:
> > > > The unit also uses {Wants,Before}=network-pre.target as advised in the
> > > > Debian wiki page linked for firewall/network type services in the
> > > > original bug report.
> > >
> > > Well, this will depend on each service. In this case, the original
> > > init script has Required-Start: $networking which makes it dubious
> > > that we want to start ferm before the network is configured. (but I do
> > > not use ferm so I don't know for sure).
> >
> > I'd want firewall rules to be in place before any other process is able
> > to start using the network. I think that is the intent of the original
> > init script being linked into /etc/rcS.d. Hence network-pre.target
> > sounds right to me.
>
> The problem is that at network-pre.target time the interfaces may not
> even exist, if the interfaces are not physical (eg, bridges are set up
> by networkd or ifupdown, which are After=network-pre.target).
It's OK for firewall rules to reference interfaces that don't exist so
I think this isn't a problem.
--
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
signature.asc
Description: This is a digitally signed message part
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#812522: Disable systemd-timesyncd in VirtualBox guests
Package: systemd Version: 228-4 Severity: wishlist File: /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The 'virtualbox-guest-utils' service provides time synchronization with the host when run inside VirtualBox. It might be worth adding ConditionFileIsExecutable=!/usr/sbin/VBoxService to disable-with-time-daemon.conf. - -- Package-specific info: - -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (550, 'stable-updates'), (550, 'stable'), (530, 'testing'), (520, 'unstable'), (510, 'experimental'), (500, 'testing-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.113+nmu3 ii libacl1 2.2.52-2 ii libapparmor12.10-2+b2 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.25.2-6 ii libc6 2.21-6 ii libcap2 1:2.24-8 ii libcap2-bin 1:2.24-8 ii libcryptsetup4 2:1.6.6-5 ii libgcrypt20 1.6.3-2 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b3 ii libmount1 2.27.1-1 ii libpam0g1.1.8-3.1 ii libseccomp2 2.1.1-1 ii libselinux1 2.3-2 ii libsystemd0 228-4 ii mount 2.27.1-1 ii sysv-rc 2.88dsf-59 ii util-linux 2.27.1-1 Versions of packages systemd recommends: ii dbus1.10.6-1 ii libpam-systemd 228-4 Versions of packages systemd suggests: ii systemd-container 228-4 pn systemd-ui Versions of packages systemd is related to: ii udev 228-4 - -- Configuration Files: /etc/systemd/system.conf changed [not included] - -- no debconf information -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJWpPmkAAoJENILQgJc2ie5Y/cP/jLrr7vig5Oc1uLvuQc7do6B 2eOlcVgEnwmzYOTxJ18GnsXqXKPXxzUGTRuuKbblV2V9egk+RcYtZfLpgyAnWW48 NaB3QzwSYdbH9ox/F9insbv9CXrgeKM4UhQApg5ZLAXahU8LhOZoECOfvNlGIaG7 YEgWtuqNJa+oDzFd9RCYulmdtQIaVoBSrsJrAd3+9aqaSzOgVG/3qg09CSLzcSG+ MkKcUKaxjWPkY4Eov1VgiKZoUiH+d1iKbRHIlB3Dza5a/0eXVmCQRy0og7AsvcGK GTi5zpjGMpg3Jj1UMOkey8hAmo7aODTUinRx/AW5V1IUP8XOxNh6bpbBKYtGhCu/ CJiQJT8j8HJExu7M+A6RYKIyydinsIi+S1+pxYqtyAe2YvDKcYrd5fQuU8gfGWve 55DUT1P8zkoRrJ57UeVLZtbzpSSI4J8A02xDgl6bUO5rIaAantPZmJrt2pWPVkUR 3QW1hvK5tENjZIFf2eri/KiDV58tWITC866TPY3KVNSpGuEJpMuzahhm4bczYnwR OzRgITilUdtjaxwosvttBpc0qLUXe7cdec5R6Jq5QtrGoA5QPNxY+txXMpoZrDg3 mXqJjj6FaN6aQAhMN2Qb9r7deJlQH0jI8j5El30n1Ep52BnQRquJ/U1b7oMKNSmJ hP2fVeP2NrrdcHtG0oY2 =qWn6 -END PGP SIGNATURE- ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#816612: systemd: Assertion failure, systemd stopped responding
Package: systemd
Version: 229-2
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Installing an unrelated package failed:
# apt install iptables-nftables-compat
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
arptables ebtables
The following NEW packages will be installed:
arptables ebtables iptables-nftables-compat
0 upgraded, 3 newly installed, 0 to remove and 36 not upgraded.
Need to get 263 kB of archives.
After this operation, 791 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://mirror.unitedcolo.de/debian jessie/main amd64 arptables
amd64 0.0.3.4-1 [35.2 kB]
Get:2 http://ftp.uni-kl.de/debian jessie/main amd64 ebtables amd64
2.0.10.4-3 [103 kB]
Get:3 http://ftp.uni-kl.de/debian stretch/main amd64
iptables-nftables-compat amd64 1.6.0-2 [126 kB]
Fetched 263 kB in 0s (287 kB/s)
Selecting previously unselected package arptables.
(Reading database ... 294499 files and directories currently installed.)
Preparing to unpack .../arptables_0.0.3.4-1_amd64.deb ...
Unpacking arptables (0.0.3.4-1) ...
Selecting previously unselected package ebtables.
Preparing to unpack .../ebtables_2.0.10.4-3_amd64.deb ...
Unpacking ebtables (2.0.10.4-3) ...
Selecting previously unselected package iptables-nftables-compat.
Preparing to unpack .../iptables-nftables-compat_1.6.0-2_amd64.deb ...
Unpacking iptables-nftables-compat (1.6.0-2) ...
Processing triggers for man-db (2.7.0.2-5) ...
Processing triggers for systemd (229-2) ...
Failed to execute operation: Connection timed out
dpkg: error processing package systemd (--unpack):
subprocess installed post-installation script returned error exit
status 1
Errors were encountered while processing:
systemd
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
systemd seems to have stopped reponding to requests. The journal
contains:
Mar 03 13:08:24 wintermute systemd[1]: Reloading.
Mar 03 13:08:24 wintermute systemd[1]: Assertion 'e->key ==
i->next_key' failed at ../src/basic/hashmap.c:634, function
hashmap_iterate_in_internal_order().
Backtrace:
#0 0x7eff584571e0 in do_waitid (options=4, infop=0x7ffe14a37220,
id=3752, idtype=P_PID) at ../sysdeps/unix/sysv/linux/waitid.c:29
resultvar = 18446744073709551104
#1 __waitid (idtype=P_PID, id=3752, infop=0x7ffe14a37220, options=4)
at ../sysdeps/posix/waitid.c:159
oldtype = 0
result =
#2 0x56161efdc463 in wait_for_terminate (pid=3752,
status=) at ../src/basic/process-util.c:474
dummy = {si_signo = -33, si_errno = 0, si_code = 527332192,
_sifields = {_pad = {0, 0, 0, 3, 1480477587, 32511, 0, 0, -1, -1, 33, 0,
788529273, 980314466, 1920169263, 1768059695, 520618315, 22038, 3829353, 98,
1768042298, 110, 0, 127, 520618360, 22038, 346257064, 32766}, _kill = {si_pid =
0, si_uid = 0},
_timer = {si_tid = 0, si_overrun = 0, si_sigval =
{sival_int = 0, sival_ptr = 0x3}}, _rt = {si_pid = 0, si_uid = 0,
si_sigval = {sival_int = 0, sival_ptr = 0x3}}, _sigchld = {si_pid = 0,
si_uid = 0, si_status = 0, si_utime = 139635162237843, si_stime = 0}, _sigfault
= {si_addr = 0x0,
si_addr_lsb = 0}, _sigpoll = {si_band = 0, si_fd = 0},
_sigsys = {_call_addr = 0x0, _syscall = 0, _arch = 3}}}
__PRETTY_FUNCTION__ = "wait_for_terminate"
#3 0x56161f00c0a1 in crash.lto_priv.250 (sig=6) at
../src/core/main.c:199
status = {si_signo = 0, si_errno = 0, si_code = 0, _sifields =
{_pad = {0 }, _kill = {si_pid = 0, si_uid = 0}, _timer =
{si_tid = 0, si_overrun = 0, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _rt
= {si_pid = 0, si_uid = 0, si_sigval = {sival_int = 0, sival_ptr = 0x0}},
_sigchld = {
si_pid = 0, si_uid = 0, si_status = 0, si_utime = 0,
si_stime = 0}, _sigfault = {si_addr = 0x0, si_addr_lsb = 0}, _sigpoll =
{si_band = 0, si_fd = 0}, _sigsys = {_call_addr = 0x0, _syscall = 0, _arch =
0}}}
r =
sa = {__sigaction_handler = {sa_handler = 0x56161efd28a0
, sa_sigaction = 0x56161efd28a0 },
sa_mask = {__val = {0 }}, sa_flags = 268435457, sa_restorer =
0x0}
__func__ = "crash"
__PRETTY_FUNCTION__ = "crash"
#4
No locals.
#5 0x7eff583d2507 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:55
resultvar = 0
pid = 1
selftid = 1
#6 0x00
Bug#816612: systemd: Assertion failure, systemd stopped responding
On Thu, 2016-03-03 at 19:26 +0100, Michael Biebl wrote: > Am 03.03.2016 um 14:47 schrieb Sam Morris: > > > > Package: systemd > > Version: 229-2 > > Severity: important > > > > systemd seems to have stopped reponding to requests. The journal > > contains: > > > > Mar 03 13:08:24 wintermute systemd[1]: Reloading. > > Mar 03 13:08:24 wintermute systemd[1]: Assertion 'e->key == > > i->next_key' failed at ../src/basic/hashmap.c:634, function > > hashmap_iterate_in_internal_order(). > This seems to be an upstream issue and looks like it was already > filed > upstream at https://github.com/systemd/systemd/issues/2676 > > Would be great if you can test the fix from > https://github.com/systemd/systemd/pull/2702 Ah, I didn't consider that bug since I thought it was just for resolved. It's probably the same bug. I don't think I'll be able to reproduce it anyway: I've only seen it once during several years * several machines running systemd. :) -- Sam Morris <https://robots.org.uk/> CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9 signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
lintian: warn when (systemd) service units install themselves into an unusual target
[I used the wrong address in the X-Debbugs-CC pseudoheader, forwarding
manually.]
I noticed that haveged.service installs itself with
WantedBy=default.target, rather than multi-user.target.
This lintian check warns when a service unit is WantedBy=
something other than {sysinit,multi-user,graphical}.target.
Would pkg-systemd-maintainers care to comment on whether this is a good
idea and/or whether there are likely to be too many false positives? I
ran the following on my system:
systemctl --no-legend list-unit-files -t service | while read unit rest; do
w=$(systemctl cat "$unit" | grep ^WantedBy=); for x in $w; do printf '%s %s\n'
$x "$unit"; done; done
and the false positives were from systemd itself, bluez and anacron.
--
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
>From 13fe1c75dae2d64d61adf765478990d5c2c84d4a Mon Sep 17 00:00:00 2001
From: Sam Morris
Date: Tue, 8 Mar 2016 16:11:18 +
Subject: [PATCH] systemd: warn if services are WantedBy= an unusual target
---
checks/systemd.desc | 11 +++
checks/systemd.pm | 7 +++
2 files changed, 18 insertions(+)
diff --git a/checks/systemd.desc b/checks/systemd.desc
index 7c8eddb..dc8ec73 100644
--- a/checks/systemd.desc
+++ b/checks/systemd.desc
@@ -126,3 +126,14 @@ Info: The systemd service file does not contain a Documentation key.
Documentation for systemd service files can be automatically viewed using
systemctl help servicename if this field is present.
Ref: systemd.unit(5)
+
+Tag: systemd-service-wantedby-unusual-target
+Severity: normal
+Certainty: certain
+Info: The systemd service file declares an unusual WantedBy= relationship.
+ .
+ Most services that want to be started automatically at boot should use
+ WantedBy=multi-user.target or WantedBy=graphical.target. Services that want to
+ be started in rescue or single-user mode should instead use
+ WantedBy=sysinit.target.
+Ref: https://wiki.debian.org/Teams/pkg-systemd/rcSMigration
diff --git a/checks/systemd.pm b/checks/systemd.pm
index 69092be..225f153 100644
--- a/checks/systemd.pm
+++ b/checks/systemd.pm
@@ -195,6 +195,13 @@ sub check_systemd_service_file {
unless extract_service_file_values($file, 'Unit', 'Documentation',1);
}
+if ($file =~ /\.service$/) {
+my @wantedby = extract_service_file_values($file, 'Install', 'WantedBy');
+my @unusual_wantedby = grep { /(?
signature.asc
Description: This is a digitally signed message part
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#817998: /lib/x86_64-linux-gnu/libsystemd.so.0: sd_pid_get_session incorrectly(?) returning -ENXIO (sesion does not exist)
Package: libsystemd0 Version: 229-2 Severity: normal File: /lib/x86_64-linux-gnu/libsystemd.so.0 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm trying to work out why I get the following: /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 (polkit-gnome-authentication-agent-1:14272): polkit-gnome-1-WARNING **: Unable to determine the session we are in: No session for pid 14272 This calls sd_pid_get_session on its own pid, which returns -ENXIO. But... I have a session, haven't I? $ loginctl show-session $XDG_SESSION_ID Id=1 User=1000 Name=sam Timestamp=Sat 2016-03-12 09:42:18 GMT TimestampMonotonic=67859194 VTNr=2 Seat=seat0 TTY=/dev/tty2 Remote=no Service=gdm-password Scope=session-1.scope Leader=1785 Audit=1 Type=x11 Class=user Active=yes State=active IdleHint=yes IdleSinceHint=1457700819192000 IdleSinceHintMonotonic=0 Internally, sd_pid_get_session calls cg_pid_get_session on that pid, which calls cg_pid_get_path_shifted, which returns "/user.slice/user-1000.slice/user@1000.service/dbus.service". This path is then passed to cg_path_get_session, which calls cg_path_get_unit on it, resulting in "user@1000.service". cg_path_get_session then bails because this string does not start with "session-". At this point I don't know whether polkit is using the API incorrectly, or whether there is a genuine problem with libsystemd. But the result of cg_pid_get_path_shifted looks strange... the code expects it to look more like "/user.slice/user-1000.slice/session-1.scope". - -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (550, 'stable-updates'), (550, 'stable'), (530, 'testing'), (520, 'unstable'), (510, 'experimental'), (500, 'unstable-debug'), (500, 'testing-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libsystemd0:amd64 depends on: ii libc62.21-9 ii libgcrypt20 1.6.3-2+deb8u1 ii liblzma5 5.1.1alpha+20120614-2+b3 ii libselinux1 2.3-2 libsystemd0:amd64 recommends no packages. libsystemd0:amd64 suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJW5CZzAAoJENILQgJc2ie5zJ4QAMsH+B5zUoQnmHlM7NAzcBdL 1Txt8AcG8U1UpqlRm3ZyLg68/FoJBtm1EJSYMozAkWSWPDi6LPYRB+/SeiQKEcDT x0ipnP7BRNR8T7dBXZhqP0gf1JXbJUgikuUHtY20G0GRKgxU6LWcXjyCNDuP26O1 aIrrvqajnn3+EZ+7SjoFLkhGQoNs4WcKGnfzMC7ZlyMD0AhvflUlXr3Vh7qaI55E 8Cb40GlnmOZkwLoGXFcCJCuMwKOfkxdCLYQcSS9epZh9d/nlYtPyICkiOYD4RZO/ anKCCWeFkJSdyhYfweMDEtbXNdHKMwofF8FeedfKCrAnX1M6qJxspz/hMcVOLDmc JmoG+GV7Xbf1+68ROVQtMVgZONnZ8B4yov/P1iCfxXH7Z4uNwA7UVXn5Qg5bs4id q2tuum5ZgylmvegoIa2xwBLXJHOP3RbyS3IzQRouZT60KnKsNyB0/Jubg5lP/Uze M7EEscTV1xUsaD8/D3VbiaDz5yESVLDIjkHXmA9CSIScIW4hV3TLRgUwmeDFXts0 Hputzsdry2G/mY1y3wHIu+lqGAJo9sZOAGo8Fk9XGeaH/ZVHPZkVmtn0bC9W7ASj LscI3BiyTOZlsaZZO2ZyuaKFn/3lA8r3Dhn8OTmRFRTyQaIPrRmxSjShl9NYxbVs cj15Ch9tH456MwQiNduS =9Jxu -END PGP SIGNATURE- ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#817998: /lib/x86_64-linux-gnu/libsystemd.so.0: sd_pid_get_session incorrectly(?) returning -ENXIO (sesion does not exist)
bts reassign 817998 gnome-terminal bts retitle 817998 gnome-terminal: processes launched via dbus-launched gnome-terminal-server do not have a session and hence are not granted access by polkit found 817998 3.14.1-1+deb8u1 bts forwarded 817998 https://bugzilla.gnome.org/show_bug.cgi?id=759115 thanks This is caused by gnome-terminal's design of spawning all child processes via gnome-terminal-server which is spawned from the user's dbus session. For a 'fun' reproduction, launch nm-connection-editor from gnome- terminal and try to figure out why it doesn't work. :) -- Sam Morris <https://robots.org.uk/> CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9 signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#826045: systemd: Suggested kernel/initramfs-tools integration scripts
Package: systemd Version: 232-25+deb9u1 Tags: + patch Followup-For: Bug #826045 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Here are the scripts I've been using. I've arranged for the initramfs post-update script to run kernel-install in the usual case; the kernel postinst script will only do so if the kernel doesn't use an initrd. The kernel postrm script runs kernel-install in either case. - -- Package-specific info: - -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (550, 'stable-updates'), (550, 'stable-debug'), (550, 'stable'), (530, 'testing'), (520, 'unstable-debug'), (520, 'unstable'), (510, 'experimental-debug'), (510, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3+b1 ii libapparmor12.11.0-3 ii libaudit1 1:2.6.7-2 ii libblkid1 2.29.2-1 ii libc6 2.24-11+deb9u1 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-4 ii libgcrypt20 1.7.6-2+deb9u2 ii libgpg-error0 1.26-2 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-6 ii libkmod223-2 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.2+b1 ii libmount1 2.29.2-1 ii libpam0g1.1.8-3.6 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3+b3 ii libsystemd0 232-25+deb9u1 ii mount 2.29.2-1 ii procps 2:3.3.12-3 ii util-linux 2.29.2-1 Versions of packages systemd recommends: ii dbus1.10.22-0+deb9u1 ii libpam-systemd 232-25+deb9u1 Versions of packages systemd suggests: ii policykit-10.105-18 ii systemd-container 232-25+deb9u1 pn systemd-ui Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.130 ii udev 232-25+deb9u1 - -- Configuration Files: /etc/systemd/journald.conf changed [not included] - -- no debconf information -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEyqqqGsppqDqJKxhV0gtCAlzaJ7kFAlnnmH4SHHNhbUByb2Jv dHMub3JnLnVrAAoJENILQgJc2ie50MMP/Ao8FBd7/2OvVJISkUkjlW1Q1HjcLFtF QMXVgZrRdlxTjEG97z+e9QBvzgST0MKCWN2iM+2C2/RqXfUWDbf6nC9pnPD6gp3d cvf5FS5tVFdLJwAWElUgQbiMlO8ilDyLGzJS0fDjhLy3z0c6qztZ+RVPc36R/nkm eKtdEv0mJkU7+KoiW4M/C9DKnfLvpGtc92bpn9C8WD67l1h8nOLz1l3Uh4gj6zJq tJkw36b02wj8tYbh6FuXeEpZDK8HuCLrqCoTVysUNAiYZF2Of5VaLhsHI90mDpf7 +51xF5rUoV0R6w6LA3fEKbCkWLfsCWocCYBend8vZzH/Fifw2uUcpWAoesg0MdWk 25sZsds0T9mIlfNSWsSR6dDcbDyleJEms14ku9Ira+Qxf0mWvjb+ZUZKfkxwwwUx LQ5RV/b7983ZXax72PslLEJxr/lTAl3YQAcY56A8l3SOybAqeS4KhNAJXv4KFmMz VDr+oOFEoQhBWybgyOXPKVCIGuW0UIeyiKNcWKiiZPosax1e/MvWWxpJ6hgAPV8U yBHbk5VGn/DW3mafsdAuYnPsuQzGY30xq+3EpHm/aCJVkc3MkwBoY7kHXeKyLc59 xaIciIMCKyesRXIjkmFQ6EZbbBzuqVm8OtHrHgnLqs+9qaL9e0BILwgZbmd/JJxV XGmikfqafBdF =jyNI -END PGP SIGNATURE- systemd-boot-integration.tar Description: Unix tar archive ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Bug#744753: anacron: Anacron not triggered when system resumes under systemd
On Tue, Jun 03, 2014 at 08:25:25PM +0200, Lennart Poettering wrote: > On Tue, 03.06.14 05:43, Michael Biebl (bi...@debian.org) wrote: > > > Lennart, do you have better solution for such services which need to be > > restarted on suspend/resume? > > Why would a service need something like this? This sounds systematically > flawed... I'd really try to focus on that and fix the software in question. The service in question, when started, checks to see if any of its cron jobs haven't been run for a specified period, running them if they haven't, then exits. It's intended as a replacement for the daily/weekly/monthly cron jobs, which will not run if your computer is turned off when their time arrives. > > Lennart > -- Sam Morris <https://robots.org.uk/> 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#753576: systemd stopped responding to dbus.socket connections
Package: systemd Version: 204-8~bpo70+1 Severity: normal My desktop has been up for 31 days. Today I noticed I could no longer connect to the system dbus daemon. I'll leave the system up as long as possible in case you need me to get any further information. # dbus-monitor --system Failed to open connection to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused # socat /run/dbus/system_bus_socket /dev/tty 2014/07/03 09:52:43 socat[24226] E connect(3, AF=1 "/run/dbus/system_bus_socket", 29): Connection refused # sudo netstat -A unix -lnp | grep system_bus_socket unix 2 [ ACC ] STREAM LISTENING 7606 1/systemd /var/run/dbus/system_bus_socket # systemctl status dbus.socket dbus.socket - D-Bus System Message Bus Socket Loaded: loaded (/lib/systemd/system/dbus.socket; static) Active: active (running) since Mon 2014-06-02 09:51:06 BST; 1 months 0 days ago Listen: /var/run/dbus/system_bus_socket (Stream) Jun 02 09:51:06 oxylus systemd[1]: Starting D-Bus System Message Bus Socket. Jun 02 09:51:06 oxylus systemd[1]: Listening on D-Bus System Message Bus Socket. # systemctl status dbus.service dbus.service - D-Bus System Message Bus Loaded: loaded (/lib/systemd/system/dbus.service; static) Active: active (running) since Mon 2014-06-02 09:51:06 BST; 1 months 0 days ago Main PID: 1124 (dbus-daemon) CGroup: name=systemd:/system/dbus.service ├─1124 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation ├─1566 /usr/sbin/modem-manager └─1680 /usr/lib/accountsservice/accounts-daemon Jul 03 07:56:16 oxylus dbus-daemon[1124]: dbus[1124]: [system] Activated service 'org.freedesktop.PackageKit' failed: Process /usr/lib/dbus-1.0/dbus-daemon-launch-helper received signal 5 Jul 03 07:56:16 oxylus dbus[1124]: [system] Activated service 'org.freedesktop.PackageKit' failed: Process /usr/lib/dbus-1.0/dbus-daemon-launch-helper received signal 5 Jul 03 08:56:16 oxylus dbus-daemon[1124]: dbus[1124]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) Jul 03 08:56:16 oxylus dbus[1124]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) Jul 03 08:56:16 oxylus dbus-daemon[1124]: (packagekitd:22845): GLib-GIO-CRITICAL **: g_dbus_proxy_new_sync: assertion `G_IS_DBUS_CONNECTION (connection)' failed Jul 03 08:56:16 oxylus dbus-daemon[1124]: (packagekitd:22845): GLib-GObject-WARNING **: invalid (NULL) pointer instance Jul 03 08:56:16 oxylus dbus-daemon[1124]: (packagekitd:22845): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed Jul 03 08:56:17 oxylus dbus-daemon[1124]: (packagekitd:22845): PackageKit-ERROR **: failed to get pokit authority: Error initializing authority: Could not connect: Connection refused Jul 03 08:56:17 oxylus dbus-daemon[1124]: dbus[1124]: [system] Activated service 'org.freedesktop.PackageKit' failed: Process /usr/lib/dbus-1.0/dbus-daemon-launch-helper received signal 5 Jul 03 08:56:17 oxylus dbus[1124]: [system] Activated service 'org.freedesktop.PackageKit' failed: Process /usr/lib/dbus-1.0/dbus-daemon-launch-helper received signal 5 -- Package-specific info: -- systemd-delta: -- [MASKED] /etc/udev/rules.d/75-cd-aliases-generator.rules → /lib/udev/rules.d/75-cd-aliases-generator.rules 1 overridden configuration files found. -- systemctl dump: -- -- Contents of /var/lib/systemd/deb-systemd-helper-enabled: -- ==> /var/lib/systemd/deb-systemd-helper-enabled/anacron.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/anacron.service ==> /var/lib/systemd/deb-systemd-helper-enabled/ssh.socket.dsh-also <== /etc/systemd/system/sockets.target.wants/ssh.socket ==> /var/lib/systemd/deb-systemd-helper-enabled/ssh.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/ssh.service /etc/systemd/system/sshd.service ==> /var/lib/systemd/deb-systemd-helper-enabled/sshd.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/syslog.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/rsyslog.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/syslog.service ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/ssh.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/rsyslog.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/anacron.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/docker.io.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/docker.io.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/d
Bug#753576: systemd stopped responding to dbus.socket connections
On Thu, Jul 03, 2014 at 12:30:14PM +0200, Michael Biebl wrote: > If dbus is running (and it apparently is), then it should be the process > listening on /var/run/dbus/system_bus_socket. I'm not sure about that... on another system where dbus is currently working fine: # netstat -A unix -lnp | grep dbus unix 2 [ ACC ] STREAM LISTENING 7809 1/systemd /var/run/dbus/system_bus_socket > Does strace -p 1124 reveal anything useful? I ran strace on both dbus and systemd. Both remain sleeping epoll_wait during the attempt to connect to the socket. -- Sam Morris <https://robots.org.uk/> 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#753576: systemd stopped responding to dbus.socket connections
On Thu, Jul 03, 2014 at 01:35:59PM +0200, Michael Biebl wrote: > Am 03.07.2014 13:03, schrieb Sam Morris: > > On Thu, Jul 03, 2014 at 12:30:14PM +0200, Michael Biebl wrote: > >> If dbus is running (and it apparently is), then it should be the process > >> listening on /var/run/dbus/system_bus_socket. > > > > I'm not sure about that... on another system where dbus is currently > > working fine: > > > > # netstat -A unix -lnp | grep dbus > > unix 2 [ ACC ] STREAM LISTENING 7809 1/systemd > >/var/run/dbus/system_bus_socket > > Well, the socket was opened by systemd, but they've been handed over to > dbus-daemon and incoming requests on the socket should be processed by > dbus-daemon. Ah, so the output of netstat is misleading for .socket units. I did more testing with strace and, on the working system, connecting to the socket with socat does indeed only wake up the dbus process, not systemd. > If you restart dbus.service (probably not a good idea to do that from > within the X session), does the problem go away? > > But before you do restart dbus, Simon, do you have any ideas how to > debug this further? Ok, I'll wait before trying this. -- Sam Morris <https://robots.org.uk/> 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
