Your message dated Tue, 17 Nov 2015 11:55:42 +0000 with message-id <[email protected]> and subject line Re: Bug#805351: dbus: dbus can not launch after testing/stable downgrade has caused the Debian Bug report #805351, regarding dbus: dbus can not launch after testing/stable downgrade to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 805351: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805351 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: dbus Version: 1.8.20-0+deb8u1 Severity: normal Dear Maintainer, I've been using the testing/(partially sid) debian release for a long time but after scheduled upgrade of the system some strange troubles with drivers made my X subsystem unusable so I decided to switch back to stable from testing. When I've made `apt-get upgrade && apt-get dist-upgrade` in order to switch back to stable the system hung after reload on a particular systemd waiting for a LSB start. It waited for some LSBs start all of which were dependents of the dbus. So I warned to check the dbus configuration and started system in old sysvinit manner (--init=/bin/bash) and investigated that the dbus cannot launch. I've called /etc/init.d/dbus start and it continuously told me than there are no /proc/filesystem mount. As soon as I've opened the /etc/init.d/dbus in editor I found that it stops on a line 53 where command `mountpoint` is called to check if the /proc/ is a valid mountpoint. Then I've checked the `mountpoint` command and there was no such a command at all. I think that there are some troubles with an `util-linux` package, which is not directly included into dbus package deps list. The package systemd should implement overall dependency of `util-linux` to cover all nested packages as a dbus but there was somehting strange in downgrade process that broke this dependency chain so the downgrade of system (and the (accidental?) removal of `mountpoint`) affected the init process such a weird way. I've removed the /proc/ check in order for proper init and after system loaded checked that there were no broken deps nor package `util-linux` uninstalled while upgrading. So may there be a check of `mountpoint` existence added to avoid such an weird (not unexpected but confusing behaviour)? * I've changed some files while investigating (symlinks remap almost) so the reportbug may include such a files in this report. -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (1001, 'stable'), (1000, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dbus depends on: ii adduser 3.113+nmu3 ii libaudit1 1:2.4-1+b1 ii libc6 2.19-18+deb8u1 ii libcap-ng0 0.7.4-2 ii libdbus-1-3 1.8.20-0+deb8u1 ii libexpat1 2.1.0-6+deb8u1 ii libselinux1 2.3-2 ii libsystemd0 215-17+deb8u2 ii lsb-base 4.1+Debian13+nmu1 dbus recommends no packages. Versions of packages dbus suggests: ii dbus-x11 1.8.20-0+deb8u1 Versions of packages dbus is related to: ii dbus-x11 1.8.20-0+deb8u1 ii systemd 215-17+deb8u2 ii systemd-sysv 215-17+deb8u2 -- Configuration Files: /etc/dbus-1/session.conf changed: <!-- This configuration file controls the per-user-login-session message bus. Add a session-local.conf and edit that rather than changing this file directly. --> <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";> <busconfig> <!-- Our well-known bus type, don't change this --> <type>session</type> <!-- If we fork, keep the user's original umask to avoid affecting the behavior of child processes. --> <keep_umask/> <listen>unix:tmpdir=/tmp</listen> <!-- On Unix systems, the most secure authentication mechanism is EXTERNAL, which uses credential-passing over Unix sockets. This authentication mechanism is not available on Windows, is not suitable for use with the tcp: or nonce-tcp: transports, and will not work on obscure flavours of Unix that do not have a supported credentials-passing mechanism. On those platforms/transports, comment out the <auth> element to allow fallback to DBUS_COOKIE_SHA1. --> <auth>EXTERNAL</auth> <standard_session_servicedirs /> <policy context="default"> <!-- Allow everything to be sent --> <allow send_destination="*" eavesdrop="true"/> <!-- Allow everything to be received --> <allow eavesdrop="true"/> <!-- Allow anyone to own anything --> <allow own="*"/> </policy> <!-- Config files are placed here that among other things, further restrict the above policy for specific services. --> <includedir>session.d</includedir> <!-- This is included last so local configuration can override what's in this standard file --> <include ignore_missing="yes">session-local.conf</include> <include if_selinux_enabled="yes" selinux_root_relative="yes">contexts/dbus_contexts</include> <!-- For the session bus, override the default relatively-low limits with essentially infinite limits, since the bus is just running as the user anyway, using up bus resources is not something we need to worry about. In some cases, we do set the limits lower than "all available memory" if exceeding the limit is almost certainly a bug, having the bus enforce a limit is nicer than a huge memory leak. But the intent is that these limits should never be hit. --> <!-- the memory limits are 1G instead of say 4G because they can't exceed 32-bit signed int max --> <limit name="max_incoming_bytes">1000000000</limit> <limit name="max_incoming_unix_fds">250000000</limit> <limit name="max_outgoing_bytes">1000000000</limit> <limit name="max_outgoing_unix_fds">250000000</limit> <limit name="max_message_size">1000000000</limit> <!-- We do not override max_message_unix_fds here since the in-kernel limit is also relatively low --> <limit name="service_start_timeout">120000</limit> <limit name="auth_timeout">240000</limit> <limit name="pending_fd_timeout">150000</limit> <limit name="max_completed_connections">100000</limit> <limit name="max_incomplete_connections">10000</limit> <limit name="max_connections_per_user">100000</limit> <limit name="max_pending_service_starts">10000</limit> <limit name="max_names_per_connection">50000</limit> <limit name="max_match_rules_per_connection">50000</limit> <limit name="max_replies_per_connection">50000</limit> </busconfig> /etc/dbus-1/system.conf changed: <!-- This configuration file controls the systemwide message bus. Add a system-local.conf and edit that rather than changing this file directly. --> <!-- Note that there are any number of ways you can hose yourself security-wise by screwing up this file; in particular, you probably don't want to listen on any more addresses, add any more auth mechanisms, run as a different user, etc. --> <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";> <busconfig> <!-- Our well-known bus type, do not change this --> <type>system</type> <!-- Run as special user --> <user>messagebus</user> <!-- Fork into daemon mode --> <fork/> <!-- We use system service launching using a helper --> <standard_system_servicedirs/> <!-- This is a setuid helper that is used to launch system services --> <servicehelper>/usr/lib/dbus-1.0/dbus-daemon-launch-helper</servicehelper> <!-- Write a pid file --> <pidfile>/var/run/dbus/pid</pidfile> <!-- Enable logging to syslog --> <syslog/> <!-- Only allow socket-credentials-based authentication --> <auth>EXTERNAL</auth> <!-- Only listen on a local socket. (abstract=/path/to/socket means use abstract namespace, don't really create filesystem file; only Linux supports this. Use path=/whatever on other systems.) --> <listen>unix:path=/var/run/dbus/system_bus_socket</listen> <policy context="default"> <!-- All users can connect to system bus --> <allow user="*"/> <!-- Holes must be punched in service configuration files for name ownership and sending method calls --> <deny own="*"/> <deny send_type="method_call"/> <!-- Signals and reply messages (method returns, errors) are allowed by default --> <allow send_type="signal"/> <allow send_requested_reply="true" send_type="method_return"/> <allow send_requested_reply="true" send_type="error"/> <!-- All messages may be received by default --> <allow receive_type="method_call"/> <allow receive_type="method_return"/> <allow receive_type="error"/> <allow receive_type="signal"/> <!-- Allow anyone to talk to the message bus --> <allow send_destination="org.freedesktop.DBus"/> <!-- But disallow some specific bus services --> <deny send_destination="org.freedesktop.DBus" send_interface="org.freedesktop.DBus" send_member="UpdateActivationEnvironment"/> <deny send_destination="org.freedesktop.DBus" send_interface="org.freedesktop.systemd1.Activator"/> </policy> <!-- Only systemd, which runs as root, may report activation failures. --> <policy user="root"> <allow send_destination="org.freedesktop.DBus" send_interface="org.freedesktop.systemd1.Activator"/> </policy> <!-- Config files are placed here that among other things, punch holes in the above policy for specific services. --> <includedir>system.d</includedir> <!-- This is included last so local configuration can override what's in this standard file --> <include ignore_missing="yes">system-local.conf</include> <include if_selinux_enabled="yes" selinux_root_relative="yes">contexts/dbus_contexts</include> </busconfig> /etc/init.d/dbus changed: set -e DAEMON=/usr/bin/dbus-daemon UUIDGEN=/usr/bin/dbus-uuidgen UUIDGEN_OPTS=--ensure NAME=dbus DAEMONUSER=messagebus PIDDIR=/var/run/dbus PIDFILE=$PIDDIR/pid DESC="system message bus" test -x $DAEMON || exit 0 .. /lib/lsb/init-functions PARAMS="" if [ -e /etc/default/dbus ]; then . /etc/default/dbus fi create_machineid() { # Create machine-id file if [ -x $UUIDGEN ]; then $UUIDGEN $UUIDGEN_OPTS fi } start_it_up() { if [ ! -d $PIDDIR ]; then mkdir -p $PIDDIR chown $DAEMONUSER $PIDDIR chgrp $DAEMONUSER $PIDDIR fi if [ -e $PIDFILE ]; then if $0 status > /dev/null ; then log_success_msg "$DESC already started; not starting." return else log_success_msg "Removing stale PID file $PIDFILE." rm -f $PIDFILE fi fi create_machineid log_daemon_msg "Starting $DESC" "$NAME" start-stop-daemon --start --quiet --pidfile $PIDFILE \ --exec $DAEMON -- --system $PARAMS log_end_msg $? } shut_it_down() { log_daemon_msg "Stopping $DESC" "$NAME" start-stop-daemon --stop --retry 5 --quiet --oknodo --pidfile $PIDFILE \ --user $DAEMONUSER # We no longer include these arguments so that start-stop-daemon # can do its job even given that we may have been upgraded. # We rely on the pidfile being sanely managed # --exec $DAEMON -- --system $PARAMS log_end_msg $? rm -f $PIDFILE } reload_it() { create_machineid log_action_begin_msg "Reloading $DESC config" dbus-send --print-reply --system --type=method_call \ --dest=org.freedesktop.DBus \ / org.freedesktop.DBus.ReloadConfig > /dev/null # hopefully this is enough time for dbus to reload it's config file. log_action_end_msg $? } case "$1" in start) start_it_up ;; stop) shut_it_down ;; reload|force-reload) reload_it ;; restart) shut_it_down start_it_up ;; status) status_of_proc -p $PIDFILE $DAEMON $NAME && exit 0 || exit $? ;; *) echo "Usage: /etc/init.d/$NAME {start|stop|reload|restart|force-reload|status}" >&2 exit 2 ;; esac -- no debconf information
--- End Message ---
--- Begin Message ---On 17/11/15 08:38, Sergey Vasilenko wrote: > I've been using the testing/(partially sid) debian release for a long time but > after scheduled upgrade of the system some strange troubles with drivers made > my X subsystem unusable so I decided to switch back to stable from testing. Debian does not support downgrades, so I'm closing this bug. Downgrading individual packages sometimes works, but a major-version downgrade like going from testing to stable will usually not work. > When I've made `apt-get upgrade && apt-get dist-upgrade` in order to switch > back to stable the system hung after reload on a particular systemd waiting > for > a LSB start. It waited for some LSBs start all of which were dependents of > the > dbus. This might be <https://bugs.debian.org/804183> which has a fix pending. Check whether /etc/dbus-1/session.conf and /etc/dbus-1/system.conf are symbolic links to the corresponding files in /usr/share/dbus-1. If they are, delete them, then reinstall dbus. > So I warned to check the dbus configuration and started system in old > sysvinit manner (--init=/bin/bash) and investigated that the dbus cannot > launch. That isn't sysvinit, that's bash. init=/bin/bash does not carry out any of the normal system startup tasks that would be done by sysvinit; if they are needed, you have to start things in their correct dependency order yourself. On systemd systems, the rescue and emergency targets are a less drastic version of init=/bin/bash. They start early-boot tasks, but do not wait until boot has finished before allowing a root login at the console. See <https://wiki.freedesktop.org/www/Software/systemd/Debugging/>. > Then I've checked the `mountpoint` command and there was no such a command at > all. > I think that there are some troubles with an `util-linux` package, which is > not > directly included into dbus package deps list. The mountpoint command and the util-linux package are both Essential:yes, so dbus is not required to depend on them explicitly. Files that have moved between packages are one of the things that often do not work after a downgrade. In stable, /bin/mountpoint was part of initscripts, which is transitively Essential; in unstable, it's part of util-linux, which is Essential. If you have somehow installed stable's util-linux but kept testing's initscripts, that would result in not having /bin/mountpoint. You can get it back by installing either stable's initscripts or testing's util-linux. > I've removed the /proc/ check in order for proper init dbus-daemon requires /proc (<https://bugs.debian.org/447363>). Regards, S
--- End Message ---
