Bug#942100: openssh-server: /etc/ssh/sshd_config unconditionally overwritten by update
> Port 22 That should have been Port Additionally, when I reviewed the `permit-root-login` debconf settings against the postinst I got a bit confused. In `create_sshdconfig` it says if [ "$permit_root_login" != true ]; then sed -i 's/^#*PermitRootLogin .*/PermitRootLogin yes/' \ "$new_config" fi My debconf setting for `$permit_root_login` is `true` so the `$new_config` is left untouched and has a #PermitRootLogin prohibit-password It took me a second think to realize that `prohibit-password` still permits root logins. However, what left me dumb-founded was that if I were to change `permit-root-login` to any value other then `true`, even `false` or `no` (debconf says it's a boolean), that that would change `$new_config` to have PermitRootLogin yes FWIW, PermitRootLogin supports four values. I find the debconf/postinst behavior *very* unintuitive, so I didn't change my debconf answers and put PermitRootLogin no in a `/etc/ssh/ssdh_config.d/*.conf` snippet so it takes precedence, per `man 5 sshd_config`, no matter how the postinst changes the `$new_config`.
Bug#942100: openssh-server: /etc/ssh/sshd_config unconditionally overwritten by update
This hit me this weekend, courtesy of the Debian 12.1 to 12.2 point upgrade.
That upgraded openssh-server from 1:9.2p1-2 to 1:9.2p1-2+deb12u1.
I had made some changes to /etc/ssh/sshd_config in March 2018 (Debian 9.4), one
of which moved the default port to . This was to make port 22 available
for use by a Docker-based GitLab instance.
I have been following point upgrades since then through 9.13, jumped to 10.6,
point upgrades through 10.11, jumped to 11.2, point upgrades through 11.7. All
without making any manual changes to sshd_config.
I integrated upstream sshd_config changes when I manually upgraded the host to
Debian 12.1 (from 11.7) in August 2023. At that time I did not move my
customizations to use the new /etc/ssh/sshd_config.d/* support.
The point upgrade was performed by unattended-upgrades on 2023-10-08 and the
machine was automatically rebooted on 2023-10-09. The SSH daemon was started
first, preventing the GitLab instance from starting. Seeing that, I tried to
login remotely via port and got a connection refused. Yikes!
Fortunately, the logcheck reports in my mailbox pointed out the GitLab could
not bind to port 22, giving me a clue that I could probably SSH in on that
port. Fortunately that worked and I was able to get things back to working
order via that remote login.
I have not been able to find any notice of this in the Debian 12 release notes
or the /usr/share/doc/openssh-server/{NEWS,README}.Debian.gz files and was
therefore very unpleasantly surprised by this behavior.
FWIW, my /var/cache/debconf/config.dat contains
Name: openssh-server/password-authentication
Template: openssh-server/password-authentication
Value: false
Owners: openssh-server
Name: openssh-server/permit-root-login
Template: openssh-server/permit-root-login
Value: true
Owners: openssh-server
but I manually edited sshd_config to use
PermitRootLogin no
as well as
Port 22
Cross-checking with /var/cache/debconf/templates.dat, it appears I used
dpkg-reconfigure to change password-authentication to end up with
PasswordAuthentication no
in my sshd_config.
The openssh-server.postinst appears to be responsible for "clobbering" my
customizations (via ucf) but I don't see any differences to that file between
the old and new versions, making me wonder why this hasn't hit me before.
I'll be syncing the openssh-server debconf answers with what I have in my
sshd_config and move out any other customizations to /etc/ssh/sshd_config.d/*
snippets but thought this might be of use to others.
Bug#1036773: [EXTERNAL] Bug#1036773: cloud.debian.org: During vagrant up, mounting NFS fails
+1
I my case installation of the NFS client fails (I'm behind a proxy) but the
machine
boots fine.
$ cat Vagrantfile
Vagrant.configure("2") do |config|
config.vm.box = "debian/testing64"
end
Last bit of the output from `vagrant up`
==> default: Machine booted and ready!
==> default: Installing NFS client...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
apt-get -yqq update
apt-get -yqq install nfs-common portmap
exit $?
Stdout from the command:
Stderr from the command:
W: Failed to fetch https://deb.debian.org/debian/dists/testing/InRelease
Cannot initiate the connection to debian.map.fastly.net:443
(2a04:4e42:48::644). - connect (101: Network is unreachable) Could not connect
to debian.map.fastly.net:443 (151.101.230.132), connection timed out Cannot
initiate the connection to deb.debian.org:443 (2a04:4e42:36::644). - connect
(101: Network is unreachable)
W: Some index files failed to download. They have been ignored, or old ones
used instead.
E: Package 'nfs-common' has no installation candidate
E: Unable to locate package portmap
Hope this helps,
From: Joshua Kugler
Sent: 26 May 2023 04:37
To: Debian Bug Tracking System
Subject: [EXTERNAL] Bug#1036773: cloud.debian.org: During vagrant up, mounting
NFS fails
Package: cloud.debian.org
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I tried to use the debian/testing64 vagrant box.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I ran `vagrant up`. It mostly runs, but hangs on ==> default: Mounting
NFS shared folders...
After sitting there
* What was the outcome of this action?
It mostly runs, but hangs on ==> default: Mounting NFS shared folders...
After sitting there for a while, it fails with:
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
mount -o vers=4 192.168.121.1:/home/jkugler/vmware/vagrant_debian
/vagrant
Stdout from the command:
Stderr from the command:
mount.nfs: Connection refused
* What outcome did you expect instead?
I expected the machine to come up without issue.
I noticed in the default Vagrantfile that comes with the box, there is
an NFS shared folder.
That should probably be removed and allow the user to configure shared
folders as they see fit.
Bug#1023784: comma separated no_proxy value ignored
Package: curl Version: 7.86.0-1 Severity: important I use a comma separated list of values in my no_proxy environment settings. Something like this no_proxy=localhost,127.0.0.1,::1,.internal.example.com,.example.org,10.0.0.0/8 This has worked fine for me for years. After the upgrade from 7.85.0-1 to 7.86.0-1, this setting is ignored and curl contacts the proxy server: $ curl -sv http://www.internal.example.com/ >/dev/null * Uses proxy env variable no_proxy == 'localhost,127.0.0.1,::1,.internal.example.com,.example.org,10.0.0.0/8' * Uses proxy env variable http_proxy == 'http://proxy.example.com:8080' * Trying 10.0.20.20:8080... * Connected to (nil) (10.0.20.20) port 8080 (#0) Using a single domain for the no_proxy value does not contact the proxy $ no_proxy=.internal.example.com curl -sv http://www.internal.example.com/ >/dev/null * Uses proxy env variable no_proxy == '.internal.example.com' * Trying 10.11.0.165:80... * Connected to www.internal.example.com (10.11.0.165) port 80 (#0) I have been experimenting a bit and found that *appending* to the variable triggers the bug. That is, no_proxy=.internal.example.com,localhost contacts the proxy server. Prepending it, does *not* trigger the bug. That is no_proxy=localhost,.internal.example.com does not contact the proxy. If I move .internal.example.com to the end of the comma separated list, curl behaves as expected but that obviously breaks for URLs in the .example.org domain or covered by the 10.0.0.0/8 CIDR. BTW, I also observe this with git for HTTP(S) URLs. In fact, that's where I first encountered the bug. Setting the no_proxy value to match the URL works around the issue for git too. Seeing that curl depends on libcurl4 and git libcurl3-gnutls, I'm submitting this to curl. I set the severity to important because it breaks a very common (as in oodles of times per day) workflow for me. Hope this helps.
Bug#1023782: Add dependency on pinentry-x11
Package: webext-browserpass Version: 3.7.2-1+b6 Severity: important The upstream documentation[1] clearly mentions that this extension depends on a GUI-based pinentry (unless you know what you're doing). This is not reflected in the package dependencies. I realize most desktops will pull one in but I prefer to piece something myself. And without installing Recommends: to boot ;-) Please add a dependency on pinentry-x11. This is a pure virtual package that makes the user pick one. I think that is to be preferred over adding a list of alternatives directly because the package managers tend to pick the first one listed. Seeing that people who know what they are doing can get away without the GUI-based pinentry, I guess a Recommends: is sufficient (although a Depends: would be okay with me too). [1]: https://github.com/browserpass/browserpass-extension#error-unable-to-fetch-and-parse-login-fields Hope this helps,
Bug#989817: davmail: [PATCH] Configuration ignored when starting via init.d script
Package: davmail Version: 5.5.1.3299-4 Severity: normal X-Debbugs-Cc: none, Olaf Meeuwissen Dear Maintainer, I have been using Davmail on Devuan (Debian sans systemd) without any trouble until this morning when I wanted to check the login procedure in the logs. Making the relevant changes in the configuration file, /etc/davmail/davmail.properties, and restarting the service with sudo /etc/init.d/davmail restart I did not see any debug log messages in either of the logfiles that might be in use, /var/log/davmail.log according to the init.d script and /var/log/davmail/davmail.log in the configuration file. Some digging around revealed that the init.d script hasn't really been kept in sync with some of the changes made to service startup. The attached patch fixed things for me. The only thing to watch out for is keeping the logfile location in sync with the configuration file. # I made the change to DAEMON_USER earlier to get things to work after # the initial installation. BTW, I don't use a keystore file so didn't bother to add /usr/share/davmail/service-prepare to the start action. Perhaps that is needed as well. Or was that handled by ENABLE_DAEMON in the past? This variable no longer expands to anything as far as I could see. Hope this helps, -- System Information: Distributor ID: Devuan Description:Devuan GNU/Linux 4 (chimaera) Release:4 Codename: n/a Architecture: x86_64 Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages davmail depends on: ii adduser 3.118 ii default-jre-headless [java9-runtime-headless] 2:1.11-72 ii init-system-helpers 1.60+devuan1 ii jarwrapper0.78 ii libcommons-codec-java 1.15-1 ii libcommons-httpclient-java3.1-16 ii libcommons-logging-java 1.2-2 ii libhtmlcleaner-java 2.24-1 ii libhttpclient-java4.5.13-2 ii libjackrabbit-java2.18.0+r2.14.6-1 ii libjcifs-java 1.3.19-2 ii libjettison-java 1.4.1-1 ii liblog4j1.2-java 1.2.17-10 ii libmail-java 1.6.5-1 ii libservlet-api-java 4.0.1-2 ii libslf4j-java 1.7.30-1 ii libstax2-api-java 4.1-1 ii libwoodstox-java 1:6.2.1-1 ii logrotate 3.18.0-2 ii lsb-base 11.1.0 ii openjdk-11-jre-headless [java9-runtime-headless] 11.0.11+9-1 davmail recommends no packages. Versions of packages davmail suggests: pn libopenjfx-java pn libswt-cairo-gtk-4-jni pn libswt-gtk2-4-jni -- Configuration Files: /etc/davmail/davmail.properties changed: davmail.server=true davmail.mode=EWS davmail.url=https://outlook.office365.com/EWS/Exchange.asmx davmail.caldavPort=1080 davmail.imapPort=1143 davmail.ldapPort=1389 davmail.popPort=1110 davmail.smtpPort=1025 davmail.enableProxy=false davmail.useSystemProxies=false davmail.proxyHost= davmail.proxyPort= davmail.proxyUser= davmail.proxyPassword= davmail.noProxyFor= davmail.allowRemote=true davmail.bindAddress= davmail.clientSoTimeout= davmail.server.certificate.hash= davmail.ssl.nosecurecaldav=false davmail.ssl.nosecureimap=false davmail.ssl.nosecureldap=false davmail.ssl.nosecurepop=false davmail.ssl.nosecuresmtp=false davmail.disableUpdateCheck=true davmail.enableKeepAlive=true davmail.folderSizeLimit=0 davmail.defaultDomain= davmail.caldavAlarmSound= davmail.caldavPastDelay=90 davmail.caldavAutoSchedule=true davmail.forceActiveSyncUpdate=false davmail.imapAutoExpunge=true davmail.imapIdleDelay= davmail.imapAlwaysApproxMsgSize= davmail.keepDelay=30 davmail.sentKeepDelay=90 davmail.popMarkReadOnRetr=false davmail.smtpSaveInSent=true davmail.logFilePath=/var/log/davmail/davmail.log davmail.logFileSize=1MB log4j.logger.davmail=INFO log4j.logger.httpclient.wire=INFO log4j.logger.org.apache.commons.httpclient=INFO log4j.rootLogger=INFO /etc/init.d/davmail changed: PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC="Davmail Exchange gateway" NAME=davmail DAEMON=/usr/bin/$NAME DAEMON_USER=_$NAME HOME=/var/lib/$DAEMON_USER PIDFILE=/var/run/$NAME.pid LOGFILE=/var/log/$NAME/$NAME.log SCRIPTNAME=/etc/init.d/$NAME [ -x "$DAEMON" ] || exit 0 DAEMON_ARGS="-server /etc/davmail/davmail.properties" if [ ! -r "$LOGFILE" ] then touch $LOGFILE chown $DAEMON_USER:ad
Bug#944699: bsdutils: logger uses username as process
Hi Chris, Chris Hofstaedtler writes: > Control: tags -1 upstream wontfix > > * Meeuwissen Olaf [191114 10:24]: > [..] >> In this case I would have expected the process to be `bash`, the shell >> from which I ran the `logger` command, not my username. >> >> I don't know if using the username instead of the parent process name is >> intended behaviour or not but if it is a note in the manual page would >> be nice. If it is not intended behaviour, it ought to be fixed. > > logger(1) clearly documents this: > The default tag is the name of the user logged in on the terminal > (or a user name based on effective user ID). Sorry. I completely missed this until you pointed it out :-( > It also says other things that are recommended when running logger > from a shell script (like dhclient-script), i.e. to pass --id=$$(PPID). In addition or instead of that, use of the --tag option would have prevented this bug report. Guess I should submit a wishlist report against isc-dhcp-client then. > logger itself does no magic to determine its parent process, and I > don't see how it could do that in a meaningful way without a > backwards incompatible change. I don't the backward incompatibility issue but seeing that the behaviour is documented, this report can be closed. Thanks for the quick feedback, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION Free Software Foundation Associate Member since 2004-01-27 Support Free Software https://my.fsf.org/donate Join the Free Software Foundationhttps://my.fsf.org/join
Bug#944699: bsdutils: logger uses username as process
Package: bsdutils Version: 1:2.33.2-0.1 Severity: normal I was debugging a dhclient-script hook when I noticed this in the journal Nov 14 09:31:23 debian olaf[3598]: /etc/dhcp/dhclient-exit-hooks.d/local-static-route returned non-zero exit status 1 THe issue is not with the non-zero exit status, that's my fault and has been fixed, but the process name had me scratch my head. I would have expected `dhclient-script` (which sources the hook) or `dhclient` which run the `dhclient-script`, *not* my username. BTW, my username was used because I'd been running ifup/ifdown via sudo for testing purposes. When I restarted networking.service, the username changed to `root`. Also, simply running `logger` from the command-line will reproduce this. $ logger 'Hello World!' $ journalctl -n 1 2>/dev/null -- Logs begin at Wed 2019-11-06 16:20:35 JST, end at Thy 2019-11-14 09:37:18 JST. -- Nov 14 09:37:18 debian olaf[2001]: Hello World! In this case I would have expected the process to be `bash`, the shell from which I ran the `logger` command, not my username. I don't know if using the username instead of the parent process name is intended behaviour or not but if it is a note in the manual page would be nice. If it is not intended behaviour, it ought to be fixed. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION Free Software Foundation Associate Member since 2004-01-27 Support Free Software https://my.fsf.org/donate Join the Free Software Foundationhttps://my.fsf.org/join
Bug#898388: systemd-sysv: shutdown command always fails
Michael Biebl writes: > Am 14.05.2018 um 01:23 schrieb Meeuwissen Olaf: > >> Definitely not from my POV. I'm off now installing dbus myself because >> systemd-sysv didn't think it important enough to do that for me :-( > > Well, the systemd package does do it for you, but you actively prevented > dbus from being installed, so I don't think it's justified for you to > complain about that. I think that systemd-sysv should think for itself what is and is not necessary for it to work. It should not rely on systemd doing that for it (because systemd probably doesn't really give a hoot about systemd-sysv). > In any case, yes, it's a good idea to have dbus installed and we do > recommend you do so. I also recommend that you install libpam-systemd, > so your user sessions are moved into proper cgroups. I noticed this in the libpam-systemd package description ;-) Packages that depend on logind functionality need to depend on libpam-systemd. Seeing that shutdown, scheduled shutdowns, depends on logind, shouldn't systemd-sysv depend on it? Would pull in dbus via a Depends: as well. Anyway, this doesn't seem to be going anywhere and you're not going to add a one-line dependency that would have saved me half a day trying to find out why unattended-upgrades didn't work as advertised in the reboot department, I'll call it quits. Hope this helped anyway, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION Free Software Foundation Associate Member since 2004-01-27 Support Free Software https://my.fsf.org/donate Join the Free Software Foundationhttps://my.fsf.org/join
Bug#898388: systemd-sysv: shutdown command always fails
Hi, Michael Biebl writes: > Am 14.05.2018 um 01:23 schrieb Meeuwissen Olaf: >> Hi, >> >> Michael Biebl writes: >> >>> Am 11.05.2018 um 08:10 schrieb Meeuwissen Olaf: >>>> Hi, >>>> >>>> Thanks for the quick follow-up. >>>> >>>> Michael Biebl writes: >>>> >>>>> Control: tags -1 + moreinfo >>>>> >>>>>> I have set up unattended-upgrades to reboot my machine at 04:00 when >>>>>> necessary. Internally, unattended-upgrades runs >>>>>> >>>>>> /sbin/shutdown -r 04:00 >>>>>> >>>>>> trying to achieve this. This fails as evidenced by these (dated) log >>>>>> messages >>>>>> >>>>>> Apr 25 06:55:18 easy apt.systemd.daily[38369]: Found >>>>>> /var/run/reboot-required, rebooting >>>>>> Apr 25 06:55:18 easy apt.systemd.daily[38369]: Failed to connect to >>>>>> bus: No such file or directory >>>>> >>>>> [ ... ] >>>> >>>> FTR, after I install dbus, I get >>>> >>>> $ sudo shutdown -r 04:00 >>>> Shutdown scheduled for Sat 2018-05-12 04:00:00 JST, use 'shutdown -c' to >>>> cancel. >>> >>> Scheduled shutdowns require systemd-logind, which in turn requires >>> dbus. >> >> In my initial bug report I included >> >> root@debian:~$ shutdown -r 04:00 >> Failed to connect to bus: No such file or directory >> root@debian:~$ shutdown -r >> Failed to connect to bus: No such file or directory >> root@debian:~$ shutdown >> Failed to connect to bus: No such file or directory >> >> What is scheduled about the last two commands? The implicit "now"? > > Please read the manual for shutdown carefully: > > "If no time argument is specified, +1 is implied." > > So yes, all the examples you gave are scheduled shutdowns. Sorry, my bad. I missed that. Instead my eyes got stuck on "now". > If you use shutdown -h now (no scheduled shutdown), it should work > without dbus. > > You said that shutdown is completely broken for you, are you implying > that -h now does not work for you? shutdown -h now works without dbus. So the shutdown command is not completely broken, just seriously broken :-/ -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION Free Software Foundation Associate Member since 2004-01-27 Support Free Software https://my.fsf.org/donate Join the Free Software Foundationhttps://my.fsf.org/join
Bug#898388: systemd-sysv: shutdown command always fails
Hi, Michael Biebl writes: > Am 11.05.2018 um 08:10 schrieb Meeuwissen Olaf: >> Hi, >> >> Thanks for the quick follow-up. >> >> Michael Biebl writes: >> >>> Control: tags -1 + moreinfo >>> >>>> I have set up unattended-upgrades to reboot my machine at 04:00 when >>>> necessary. Internally, unattended-upgrades runs >>>> >>>> /sbin/shutdown -r 04:00 >>>> >>>> trying to achieve this. This fails as evidenced by these (dated) log >>>> messages >>>> >>>> Apr 25 06:55:18 easy apt.systemd.daily[38369]: Found >>>> /var/run/reboot-required, rebooting >>>> Apr 25 06:55:18 easy apt.systemd.daily[38369]: Failed to connect to bus: >>>> No such file or directory >>> >>> What's the output of >>> systemctl status dbus.socket dbus.service systemd-logind.service >> >> $ sudo systemctl status dbus.socket dbus.service systemd-logind.service >> Unit dbus.socket could not be found. >> Unit dbus.service could not be found. >> * systemd-logind.service - Login Service >> Loaded: loaded (/lib/systemd/system/systemd-logind.service; static; >> vendor preset: enabled) >> Active: inactive (dead) >> Condition: start condition failed at Fri 2018-05-11 04:00:25 JST; 10h ago >> `- ConditionPathExists=/lib/systemd/system/dbus.service was not >> met >>Docs: man:systemd-logind.service(8) >> man:logind.conf(5) >> http://www.freedesktop.org/wiki/Software/systemd/logind >> http://www.freedesktop.org/wiki/Software/systemd/multiseat >> >> Yes, I don't have dbus installed. Nothing I have installed has a >> dependency on it that is Depends: or more important. I don't install >> Recommends: and actively remove them unless other installed packages >> declare a (Pre-)Depends: >> >> Based on my understanding of the relevant section[1] in the Debian >> Policy, I would argue that systemd-sysv needs a Depends: dbus. >> >> [1]: >> https://www.debian.org/doc/debian-policy/#binary-dependencies-depends-recommends-suggests-enhances-pre-depends >> >> The Recommends: that systemd declares looks fine as I have not observed >> any other breakage. >> >> FTR, after I install dbus, I get >> >> $ sudo shutdown -r 04:00 >> Shutdown scheduled for Sat 2018-05-12 04:00:00 JST, use 'shutdown -c' to >> cancel. >> > > Scheduled shutdowns require systemd-logind, which in turn requires > dbus. In my initial bug report I included root@debian:~$ shutdown -r 04:00 Failed to connect to bus: No such file or directory root@debian:~$ shutdown -r Failed to connect to bus: No such file or directory root@debian:~$ shutdown Failed to connect to bus: No such file or directory What is scheduled about the last two commands? The implicit "now"? The reboot command, also provided by systemd-sysv, works *without* dbus installed. So do the halt and poweroff commands. The only thing login related I could find in the shutdown manual page is the creating of a /run/nologin file in case a timespec is given. > The basic functionality of systemd does not strictly require dbus > though. This pretty much fits the bill for recommends and we want to > allow (at least for the time being), to not have dbus installed, even if > this means, that certain functionality in systemd is then not available. > This is a choice the admin has to make. And I agreed that the Recommends: dbus for systemd is fine. I said that I thought that systemd-sysv needs a Depends: because the absence of dbus breaks the shutdown command *completely*. # OK, so invoking it with the --help option works. Great! I would think completely breaking the shutdown command meets The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. unless you want to argue that shutdown is not a significant amount of functionality provided by systemd-sysv. Seeing that systemd does not depend on systemd-sysv, adding the dbus dependency to systemd-sysv will not introduce a dbus dependency for systemd itself. > If you choose to not install dbus, then you can't use logind (and as > such scheduled shutdowns). > > So everything is behaving as expected. Definitely not from my POV. I'm off now installing dbus myself because systemd-sysv didn't think it important enough to do that for me :-( Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION Free Software Foundation Associate Member since 2004-01-27 Support Free Software https://my.fsf.org/donate Join the Free Software Foundationhttps://my.fsf.org/join
Bug#898388: systemd-sysv: shutdown command always fails
Hi, Thanks for the quick follow-up. Michael Biebl writes: > Control: tags -1 + moreinfo > >> I have set up unattended-upgrades to reboot my machine at 04:00 when >> necessary. Internally, unattended-upgrades runs >> >> /sbin/shutdown -r 04:00 >> >> trying to achieve this. This fails as evidenced by these (dated) log >> messages >> >> Apr 25 06:55:18 easy apt.systemd.daily[38369]: Found >> /var/run/reboot-required, rebooting >> Apr 25 06:55:18 easy apt.systemd.daily[38369]: Failed to connect to bus: >> No such file or directory > > What's the output of > systemctl status dbus.socket dbus.service systemd-logind.service $ sudo systemctl status dbus.socket dbus.service systemd-logind.service Unit dbus.socket could not be found. Unit dbus.service could not be found. * systemd-logind.service - Login Service Loaded: loaded (/lib/systemd/system/systemd-logind.service; static; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Fri 2018-05-11 04:00:25 JST; 10h ago `- ConditionPathExists=/lib/systemd/system/dbus.service was not met Docs: man:systemd-logind.service(8) man:logind.conf(5) http://www.freedesktop.org/wiki/Software/systemd/logind http://www.freedesktop.org/wiki/Software/systemd/multiseat Yes, I don't have dbus installed. Nothing I have installed has a dependency on it that is Depends: or more important. I don't install Recommends: and actively remove them unless other installed packages declare a (Pre-)Depends: Based on my understanding of the relevant section[1] in the Debian Policy, I would argue that systemd-sysv needs a Depends: dbus. [1]: https://www.debian.org/doc/debian-policy/#binary-dependencies-depends-recommends-suggests-enhances-pre-depends The Recommends: that systemd declares looks fine as I have not observed any other breakage. FTR, after I install dbus, I get $ sudo shutdown -r 04:00 Shutdown scheduled for Sat 2018-05-12 04:00:00 JST, use 'shutdown -c' to cancel. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION Free Software Foundation Associate Member since 2004-01-27 Support Free Software https://my.fsf.org/donate Join the Free Software Foundationhttps://my.fsf.org/join
Bug#898388: systemd-sysv: shutdown command always fails
Package: systemd-sysv Version: 232-25+deb9u3 Severity: important Dear Maintainer, I have set up unattended-upgrades to reboot my machine at 04:00 when necessary. Internally, unattended-upgrades runs /sbin/shutdown -r 04:00 trying to achieve this. This fails as evidenced by these (dated) log messages Apr 25 06:55:18 easy apt.systemd.daily[38369]: Found /var/run/reboot-required, rebooting Apr 25 06:55:18 easy apt.systemd.daily[38369]: Failed to connect to bus: No such file or directory I have tried running the shutdown directly from the commandline with identical results root@debian:~$ shutdown -r 04:00 Failed to connect to bus: No such file or directory root@debian:~$ shutdown -r Failed to connect to bus: No such file or directory root@debian:~$ shutdown Failed to connect to bus: No such file or directory I had expected the shutdown to behave as documented. I have searched the debian/changelog for 238-4 on the terms shutdown and reboot but did not find any indication that this might have been fixed. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-sysv depends on: ii systemd 232-25+deb9u3 systemd-sysv recommends no packages. systemd-sysv suggests no packages. -- no debconf information Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION Free Software Foundation Associate Member since 2004-01-27 Support Free Software https://my.fsf.org/donate Join the Free Software Foundationhttps://my.fsf.org/join
