Bug#806291: systemd: systemctl status ignores -n argument
Hallo, * Michael Biebl [Thu, Nov 26 2015, 04:32:43PM]: > Am 26.11.2015 um 15:59 schrieb Michael Biebl: > > Works here. But I actually need a service which produces more then 10 > > lines of output when started. > > To illustrate what I did: > > # cat /etc/systemd/system/output.service > [Unit] > Description=foo > [Service] > Type=oneshot > ExecStart=/bin/sh -c "for i in `seq 1 200`; do echo $i; done" > > > # systemctl start output.service > # systemct status -n 100 > log message 102-200 > Nov 26 16:28:27 pluto systemd[1]: Started foo. You are demonstrating the good case, I am after a bad case. Let's try this: [Unit] Description=SomeThing After=network.target [Install] WantedBy=multi-user.target [Service] Type=notify Restart=on-failure ExecStart=/bin/sh -c "echo OMG THEY KILLED KENNY >&2; exit 123" and check the result: foo.service - SomeThing Loaded: loaded (/lib/systemd/system/foo.service; disabled; vendor preset: enabled) Active: failed (Result: start-limit) since Sa 2015-11-28 11:28:39 CET; 13s ago Process: 6982 ExecStart=/bin/sh -c echo OMG THEY KILLED KENNY >&2; exit 123 (code=exited, status=123) Main PID: 6982 (code=exited, status=123) Nov 28 11:28:39 idefix systemd[1]: Failed to start SomeThing. Nov 28 11:28:39 idefix systemd[1]: foo.service: Unit entered failed state. Nov 28 11:28:39 idefix systemd[1]: foo.service: Failed with result 'exit-code'. Nov 28 11:28:39 idefix sh[6982]: OMG THEY KILLED KENNY Nov 28 11:28:39 idefix systemd[1]: foo.service: Service hold-off time over, scheduling restart. Nov 28 11:28:39 idefix systemd[1]: Stopped SomeThing. Nov 28 11:28:39 idefix systemd[1]: foo.service: Start request repeated too quickly. Nov 28 11:28:39 idefix systemd[1]: Failed to start SomeThing. Nov 28 11:28:39 idefix systemd[1]: foo.service: Unit entered failed state. Nov 28 11:28:39 idefix systemd[1]: foo.service: Failed with result 'start-limit'. Looks good, huh? So what is the major difference to the script in the original report? Is it maybe this? Type=notify I can imagine that if the service dies before any dbus event was sent then the messages are printed early, followed by the spam I mentioned? And that makes them scroll out of "systemctl status" buffer? But anyhow, it's a secondary issue and probably deserves a second bug report. The thing that botters me, see subject, is the broken -n option, adding -n20 or -n2000 to systemctl-status call does not change anything. It keeps displaying 10 lines. Regards, Eduard. -- lol, habe gerad eine spam mail bekommen mit: klicken sie hier um zu testen wie hoch ihr IQ ist... ich denke wenn ich raufklicke habe ich ihn nicht bestanden :))) signature.asc Description: 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
Bug796588#: adjtimex: Has init script in runlevel S but no matching service file
Dear systemd maintainers, I'm in the process of ITA adjtimex package, which contains a bug you reported that need to support rcS service. I'm trying to fix this before send out my 1st release to close ITA. > Package: adjtimex > Severity: important > User: pkg-systemd-maintainers@lists.alioth.debian.org > Usertags: init-rcs-service > Your package adjtimex has an initscript that is enabled in runlevel > S, but it does not provide a corresponding systemd service unit. As you may already know, adjtimex is a tool to set up kernel time variables in boot time. Correct time and time ticking is important to many services, including time-sync service, so in SysV world adjtimex is run in rcS level, which is very early. Enclosed the "adjtimex.service" file I wrote and confirmed working well on my box. Since this is the first time I write service file, it would be helpful if you can help to review it. I also have one doubt whether to have "RemainAfterExit=yes", which is commented out now. After setting the kernel time variables, adjtimex simply exits and don't need to remain as daemon. I guess it should be okay to be "no". Looking forward to your reply. Thank you! Cheers, Roger adjtimex.service Description: Binary data ___ 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#798242: systemd: Failed to execute operation: Connection timed out
Control: fixed -1 228-1 Hello James, James Cameron [2015-09-07 3:19 -0500]: > Processing triggers for systemd (215-17+deb8u1) ... > Failed to execute operation: Connection timed out This sounds like another case of https://github.com/systemd/systemd/issues/1505, which finally got fixed in version 228. This bug is really hard to reproduce reliably on versions < 219, and still hard to reproduce in that particular postinst situation with later versions. I don't close this for now, it would be interesting to see whether this still happens with >= 228 in any case. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: Bug#798242: systemd: Failed to execute operation: Connection timed out
Processing control commands: > fixed -1 228-1 Bug #798242 [systemd] systemd: Failed to execute operation: Connection timed out Marked as fixed in versions systemd/228-1. -- 798242: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798242 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ 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#788050: systemd-fsck : Check disks at each reboot
Hey Michael, Michael Biebl [2015-09-24 18:32 +0200]: > Am 24.09.2015 um 17:46 schrieb hannu@pp.inet.fi: > > This works for me: > > > > copy /lib/systemd/system/systemd-fsckd.service to /etc/systemd/system > > > > edit /etc/systemd/system/systemd-fsckd.service, add TimeoutStartSec under > > [Service] > > > > [Service] > > TimeoutStartSec=60min > > Hm, good point. We should probably disable the Timeout completely like > in systemd-fsck-root.service and systemd-fsck@.service by setting > > TimeoutStartSec=0 > > The default is 90s, and an fsck for a large disk can certainly take > longer for ext3. Do you happen to know *why* this works? fsckd.service is not a Type=oneshot, and I don't see why the actual startup of the process should take that long? Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital 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#806533: systemd-sysv: /sbin/shutdown is missing -F option (force fsck on reboot)
Package: systemd-sysv Version: 228-2 Severity: important This option seems to have recently disappeared; see here, for example: http://linuxcommand.org/man_pages/shutdown8.html It seems to be related to systemd; perhaps it's supposed to be an "improvement". http://forums.fedoraforum.org/showthread.php?t=268935 There are a wide variety of situations in which you might want to force filesystem checks on reboot, which is why this option existed in the first place. There is no valid reason for removing it -- it's OPTIONAL. Can we please have it back? -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-sysv depends on: ii systemd 228-2 systemd-sysv recommends no packages. systemd-sysv suggests no packages. -- no debconf information ___ 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: Bug796588#: adjtimex: Has init script in runlevel S but no matching service file
Hi Roger, On 28 November 2015 at 11:12, Roger Shimizu wrote: > Dear systemd maintainers, > > I'm in the process of ITA adjtimex package, which contains a bug you > reported that need to support rcS service. I'm trying to fix this > before send out my 1st release to close ITA. Excellent! > >> Package: adjtimex >> Severity: important >> User: pkg-systemd-maintainers@lists.alioth.debian.org >> Usertags: init-rcs-service >> Your package adjtimex has an initscript that is enabled in runlevel >> S, but it does not provide a corresponding systemd service unit. > > As you may already know, adjtimex is a tool to set up kernel time > variables in boot time. Correct time and time ticking is important to > many services, including time-sync service, so in SysV world adjtimex > is run in rcS level, which is very early. > > Enclosed the "adjtimex.service" file I wrote and confirmed working > well on my box. > Since this is the first time I write service file, it would be helpful > if you can help to review it. I have some comments: > [Unit] > Description=adjtimex service in early boot I think the description of the init script is better: "set the kernel time variables". > ConditionFileIsExecutable=/etc/init.d/adjtimex I thin this is superflous. > DefaultDependencies=no > After=local-fs.target > Before=time-sync.target sysinit.target shutdown.target > Conflicts=shutdown.target I'm not sure about time-sync.target. `man systemd.special` says that time-sync.target is for synchronizing against a remote source, which AFAICT adjtimex doesn't do. Note that if what you wanted to do is to run before other time-synchronization daemons, this will not do it. sysinit.target should be ok, though. I don't think the conflict/before with shutdown.target is relevant, as this unit does nothing on stop, and thus does not need to do anything on shutdown. > > [Service] > Type=oneshot > ExecStart=/etc/init.d/adjtimex start I think you should call the program directly and bypass the init script. You can do as follows: # default values Environment=TICK=1 Environment=FREQ=0 # override as in the init script EnvironmentFile=-/etc/default/adjtimex ExecStart=/sbin/adjtimex -tick $TICK -frequency $FREQ > TimeoutSec=0 This is almost certainly wrong. I think you should skip this entry and leave it at the default. At some point the system needs to continue booting, even if the time is wrong, no? > StandardOutput=tty Do not set this, as this overrides the administrator default in /etc/systemd/system.conf. Let standard output go to the system-wide default. > #RemainAfterExit=yes I have seen that Type=oneshot services that do not have RemainAfterExit=yes can be executed multiple times during boot. This may or may not be a problem here. > > [Install] > WantedBy=sysinit.target > > I also have one doubt whether to have "RemainAfterExit=yes", which is > commented out now. > After setting the kernel time variables, adjtimex simply exits and > don't need to remain as daemon. I guess it should be okay to be "no". The RemainAfterExit directive controls wether systemd considers the unit "active" after all the running processes in the unit exited. This can trigger multiple runs during boot, if at some point this unit is wanted, but it already ran and exited. My sense is that RemainAfterExit should be =yes for most Type=oneshot service. Unfortunately, that means that to manually re-run the unit, one needs to do a "restart" instead of a "start" to make systemd run the program again. > > Looking forward to your reply. Thank you! Thank you for your contribution! -- Saludos, Felipe Sateler ___ 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: Bug796588#: adjtimex: Has init script in runlevel S but no matching service file
Hello Roger Shimizu. On Sat, Nov 28, 2015 at 11:12:38PM +0900, Roger Shimizu wrote: > Dear systemd maintainers, [...] I'm just a random bystander, but hope I can come up with a few useful suggestion. > Enclosed the "adjtimex.service" file I wrote and confirmed working > well on my box. > Since this is the first time I write service file, it would be helpful > if you can help to review it. Thanks for your interest in participating in resolving the rcS situation. > > I also have one doubt whether to have "RemainAfterExit=yes", which is > commented out now. > After setting the kernel time variables, adjtimex simply exits and > don't need to remain as daemon. I guess it should be okay to be "no". I'd suggest you remove the line entirely. (The default is RemainAfterExit=no.) You have no "stop" method, thus there's no point in using this directive to mark the service as still running so that it can later be "stopped". For more information: http://www.freedesktop.org/software/systemd/man/systemd.service.html#RemainAfterExit= > > Looking forward to your reply. Thank you! I also suggest you look into the possibility to not running the init script from the service file. Should be possible by making the following changes: Remove: ConditionFileIsExecutable=/etc/init.d/adjtimex Add: Environment="TICK=1 FREQ=0" EnvironmentFile=-/etc/default/adjtimex See: http://www.freedesktop.org/software/systemd/man/systemd.exec.html#Environment= EnvironmentFile= should "win" over default settings in Environment=, while the dash (-) prefix says it's ok if the file does not exist. Replace: ExecStart=/etc/init.d/adjtimex start with: ExecStart=/sbin/adjtimex -tick "$TICK" -frequency "$FREQ" In case these changes sounds useful to you, then please confirm the above to make sure my understanding of the situation is correct. Regards, Andreas Henriksson ___ 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#806256: libpam-systemd: log out from a TTY and your X input devices get lost!
On Fri, 27 Nov 2015 00:16:45 +0100 Francesco Poli wrote: > On Thu, 26 Nov 2015 00:06:56 +0100 Michael Biebl wrote: [...] > > Does it make a difference if you use > > a different window manager? > > I'll try and find the time to install a different window manager / > desktop environment and test it, hopefully during the week-end... I installed xfce4 and tried to reproduce the bug. I experienced the same exact misbehavior. I think we can conclude that the bug does *not* depend on the window manager / desktop environment... Please tell me whether you need any further information in order to investigate. Otherwise, please drop the moreinfo tag. Thanks for your time! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpg4YbubgHLq.pgp Description: 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
Re: Bug#788050: systemd-fsck : Check disks at each reboot
Might have been a red herring Am 28. November 2015 15:36:12 MEZ, schrieb Martin Pitt : >Hey Michael, > >Michael Biebl [2015-09-24 18:32 +0200]: >> Am 24.09.2015 um 17:46 schrieb hannu@pp.inet.fi: >> > This works for me: >> > >> > copy /lib/systemd/system/systemd-fsckd.service to >/etc/systemd/system >> > >> > edit /etc/systemd/system/systemd-fsckd.service, add TimeoutStartSec >under [Service] >> > >> > [Service] >> > TimeoutStartSec=60min >> >> Hm, good point. We should probably disable the Timeout completely >like >> in systemd-fsck-root.service and systemd-fsck@.service by setting >> >> TimeoutStartSec=0 >> >> The default is 90s, and an fsck for a large disk can certainly take >> longer for ext3. > >Do you happen to know *why* this works? fsckd.service is not a >Type=oneshot, and I don't see why the actual startup of the process >should take that long? > >Martin >-- >Martin Pitt| http://www.piware.de >Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) > > > > >___ >Pkg-systemd-maintainers mailing list >Pkg-systemd-maintainers@lists.alioth.debian.org >http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: severity of 806533 is wishlist, tagging 806533
Processing commands for cont...@bugs.debian.org: > severity 806533 wishlist Bug #806533 [systemd-sysv] systemd-sysv: /sbin/shutdown is missing -F option (force fsck on reboot) Severity set to 'wishlist' from 'important' > tags 806533 + wontfix Bug #806533 [systemd-sysv] systemd-sysv: /sbin/shutdown is missing -F option (force fsck on reboot) Added tag(s) wontfix. > thanks Stopping processing here. Please contact me if you need assistance. -- 806533: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806533 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
RM: kdbus; RoM, abandoned upstream in current form
Package: ftp.debian.org kdbus has been put into experimental as an out-of-tree preview. However, kdbus was rejected for inclusion into the upstream kernel, and the kdbus authors now want to re-think and re-design it. It has also been removed from Fedora [1]. With that, the systemd maintainers think it's better to remove the package for the time being, as the current code can now be considered as unmaintained and it does not have much of a future. The module can still be used from git for interested people, of course. Thanks, Martin [1] https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/message/QABCG3E5TTDJIZBIEC7NHUD5KUKNIF5S/ -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital 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#806407: marked as done (systemd: session limited to 512 tasks after upgrade)
Your message dated Sat, 28 Nov 2015 21:57:23 +0100 with message-id <20151128205723.gd3...@piware.de> and subject line Re: Bug#806407: systemd: session limited to 512 tasks after upgrade has caused the Debian Bug report #806407, regarding systemd: session limited to 512 tasks after upgrade 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 ow...@bugs.debian.org immediately.) -- 806407: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806407 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 228-2 Severity: important After upgrading from systemd 227-2 to 228-2, my session became unusable as it had more than 512 tasks and all of user.slice, user-1000.slice and session-cNN.scope had TasksMax=512. Restarting systemd-logind.service _and_ logging off and on did solve the problem, but that's hardly acceptable, is it? -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (980, 'testing'), (980, 'stable'), (500, 'unstable'), (500, 'stable'), (200, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.3.0-lis64+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash 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+b1 ii libaudit1 1:2.4.4-4 ii libblkid1 2.27.1-1 ii libc6 2.19-22 ii libcap2 1:2.24-12 ii libcap2-bin 1:2.24-12 ii libcryptsetup4 2:1.6.6-5 ii libgcc1 1:5.2.1-23 ii libgcrypt20 1.6.4-3 pn libkmod2 ii liblzma55.1.1alpha+20120614-2.1 ii libmount1 2.27.1-1 ii libpam0g1.1.8-3.1 ii libseccomp2 2.2.3-2 ii libselinux1 2.4-3 ii libsystemd0 228-2 ii mount 2.27.1-1 ii sysv-rc 2.88dsf-59.2 ii util-linux 2.27.1-1 Versions of packages systemd recommends: ii dbus1.10.4-1 ii libpam-systemd 228-2 Versions of packages systemd suggests: ii systemd-container 228-2 ii systemd-ui 3-4 Versions of packages systemd is related to: ii udev 228-2 -- Configuration Files: /etc/systemd/logind.conf changed [not included] -- no debconf information -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/ --- End Message --- --- Begin Message --- Hello, as discussed, there really isn't much we can do here, I'm afraid. Eventually, for a jessie → stretch upgrade you will need to reboot, but that's already the case for a dist-upgrade. Thus I'm closing this. Sorry for the bad news! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)--- End Message --- ___ 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#806533: marked as done (systemd-sysv: /sbin/shutdown is missing -F option (force fsck on reboot))
Your message dated Sat, 28 Nov 2015 22:41:25 +0100 with message-id <565a1f85@debian.org> and subject line Re: Bug#806533: systemd-sysv: /sbin/shutdown is missing -F option (force fsck on reboot) has caused the Debian Bug report #806533, regarding systemd-sysv: /sbin/shutdown is missing -F option (force fsck on reboot) 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 ow...@bugs.debian.org immediately.) -- 806533: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806533 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd-sysv Version: 228-2 Severity: important This option seems to have recently disappeared; see here, for example: http://linuxcommand.org/man_pages/shutdown8.html It seems to be related to systemd; perhaps it's supposed to be an "improvement". http://forums.fedoraforum.org/showthread.php?t=268935 There are a wide variety of situations in which you might want to force filesystem checks on reboot, which is why this option existed in the first place. There is no valid reason for removing it -- it's OPTIONAL. Can we please have it back? -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-sysv depends on: ii systemd 228-2 systemd-sysv recommends no packages. systemd-sysv suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- Dear Ian, Am 28.11.2015 um 15:48 schrieb Ian Bruce: > This option seems to have recently disappeared; see here, for example: > > http://linuxcommand.org/man_pages/shutdown8.html The man page shipped by systemd is a different one and doesn't list -F as an option, because... > It seems to be related to systemd; perhaps it's supposed to be an > "improvement". > > http://forums.fedoraforum.org/showthread.php?t=268935 > > There are a wide variety of situations in which you might want to force > filesystem checks on reboot, which is why this option existed in the first > place. There is no valid reason for removing it -- it's OPTIONAL. > > Can we please have it back? it was removed on purpose. -F creates a flag file on the file system which should be checked. For a file system which potentially already has issues, doing a write is probably not a good idea. Systemd still has legacy support for /forcefsck. So if you create that file manually, systemd will respect that. You need to do that by hand though. The reasoning here is, to make the user aware that this causes a write operation on the file system, the -F switch hides that. That said, touch /forcefsck is discouraged and a better mechanism is to pass systemd.fsck=force on the kernel command line. For more details, see man systemd-fsck@.service. In summary, the change is deliberate and there exist better alternatives. Thus closing this bug report. Regards, Michael signature.asc Description: OpenPGP digital signature --- End Message --- ___ 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#788050: systemd-fsck : Check disks at each reboot
Hi again, On 15-11-15 10:06, Michael Biebl wrote: I saw some workaround and suggestions, but is there already a direction of a solution of this issue? I'm afraid not. Not being able to reproduce this issue (on my side) makes this harder. Can you reproduce the issue reliably? As I wrote before, I get this issue *each and every time* I boot my system at the moment. So, I'm having a 9.5 minute delay every time I start up my PC. (Which is daily.) This is getting quite annoying, but the plus side is: as I can 100% reliably reproduce the issue, I am very much wanting to help you to investigate it. But you need to tell me what I need to do to help you with this issue. Which output of which commands do you need? Which tests could we do? How can I help? If there's really nothing I can do (and you're sure about that!), I'd rather get rid of this long boot delay... I bought an SSD to be able to boot quickly and that joy is now totally destroyed! ;-) -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ ___ 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#803531: systemd: timeout mounting /home (btrfs) at boot
Michael Biebl [2015-11-01 2:57 +0100]: > So, I'm not sure if this a problem of the systemd btrfs builtin doing > something stupid or if it's a kernel/btrfs bug. Just FTR, it's not generally broken. I (and also some of my colleagues) have used btrfs for a long time, with systemd versions 44 to 228, and it works just fine here. So indeed we need to debug this on Brian's machine. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: bug 794744 is forwarded to https://github.com/systemd/systemd/issues/1658
Processing commands for cont...@bugs.debian.org: > forwarded 794744 https://github.com/systemd/systemd/issues/1658 Bug #794744 [systemd] systemd-logind: Lid closed event does not suspend Set Bug forwarded-to-address to 'https://github.com/systemd/systemd/issues/1658'. > thanks Stopping processing here. Please contact me if you need assistance. -- 794744: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794744 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ 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#803531: systemd: timeout mounting /home (btrfs) at boot
Hello Brian, Brian May [2015-11-01 10:36 +1100]: > Brian May writes: > >> Can you boot with systemd.log_level=debug on the kernel command line and > >> attach the output of journalctl -alb. > >> > >> The output of udevadm info -e might be helpful as well. > > > > Have a vague feeling I may have tried systemd.log_level=debug and it > > didn't show anything useful. Not sure now. > > Have attached the output from the above commands. Hopefully this > helps... Ah, ignore my previous reply, I didn't look at this bug too closely yet. | P: /devices/pci:00/:00:1f.2/ata3/host2/target2:0:0/2:0:0:0/block/sdb/sdb1 | E: ID_FS_UUID=f77d6ce8-12bf-476a-8276-2031ce3e3c42 | E: ID_BTRFS_READY=1 | | P: /devices/pci:00/:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sdc/sdc1 | E: ID_FS_UUID=f77d6ce8-12bf-476a-8276-2031ce3e3c42 | E: ID_BTRFS_READY=0 It's indeed very likely that this is due to the "mirrored" mode and both partitions have the same UUID. I guess this confuses the kernel driver and/or udev somehow? This ought to be reproducible in a VM. (Won't do it right now myself; too late, sorry.) To clarify, how exactly did you create this "mirrored" btrfs mode, to ensure we try the same thing for reproducing? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ 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#806256: libpam-systemd: log out from a TTY and your X input devices get lost!
Am 28.11.2015 um 19:23 schrieb Francesco Poli: > Please tell me whether you need any further information in order to > investigate. Otherwise, please drop the moreinfo tag. So far I don't know yet, how I can reproduce the problem. So I'll keep the moreinfo tag. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital 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#788050: systemd-fsck : Check disks at each reboot
Am 29.11.2015 um 00:12 schrieb Manuel Bilderbeek: > How can I help? Describe your setup in as much detail as possible. LVM, RAID, fstab etc. Can you reproduce the issue with arbitrary mounts? Can you reproduce the issue with a minimal setup? On a different system? Do you have any hints how we can reproduce it? Does the problem go away if you use "systemctl mask systemd-fsckd.service systemd-fsckd.socket" Does journalctl -u systemd-fsckd.service produce anything interesting? Can you boot with systemd.debug-shell on the kernel command line, and then switch to tty9 while the fsck is running and attach strace to the fsckd and fsck process? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital 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#803531: systemd: timeout mounting /home (btrfs) at boot
Martin Pitt writes: > It's indeed very likely that this is due to the "mirrored" mode and > both partitions have the same UUID. I guess this confuses the kernel > driver and/or udev somehow? Perhaps annoyingly, somedays it boots every time. Then I get a day when it wont boot at all. I never considered the possibility that mirrored mode might be a contributing factor. Wonder if it is a matter of one drive being OK, however it is random which drive it is; it will boot if the drive referenced in /etc/fstab is the drive that is OK. > This ought to be reproducible in a VM. (Won't do it right now myself; > too late, sorry.) To clarify, how exactly did you create this > "mirrored" btrfs mode, to ensure we try the same thing for > reproducing? I created it on a single drive, then followed the instructions to mirror it in RAID1 mode on the other drive. -- Brian May ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
