Re: Many systemd units do not start anymore

[Michael Biebl]

Am 07.02.24 um 13:07 schrieb Christoph Pleger:

Hello,

Am Mittwoch, dem 07.02.2024 um 12:27 +0100 schrieb Michael Biebl:

Am 07.02.24 um 11:32 schrieb Christoph Pleger:

Hello,



systemd-time-wait-sync.service is running but has not completed.
I wonder if that is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940840
https://github.com/systemd/systemd/issues/14061

Which NTP service do you use?


I am using chrony, because the server is offering time services to NTP
clients.

Regards
    Christoph

PS: As a (temporary) workaround, I created an override file for
systemd-time-wait-sync.service that just calls /bin/true .
   



Have you tried to simply disable the service?


I have now, and it works. Any idea what might have enabled it? I have
quite old entries in /root/.bash_history, but no signs of that I
enabled that service manually, I did not even know about its existence
before monday ...


Nowadays, systemd-time-wait-sync.service is disabled in presets. I don't 
now if this was (already) the case for Bullseye (which I no longer use).


Might be that you enabled it via presets / it was enabled via presets.



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Many systemd units do not start anymore

[Michael Biebl]

Am 07.02.24 um 11:32 schrieb Christoph Pleger:

Hello,



systemd-time-wait-sync.service is running but has not completed.
I wonder if that is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940840
https://github.com/systemd/systemd/issues/14061

Which NTP service do you use?


I am using chrony, because the server is offering time services to NTP
clients.

Regards
   Christoph

PS: As a (temporary) workaround, I created an override file for
systemd-time-wait-sync.service that just calls /bin/true .
  


Have you tried to simply disable the service?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Many systemd units do not start anymore

[Michael Biebl]

Am 05.02.24 um 21:38 schrieb Michael Biebl:

This is the output of systemctl list-jobs :

JOB UNIT TYPE  STATE
102 autofs.service   start waiting
82  mlocate.timer    start waiting
80  e2scrub_all.timer    start waiting
117 cron.service start waiting
1   graphical.target start waiting
140 apache2.service  start waiting
127 nullmailer.service   start waiting
81  phpsessionclean.timer    start waiting
94  nslcd.service    start waiting
40  time-sync.target start waiting
86  logrotate.timer  start waiting
83  man-db.timer start waiting
84  apt-daily-upgrade.timer  start waiting
115 systemd-update-utmp-runlevel.service start waiting
135 atd.service  start waiting
79  timers.target    start waiting
87  apt-daily.timer  start waiting
39  systemd-time-wait-sync.service   start running
88  fstrim.timer start waiting
2   multi-user.target    start waiting

As you can see, there are really many failed services. It seems that
systemd-time-wait-sync.service is waiting for systemd-timesyncd to
synchronize the clock, but systemd-timesyncd is not installed at all.


Those services are not failed, they are waiting for their dependencies.

systemd-time-wait-sync.service is running but has not completed.
I wonder if that is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940840
https://github.com/systemd/systemd/issues/14061

Which NTP service do you use?
Could you try with systemd-timesyncd?



If you are not using systemd-timesyncd, you could also consider 
disabling systemd-time-wait-sync.service (via systemctl disable).


The default is disabled in Debian:

# systemctl status systemd-time-wait-sync.service
○ systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized
 Loaded: loaded 
(/usr/lib/systemd/system/systemd-time-wait-sync.service; disabled; 
preset: disabled)

 Active: inactive (dead)
   Docs: man:systemd-time-wait-sync.service(8)





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Many systemd units do not start anymore

[Michael Biebl]

This is the output of systemctl list-jobs :

JOB UNIT TYPE  STATE
102 autofs.service   start waiting
82  mlocate.timerstart waiting
80  e2scrub_all.timerstart waiting
117 cron.service start waiting
1   graphical.target start waiting
140 apache2.service  start waiting
127 nullmailer.service   start waiting
81  phpsessionclean.timerstart waiting
94  nslcd.servicestart waiting
40  time-sync.target start waiting
86  logrotate.timer  start waiting
83  man-db.timer start waiting
84  apt-daily-upgrade.timer  start waiting
115 systemd-update-utmp-runlevel.service start waiting
135 atd.service  start waiting
79  timers.targetstart waiting
87  apt-daily.timer  start waiting
39  systemd-time-wait-sync.service   start running
88  fstrim.timer start waiting
2   multi-user.targetstart waiting

As you can see, there are really many failed services. It seems that
systemd-time-wait-sync.service is waiting for systemd-timesyncd to
synchronize the clock, but systemd-timesyncd is not installed at all.


Those services are not failed, they are waiting for their dependencies.

systemd-time-wait-sync.service is running but has not completed.
I wonder if that is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940840
https://github.com/systemd/systemd/issues/14061

Which NTP service do you use?
Could you try with systemd-timesyncd?

Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Stop packagekitd from downloading updates

[Michael Biebl]

In case of GNOME, you might try the following

gsettings set org.gnome.software download-updates false

(gnome-software used packagekitd internally)


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Help ! No syslog anymore

[Michael Biebl]

Am 13.11.23 um 10:13 schrieb Bhasker C V:

I forgot to answer the question on why I am doing this
I am experimenting on a no-log system where there is no writes 
what-so-ever to /var/log (except for mails) or systemd journal 
(currently kept volatile)

/tmp/ is tmpfs mounted
Attached is the rsyslog config as-it-is being used now.



With the attached rsyslog.conf, disabling PrivateTmp makes rsyslog log 
to /run/server.log correctly (verified locally).


I can only assume you didn't follow my instructions properly.

Please make sure after following my instruction that you have afterwards
# systemctl show -P PrivateTmp rsyslog.service
no

Btw, for your use case, a subdirectory in /run would be more suitable, 
like say /run/syslog/.


Also, you currently have
*.* -/tmp/server.log
*and*
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,audit,news.none-/tmp/server.log

This doesn't make any sense.
This will basically duplicate the log messages in /tmp/server.log and 
interleave them.


Either you split up the logs facilities and log them to separate files 
or you only keep a single log rule like


*.* -/tmp/server.log

which simply logs everything to /tmp/server.log



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Help ! No syslog anymore

[Michael Biebl]

Am 12.11.23 um 08:18 schrieb Bhasker C V:

Hi,
I have tried removing PrivateTmp=no in the rsyslog service file and it 
still doesnt work


I assume you mean PrivateTmp=yes?


I  have removed the service file which I had created too.
I found that when I run the daemon manually, it works well. Hence I have 
disabled rsyslog and I have put the daemon startup in my rc-local


But yes, removing PrivateTmp doesnt help.
I am happy to troubleshoot this if anyone wants me to be a QA for this.


As a first step, please share your complete rsyslog config *verbatim*


Michael

[Not subsribed to debian-user, so please CC on replies]


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Help ! No syslog anymore

[Michael Biebl]

The service file you posted is not a good idea. Please remove it again.


If moving the log file out of /tmp is not an option, please run
systemctl edit rsyslog.service
and disable PrivateTmp via

[Service]
PrivateTmp=no


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bookworm: NetworkManager

[Michael Biebl]

I want NetworkManager to not over write /etc/resolv.conf

According to the docs if dns=none is set it will not touch /etc/resolv.conf


This should work, and this does work here.

If not, please do file a bug report.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bookworm: NetworkManager

[Michael Biebl]

Is /etc/resolv.conf a real file or a symlink?
If the latter, where does it point to?

Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Installing Gnome Desktop on Bookworm Cloud Image Fails due to netdev GID

[Michael Biebl]

Hi Shawn,

this sounds like a bug in the cloud images.
Not quite sure, why they need the netdev (system) group, but if that 
user is created by them, they should do so as a system user.


Could you please inform the cloud image maintainers?

https://wiki.debian.org/Teams/Cloud
https://salsa.debian.org/cloud-team

Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Re: 60-serial.rules, broken

[Michael Biebl]

Not sure if it's fixed in Bookworm already. The upstream fix went in at
v253. Bookworm is at 252.6 which doesn't exist as a tag in the upstream
repo so I cannot check if the fix was backported.


stable/point releases can be found in the systemd-stable repository. See
https://github.com/systemd/systemd-stable/


OpenPGP_signature
Description: OpenPGP digital signature

Re: Syslog/Rsyslog/Systemctl issue

[Michael Biebl]

Are you using SELinux or AppApparmor ?

Have you tried disabling it?


OpenPGP_signature
Description: OpenPGP digital signature

Re: usrmerge problem on docker with upgrade

[Michael Biebl]

What you said about overlayfs is true and usrmerge is imho giving a 
rather clear error message.


That said, I thought the best practice for docker containers is to throw 
them away and rebuild them and that upgrading containers is frowned upon?


If you build / pull a new bookworm docker container, it should be setup 
as merged-usr from the start.


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Re: How to configure (aka deal with) /tmp in the best way?

[Michael Biebl]

while the OP had an entry for /tmp in teir /etc/fstab.



Wow!
AFAICT, i did not create any systemd files nor ran a generator or such.
Apart from listing units, i did not interfere ... wait ... i recall
using the systemctl edit command once 


So, what likely happened is:
- You had an fstab entry for /tmp
- systemd via systemd-fstab-generator generated a corresponding runtime 
unit file tmp.mount in /run during boot
- You ran systemctl edit --full tmp.mount, which created a persistent 
copy of tmp.mount in /etc/systemd/system/


OpenPGP_signature
Description: OpenPGP digital signature

Re: usrmerge

[Michael Biebl]

On Sat, Oct 01, 2022 at 11:06:55AM +0100, billium wrote:

Since the last update to my debian testing I am unable to install anything
or upgrade.

Setting up usrmerge (31) ...

FATAL ERROR:
Both /lib/x86_64-linux-gnu/libc.so.6 and /usr/lib/x86_64-linux-gnu/libc.so.6
exist.


How did you arrive in this state?  Is /lib already a symlink to /usr/lib
on your system?


This is a good question.
billium, if you by any chance have a backup of your system from before 
the upgrade, it would be great if you can file a bug report against the 
usrmerge package so its maintainers can have a look.


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Re: *Now* what is starting ssh-agent?

[Michael Biebl]

Can you post the output of
systemd-cgls


OpenPGP_signature
Description: OpenPGP digital signature

Re: network-manager-gnome - no primary & secondary dns possible?

[Michael Biebl]

Am 16.10.21 um 09:27 schrieb dude:

Hello,

on latest Debian 11 + MATE Desktop (it is software simplicity at it's 
best :)


why is it not possible to set primary & secondary dns via 
network-manager-gnome? (only "additional dns")


It is possible. Choose
Method: Automatic (DHCP) addresses only

[Methode: Automatisch (DHCP), nur Adressen]

then specify your DNS servers manually.


also: it used to be /etc/resolv.conf

where nameservers are set


It still is


systemd is doing it’s own thing

/etc/systemd/resolved.conf


Completely unrelated file





OpenPGP_signature
Description: OpenPGP digital signature

Re: exim update not responding to update-rc.d

[Michael Biebl]

Am 07.05.21 um 02:12 schrieb Michael Biebl:

exim4 is unfortunately still SysV-only and doesn't ship a native systemd
.service file. So the correct command is

"update-rc.d exim4 disable"


For the curious: you can run "systemctl disable exim4" as well.
This will just run the above command though via
/lib/systemd/systemd-sysv-install

It's a thin wrapper to make systemctl more convenient to use and you 
don't need to remember whether a service has a native .service unit file 
or still ships only a legacy SysV init script.




OpenPGP_signature
Description: OpenPGP digital signature

Re: exim update not responding to update-rc.d

[Michael Biebl]

exim4 is unfortunately still SysV-only and doesn't ship a native systemd
.service file. So the correct command is

"update-rc.d exim4 disable"

"update-rc.d exim4 remove" will remove the symlinks in /etc/rc?.d/ but on
the next package update, they will be recreated.

So if you want to make this a permanent change, use "disable"

man update-rc.d has a section "DISABLING INIT SCRIPT START LINKS"

Regards,
Michael


signature.asc
Description: This is a digitally signed message part

HEADSUP: systemd now defaults to cgroupsv2

[Michael Biebl]

Hi,

with systemd 247.2-2, the default cgroup hierarchy has been switched to 
unified (i.e. cgroupv2).
If you want to read more about the benefits of cgroupv2 vs cgroupv1, I 
would suggest [1].

In Debian, all major container tools should support cgroupv2.
My special thanks go to Ryutaroh Matsumoto, who has been driving this 
effort [2]. I'd also like to thank Arnaud Rebillout for beeing very 
cooperative and preparing the new docker 20.x upload.


Please test the new setup and report any issues you find (file them 
againt the systemd package, we will re-assign/user-tag accordingly).

You can (temporarily) switch back to the old setup by adding

systemd.unified_cgroup_hierarchy=false

to the kernel command line, should that be necessary.

Regards,
Michael

[1] 
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#issues-with-v1-and-rationales-for-v2
[2] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintain...@lists.alioth.debian.org;tag=cgroupv2




OpenPGP_signature
Description: OpenPGP digital signature

Re: Re: Mounting /dev/shm noexec

[Michael Biebl]

Also related

https://github.com/systemd/systemd/pull/17238#discussion_r499375614



signature.asc
Description: OpenPGP digital signature

Heads up: persistent journal has been enabled in systemd

[Michael Biebl]

Hi,

with today's upload of systemd 244.1-2 I finally enabled persistent
journal by default [1]. It has been a long requested feature.

The package will create a directory /var/log/journal on upgrades and new
installs, which enables persistent journal in so called auto mode.

If you decide, that you want to disable the persistent journal again,
you can run:
journalctl --relinquish-var; rm -rf /var/log/journal

Future package updates will respect this choice and not re-create the
directory. You can, of course, also configure this explicitly via the
Storage= option in journald.conf.

Depending on how it goes, I might ask the ftp-masters to lower the
priority of rsyslog from important to optional, so it would no longer be
installed by default on new bullseye installations.
This would avoid, that we store log messages twice on disk.
Users that prefer text logs can of course still install rsyslog by
default (or their syslogger of choice).
Alternative init systems might consider adding a Recommends on a syslog
implementation of their choice or creating a task, which would pull in a
syslogger.

Here are some resources that you might find useful:
- man journald.conf
  https://www.freedesktop.org/software/systemd/man/journald.conf.html#
- man journalctl
  https://www.freedesktop.org/software/systemd/man/journalctl.html#
- man systemd-journald.service
  https://www.freedesktop.org/software/systemd/man/systemd-journald.html#

Regards,
Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717388





signature.asc
Description: OpenPGP digital signature

Re: systemd-container login as root no longer possible?

[Michael Biebl]

Hi

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830255
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731656

might be related.
Does it help if you add pts/0 to /etc/securetty inside your buster
container?
Would be great if you can report back if that fixes your issue.
If you want to use machinectl, you also need to have dbus installed
inside your container.

Interesting to see that /etc/securetty has apparently been removed just
recently. That change is unstable only, i.e. won't help you for a buster
container. See
https://tracker.debian.org/news/1042624/accepted-shadow-147-1-source-into-unstable/


-- 
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

Re: Unreliable systemd user service

[Michael Biebl]

Hi

>  Why is there no "the graphical session is ready"
> systemd target?

There is, incidentally it is named graphical-session.target :-)
See man systemd.special

Unfortunately, no display/session manager is hooked up yet to manage the
lifetime of that target, so you can't make use of that target as of now.

Martin Pitt has been working on that in the past, see
https://lists.freedesktop.org/archives/systemd-devel/2018-June/040952.html
which contains a few references to work from 2016.

When Martin left Canonical, work on this mostly stopped and I don't know
what the current state is in that regard.
I did find
https://blogs.gnome.org/laney/2018/06/26/starting-sessions-with-systemd/
so I hope we will eventually see proper support for
graphical-session.target.

Regards,
Michael


-- 
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

Re: systemd+anacron breaks cron jobs

[Michael Biebl]

Am 05.12.18 um 11:35 schrieb Kamil Jońca:

> So I cannot drop (ana)cron :)  EOT

With your specific set of requirements, you are most likely best served
by cron (and anacron if your system is not continuously running).

I still don't understand why you need to start your backup task as user
service and during boot instead of just making it a system service, but
that's ok. It's ultimately your decision.

My general remark that anacron is typically not needed anymore, still
stands though (even if it doesn't apply for your specific use case).


Regards,
Michael


-- 
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

Re: systemd+anacron breaks cron jobs

[Michael Biebl]

Am 05.12.18 um 11:04 schrieb Kamil Jońca:

> But 'enable-linger' starts my ALL services, which is not what I want.
> I want to start only timers.

Since you can only have one systemd --user instance, this is not possible.
You can't have a systemd --user instance which is started during boot
with only timers.target and a second systemd --user instance which is
started on first login with default.target.


Regards,
Michael
-- 
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

Re: systemd+anacron breaks cron jobs

[Michael Biebl]

Am 05.12.18 um 10:49 schrieb Michael Biebl:
> Am 05.12.18 um 10:47 schrieb Kamil Jońca:

>> How can I:
>> 1. start services only with graphical login and
> 
> You can't. At least not yet. Use ~/.config/autostart

Some work has already been done to support graphical-session.target

https://www.freedesktop.org/software/systemd/man/systemd.special.html#graphical-session.target

We are not there yet, though.

A bit more dated is this video from systemd.conf
https://www.youtube.com/watch?v=hq18daxTkLA

Regards,
Michael
-- 
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

Re: systemd+anacron breaks cron jobs

[Michael Biebl]

Am 05.12.18 um 10:47 schrieb Kamil Jońca:
> Michael Biebl  writes:
> 
>> Am 05.12.18 um 10:04 schrieb Kamil Jońca:
>>> Michael Biebl  writes:
>>
>>>>>  which in turn, can break ALL your "user" units)
>>>>
>>>> I'd be interested to know, what exactly you have in mind here. I'm not
>>>> aware of such a breakage.
>>>
>>> For example: I have (--user)
>>> kj-keepassx.service - my own service with keepasx
>>> xscreensaver-monitor.service - my own service which to monitor screensaver
>>>
>>> These services should NOT be run withoud graphical login.
>>
>> If those services are tied to a X login session, they should not be
>> started via systemd --user (at least, not yet)
>>
>> Let me go into a bit more detail.
>>
>>
>> There is only ever *one* systemd --user instance per user. It is
>> typically started, the first time you log in and stopped, once there is
>> no more active login session for a particular user.
>>
> [...snip...]
> I knew all you wrote.
> So I my question still is:
> 
> How can I:
> 1. start services only with graphical login and

You can't. At least not yet. Use ~/.config/autostart
This is what I trying to explain.

> 2. start timers irrespective of graphical login.

If you want them to be started during boot, use enable-linger


-- 
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

Re: systemd+anacron breaks cron jobs

[Michael Biebl]

Am 05.12.18 um 10:04 schrieb Kamil Jońca:
> Michael Biebl  writes:

>>>  which in turn, can break ALL your "user" units)
>>
>> I'd be interested to know, what exactly you have in mind here. I'm not
>> aware of such a breakage.
> 
> For example: I have (--user)
> kj-keepassx.service - my own service with keepasx
> xscreensaver-monitor.service - my own service which to monitor screensaver
> 
> These services should NOT be run withoud graphical login.

If those services are tied to a X login session, they should not be
started via systemd --user (at least, not yet)

Let me go into a bit more detail.


There is only ever *one* systemd --user instance per user. It is
typically started, the first time you log in and stopped, once there is
no more active login session for a particular user.

If you have multiple active login sessions (say X, and one console login
on tty2), you still have only one systemd --user instance.
If you now logout from X, the systemd --user instance is not stopped,
only if you also logout from tty2.

I hope, you can now see that your kj-keepassx.service is not going to work.

What you really want, is to start that service as part of a X login
session. Those are traditionally handled via
/etc/xdg/autostart and ~/.config/autostart


There are attempts to provide such a XDG autostart equivalent facility
in systemd, by providing a target, which becomes active once a X session
starts and becomes inactive, once the X session ends.
User units which are supposed to be tied to X sessions can then bind to
that target.

See https://blogs.gnome.org/laney/2018/06/26/starting-sessions-with-systemd/
if you want to read a bit more about it.


For the time being, starting a service via a systemd user service which
is bound to the life-time of an X session, is not really supported and I
would recommend you use ~/.config/autostart for it instead.

Regards,
Michael

-- 
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

Re: systemd+anacron breaks cron jobs

[Michael Biebl]

Am 05.12.18 um 08:54 schrieb Kamil Jońca:
> "User" task aren't started until user logs in. (You should play with
> enable-linger,

I haven't read the full discussion, so I missed the part that you are
apparently using a user crontab.

Just curious: Why are you starting the backup task via a user crontab
and not as a system cron job? Are you only saving the users /home/
directory?


It's correct, that "systemd --user"  is started if you log in, or if you
explicitly enable linger for this user (then it is started during boot).


>  which in turn, can break ALL your "user" units)

I'd be interested to know, what exactly you have in mind here. I'm not
aware of such a breakage.


Regards,
Michael

-- 
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

Re: systemd+anacron breaks cron jobs

[Michael Biebl]

Am 05.12.18 um 07:41 schrieb Michael Biebl:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864213#25
> If you drop /lib/udev/rules.d/60-anacron.rules my bet is that the
> problem is gone.

Btw, I'd go as far and say that you can safely drop anacron these days.
A lot of Debian packages which ship a cron job also ship a native
systemd .timer. Such persistent timers handle systems which don't run
24/7 in a much better way.

In your case, I would recommend to use a .timer to start your backup
task. The arch wiki [2] is a good start, or simply take a look at
existing timers on your system:

systemctl cat logrotate.service logrotate.timer

Regards,
Michael

[1]
https://www.freedesktop.org/software/systemd/man/systemd.timer.html#Persistent=
[2] https://wiki.archlinux.org/index.php/Systemd/Timers
-- 
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

Re: systemd+anacron breaks cron jobs

[Michael Biebl]

> On Mon, 03 Dec 2018, Kamil Jońca wrote:
>> >> Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' 
>> >> timed out. Killing.
>> > See, someone or some script told systemd to stop anacron (or maybe to
>> > stop-and-start/restart it).  THIS is causing the undesired behavior.
>> 
>> Dec 03 00:22:24 alfa systemd[1]: Stopping Run anacron jobs...
>> Dec 03 00:22:24 alfa anacron[8919]: Received SIGUSR1
>> Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' timed 
>> out. Killing.
> 
> Looks like something asked systemd to send sigusr1 to anacron, which is
> "clean exit" for anacron.  Since the anacron package told systemd to use
> "killmode mixed", it waits for a while, then proceeds to SIGKILL
> everything in the group because they took too long to die.
> 
> It is a bug, but on anacron, not systemd.  systemd is doing exactly what
> it was (mis)configured to do by the anacron package.
> 
> And something *is* asking anacron to restart or to stop.  Look at your
> log rotation scripts (and also anacron's).

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864213#25
If you drop /lib/udev/rules.d/60-anacron.rules my bet is that the
problem is gone.
-- 
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

Re: Starting powertop --auto-tune from systemd

[Michael Biebl]

Am 10.03.2018 um 18:55 schrieb Rainer Dorsch:
> [Please follow-up to debian-user]
> 
> Hello,
> 
> I run
> 
> /usr/bin/powertop --auto-tune
> 
> to optimize the power consumption of my system. Running it manually works 
> nicely. When I try to run from systemd, I see no effect :-/
> 
> I followed
> 
> https://wiki.archlinux.org/index.php/Powertop#Apply_settings
> 
> added
> 
> root@master:~# cat /etc/systemd/system/powertop.service 
> [Unit]
> Description=Powertop tunings
> 
> [Service]
> ExecStart=/usr/bin/powertop --auto-tune
> RemainAfterExit=true
> 
> [Install]
> WantedBy=multi-user.target
> root@master:~# 
> 
> enabled it for systemd and got
> 
> root@master:~# systemctl status powertop.service 
> ● powertop.service - Powertop tunings
>Loaded: loaded (/etc/systemd/system/powertop.service; enabled; vendor 
> preset: enabled)
>Active: active (exited) (Result: exit-code) since Sat 2018-03-10 18:29:53 
> CET; 22min ago
>   Process: 642 ExecStart=/usr/bin/powertop --auto-tune (code=exited, 
> status=203/EXEC)
>  Main PID: 642 (code=exited, status=203/EXEC)

systemct tells you there was a problem trying to execute the binary.
Possibly because it's the wrong path?
$ whereis powertop
powertop: /usr/sbin/powertop /usr/share/man/man8/powertop.8.gz

(note bin vs sbin)
-- 
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

Re: Bug#889144: systemd 237-1: problem starting dnsmasq

[Michael Biebl]

Am 07.02.2018 um 22:12 schrieb Jonathan de Boyne Pollard:
> Michael Biebl:
> 
>> If other services depend on dnsmasq, please keep
>> https://www.lucas-nussbaum.net/blog/?p=877 in mind
>>
> Please do not.  It is an erroneous conclusion based upon a faulty
> analysis that conflates the readiness protocols
> <http://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html> with
> the non-daemon nature of the way that things are run by the |service|
> command

[..]

So how exactly does dnsmasq signal readiness if it's run in foreground?
It does neither implement sd_notify nor use D-Bus activation.
So there is no way for systemd to know when it's ready to accept
connections. As a result, daemon, which depend on dnsmasq would be
started immediately once the dnsmasq binary has been spawned.





-- 
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

Re: Embarrassing security bug in systemd

[Michael Biebl]

Am 07.12.2017 um 15:37 schrieb Roberto C. Sánchez:
> On Thu, Dec 07, 2017 at 03:03:44AM -0600, Dave Sherohman wrote:
>>
>> I no longer have any non-systemd machines handy to verify this on, but
>> my memory is that I have *always* been able to use halt/poweroff/reboot
>> commands from the console without requiring sudo or entering a password,
>> and I've been using Debian since 2000ish, well before systemd was even a
>> gleam in some programmer's eye.  /sbin/shutdown may have also been
>> freely available at the console, but I don't remember that one clearly,
>> since I didn't use it all that often once I discovered the others.
>>
> I just did a fresh install of wheezy (7.11) with all defaults.  Here is
> what happened:
> 
> testuser@debian:~$ cat /etc/debian_version
> 7.11
> testuser@debian:~$ /sbin/reboot
> reboot: must be superuser.
> testuser@debian:~$ ls -l /sbin/reboot
> lrwxrwxrwx 1 root root 4 Jul 14  2013 /sbin/reboot -> halt
> testuser@debian:~$ ls -l /sbin/halt
> -rwxr-xr-x 1 root root 15184 Jul 14  2013 /sbin/halt
> 
> The situation is basically the same for /sbin/shutdown.

Now try CTRL+ALT+DEL on the console. This will reboot your system.
See /etc/inittab:

# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now


Next, try hitting the power button. This will shut down your system.
On systems with acpi support, Debian has been installing acpid +
acpi-support-base in the past. See
/etc/acpi/powerbtn-acpi-support.sh


Next install a display manager, like gdm3 or lightdm. This will allow
you shutdown/reboot the system as well.


Basically, it was a completely inconsistent mess before systemd.
Now you at least have a central place where you can configure your
system behaviour.

Michael


-- 
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

Re: Embarrassing security bug in systemd

[Michael Biebl]

Am 06.12.2017 um 23:53 schrieb Michael Lange:
> Hi,
> 
> uh, I guess you ought to have used your time to check your machine and
> read some docs instead of figuring out how to best insult the debian
> developers ;)
> (scnr)
> 
> On 06 Dec 2017 22:52:17 +0100
> Urs Thuermann  wrote:
> 
> (...)
>> I wonder how can such a severe bug make it into a Debian stable
>> distribution?  And is this just an insane default setting on Debian's
>> side or is it yet another instance of brain-dead systemd behavior?
> 
> Maybe I am just a brain-dead loony, but personally I prefer to be able to
> shut down or reboot my system without having to type a password. If you
> do not like this behavior you might have to learn how to define
> polkit rules.

For the interested reader, see
/usr/share/polkit-1/actions/org.freedesktop.login1.policy

org.freedesktop.login1.power-off has the following defaults


  auth_admin_keep
  auth_admin_keep
  yes


As has already been mentioned, active, local users can shutdown/reboot
the system without requiring a password. This is intended behaviour (for
the reasons already mentioned) and can indeed be overridden by custom
polkit rules.


-- 
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

Re: Thunderbird no longer opens links

[Michael Biebl]

Am 01.12.2017 um 15:40 schrieb to...@tuxteam.de:
> On Fri, Dec 01, 2017 at 03:30:50PM +0100, solitone wrote:
>> On 01/12/17 15:22, Jonathan Dowland wrote:
>>> AppArmor is not enabled in current
>>> stable [...]
> 
>> I have stretch, and didn't requested it manually, but was installed
>> with the latest kernel update from stretch backports. I think it was
>> installed because of that backported kernel version:
> 
> [...]
> 
>> Install: libapparmor-perl:amd64 (2.11.0-3, automatic), apparmor:amd64 (2
>> .11.0-3, automatic)
>> Upgrade: linux-image-4.13.0-0.bpo.1-amd64:amd64 (4.13.4-2~bpo9+1, 4.13.1
>> 3-1~bpo9+1)
> 
> Woah.
> 
> Thanks for the heads-up!

I think it might be useful to open a (wishlist) bug report against the
linux package to not add the recommends when building for stretch-backports

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-- 
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

Re: Missing qt5-designer in Stretch

[Michael Biebl]

Am 14.11.2017 um 16:48 schrieb Marc Shapiro:
> On 11/14/2017 12:18 AM, Christian Seiler wrote:
>> Am 2017-11-14 08:05, schrieb Marc Shapiro:
>>> Am I missing something, somewhere?  Or is qt5-designer not packaged
>>> for Debian?
>>
>> Designer for Qt5 can be found in the qttools5-dev-tools package
>> in Stretch.
>>
>> Regards,
>> Christian
>>
> I installed qttools5-dev-tools package, but it still looks for designer
> and assistant in the old qt4 directory.  What am I doing wrong?

You probably want qt5-default

https://packages.debian.org/sid/qt5-default

-- 
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

Re: System becomes inaccessible after upgrade of libgl1-mesa-glx to version 17.2.2-1

[Michael Biebl]

Am 19.10.2017 um 21:09 schrieb Simon Pepping:

> The solution seems simple:
> 
> The following packages will be REMOVED:
>   libglvnd0-nvidia
> The following NEW packages will be installed:
>   libglvnd0"
> 
> But how do you do that with an inaccessible system? The system can be
> booted in recovery mode, and the change can be made there. But the
> network is not yet up and running.

You can do the following (assuming you use grub):
Change the kernel command line and append
systemd.unit=multi-user.target

This will boot (one-time) into a multi-user system (including network)
but not start the display manager.




-- 
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

Re: [Pkg-utopia-maintainers] network-manager-gnome - Ethernet - Security - 802.1x - Password can't be changed

[Michael Biebl]

Am 19.10.2017 um 14:39 schrieb Daniel:
> Hello,
> 
> I'm using debian 9 up to date.
> 
> Desktop Environment: Gnome
> 
> Scenario: Where I work we connect to the network with Ethernet and
> 802.1x peap authentication. Each X days passwords expire and we need
> to change it.
> 
> Problem: When I try to change the password to the new one and I apply
> changes everything seems fine (I apply and get no errors), but when I
> open the same settings back again the old password still remains, so
> the password is not really changed no matter how many times I try.
> 
> Workaround so far: The only way I found so far to effectively set the
> password is to disable security completely and enable it back again to
> define all values from scratch.
It looks like you used gnome-control-center to change the password.
Does it make a difference if you use nm-connection-editor (from
network-manager-gnome) to change the password?


-- 
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

Re: ugly fonts in thunderbird after sid upgrade

[Michael Biebl]

Am 16.10.2017 um 22:50 schrieb Pétur Viljamson:
> I have ugly fonts in thunderbird after updating my Debian sid today.

It's the latest freetype upgrade causing this for users which use
subpixel antialiasing. Thunderbird needs to be updated to cope with the
changes in freetype 2.8.1

see https://bugs.debian.org/878870


-- 
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

D-Bus (Re: systemd process(es) consuming CPU when laptop lid closed)

[Michael Biebl]

Am 17.10.2017 um 14:49 schrieb Jimmy Johnson:
>>> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;

> Michael I found it interesting that I do not have a folder /org/ .hidden
> or not and that's with kde5 desktop on Stretch.

Those are D-Bus path names, not file names.

https://dbus.freedesktop.org/doc/dbus-tutorial.html explains the basic
concepts.

If you want to dig a bit deeper, install d-feet to explore what D-Bus
services are running on your system and what API they provide.

Michael
-- 
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

Re: systemd process(es) consuming CPU when laptop lid closed

[Michael Biebl]

Am 16.10.2017 um 02:56 schrieb Glen B:
> On 10/15/2017 10:31 AM, Michael Biebl wrote:
>> Am 14.10.2017 um 21:48 schrieb Glen B:
>>>295 root  20   07448   4432   3992 R 41.2  0.9   0:54.81 
>>> systemd-logind
>>>298 message+  20   06260   3636   3268 S 17.6  0.7   0:17.12 
>>> dbus-daemon
>> That looks like there is a huge amount of dbus messages sent.
>> Can you run dbus-monitor --system (as root) to see what those messages are?
> 
> That's an interesting command, lots of information was spat out. Here's 
> an excerpt of what was put out:
> 
> 
>   uint32 0
> error time=1508114297.985967 sender=:1.0 -> destination=:1.1 
> error_name=org.freedesktop.systemd1.UnitMasked reply_serial=26352
>     string "Unit suspend.target is masked."
> signal time=1508114297.986032 sender=:1.0 -> destination=(null 
> destination) serial=52814 path=/org/freedesktop/systemd1; 
> interface=org.freedesktop.systemd1.Manager; member=UnitNew
>     string "suspend.target"
>     object path "/org/freedesktop/systemd1/unit/suspend_2etarget"
> signal time=1508114297.986058 sender=:1.0 -> destination=(null 
> destination) serial=52815 path=/org/freedesktop/systemd1; 
> interface=org.freedesktop.systemd1.Manager; member=UnitRemoved
>     string "suspend.target"
>     object path "/org/freedesktop/systemd1/unit/suspend_2etarget"
> signal time=1508114297.991185 sender=:1.1 -> destination=(null 
> destination) serial=26353 path=/org/freedesktop/login1; 
> interface=org.freedesktop.login1.Manager; member=PrepareForSleep
>     boolean true
> method call time=1508114297.992516 sender=:1.1 -> 
> destination=org.freedesktop.systemd1 serial=26354 
> path=/org/freedesktop/systemd1; 
> interface=org.freedesktop.systemd1.Manager; member=StartUnit
>     string "suspend.target"
>     string "replace-irreversibly"
> method call time=1508114297.993237 sender=:1.0 -> 
> destination=org.freedesktop.DBus serial=52816 
> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; 
> member=GetConnectionUnixUser
>     string ":1.1"
> method return time=1508114297.993292 sender=org.freedesktop.DBus -> 
> destination=:1.0 serial=13188 reply_serial=52816
> 
> 
> If I'm understanding this correctly, it looks like it's trying to 
> suspend but is somehow getting confused...

Not sure about the confused part. We might need a debug log for
systemd-logind.

That said, is that all? Given the high cpu usage for the dbus-daemon
process I was expecting it to be flooded by dbus messages.

You could also try stracing dbus-daemon and systemd-logind and see if
you get anything interesting.



-- 
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

Re: systemd process(es) consuming CPU when laptop lid closed

[Michael Biebl]

Am 14.10.2017 um 21:48 schrieb Glen B:
>   295 root  20   07448   4432   3992 R 41.2  0.9   0:54.81 
> systemd-logind
>   298 message+  20   06260   3636   3268 S 17.6  0.7   0:17.12 dbus-daemon

That looks like there is a huge amount of dbus messages sent.
Can you run dbus-monitor --system (as root) to see what those messages are?

-- 
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

Re: Rescue mode when root account locked

[Michael Biebl]

Am 20.09.2017 um 13:46 schrieb solitone:
> When I boot in rescue mode, I get this message:
> 
> Cannot open access to console, the root account is locked. See
> sulogin(8) man page for more details
> 
> When I press Enter to continue, it continues bootup in normal graphical
> mode.
> 
> Would it be wiser to unlock the root account, so that I can go into
> single user mode? Or is there something I can do, without unlocking the
> root account?

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211

-- 
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

Re: hibernate uses a wrong UUID

[Michael Biebl]

Am 10.09.2017 um 17:36 schrieb Michael Biebl:
> If you "make the swap partition bigger", you most likely changed the
> UUID. That's exactly what Alexander described you need to check and
> update if necessary.


Running "mkswap" on an existing swap partition will change its UUID.
(unless you specify the old one via the --uuid switch)

What often happens is that users install another distro onto another
partition. The installer usually runs mkswap on existing swap partitions
which breaks existing installations.



-- 
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

Re: hibernate uses a wrong UUID

[Michael Biebl]

Am 10.09.2017 um 16:51 schrieb Erwan David:
> Le 09/10/17 à 16:47, Alexander V. Makartsev a écrit :
>> You should not use "uswsusp" anymore on recent OS releases. Hibernate
>> should work "out-of-the-box" assuming swap partition is big enough.
>> Remove "uswsusp", double check "/etc/fstab" swap entry
>>
> "Should" is not an answer when it does not work anymore. Eg you add RAM
> and make a bigger swap partition -> stops working, what to do, where to
> chheck ?

If you "make the swap partition bigger", you most likely changed the
UUID. That's exactly what Alexander described you need to check and
update if necessary.


-- 
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

Re: hibernate uses a wrong UUID

[Michael Biebl]

Am 09.09.2017 um 18:50 schrieb Pierre Frenkiel:
> I have this in /etc/initramfs-tools/conf.d/resume
>     RESUME=UUID=42b1dc3e-6206-4bd5-9eb4-76e97f94cd65
> which is actually the UUID of the swap partition.
> 
> and after pm-hibernate and reboot, I find in syslog:
>    PM: Checking hibernation image partition
> /dev/disk/by-uuid/2fff8fc5-d304-418f-8d5c-c0ae12b23ac2
> and then, of course, "image not found" (no partition has this UUID)
> 
> Can anybody explain that?

Outdated initramfs?
After modifying /etc/initramfs-tools/conf.d/resume you need to run
update-initramfs


-- 
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

Re: systemd autocompletion does not work

[Michael Biebl]

Am 28.07.2017 um 06:14 schrieb Kamil Jońca:

> /etc/dbus-1/system.d/:
> 
> -rw-r--r-- 1 root root 3947 Apr 29  2014 org.freedesktop.systemd-shim.conf

Purge the systemd-shim package. This file from systemd-shim is breaking
systemd.



signature.asc
Description: OpenPGP digital signature

Re: systemd autocompletion does not work

[Michael Biebl]

Am 27.07.2017 um 19:09 schrieb Kamil Jońca:
> 
> 1. Box with debian sid, updated frequently
> 2. Recently I realized that completion of systemd units does not work,
> ie.
> $sudo systemd restart  gives me "@" sign only.
> I noticed that, at the moment of pressing tab I got in /var/log/auth.log
> --8<---cut here---start->8---
> 2017-07-27T19:01:37.228534+02:00 alfa dbus[685]: [system] Rejected send 
> message, 4 matched rules; type="method_call", sender=":1.507" (uid=1000 
> pid=10335 comm="systemctl --full --no-legend --no-pager list-unit-") 
> interface="org.freedesktop.systemd1.Manager" member="ListUnitFilesByPatterns" 
> error name="(unset)" requested_reply="0" 
> destination="org.freedesktop.systemd1" (uid=0 pid=1 comm="/sbin/init ")

Can you provide the systemd and dbus version and the output of
ls -la /etc/dbus-1/system.d/ /usr/share/dbus-1/system.d/


-- 
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

Re: systemd autocompletion does not work

[Michael Biebl]

Am 27.07.2017 um 22:20 schrieb Kamil Jońca:
> Michael Biebl <bi...@debian.org> writes:
> 
>> Am 27.07.2017 um 19:09 schrieb Kamil Jońca:
>>>
>>> 1. Box with debian sid, updated frequently
>>> 2. Recently I realized that completion of systemd units does not work,
>>> ie.
>>> $sudo systemd restart  gives me "@" sign only.
>>
>> ...
>>
>>> What am I missing?
>>
>> The tool is called systemctl, not systemd.
> 
> You're right, my typo.
> But what am I missing?
> KJ
> 

Are you sure you are using systemd as PID 1? Is systemd-sysv installed
and have you rebooted since installing that package?



signature.asc
Description: OpenPGP digital signature

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Michael Biebl]

Am 27.07.2017 um 20:21 schrieb Patrick Flaig:
> Sure, this is the content:
> 
> cat /tmp/foo/lib/systemd/network/99-default.link 

Thanks Patrick.
So, it seems the udev maintainer scripts detected at virtualized
environment which causes the following code to be triggered:

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/udev.postinst#n49

The /etc/systemd/network/99-default.link file overrides the the package
provided one from /lib/systemd/network/99-default.link

So, in order to enable the new naming scheme, remove
/etc/systemd/network/99-default.link then rebuild the initramfs.

On the next boot you should have the new network interface names.

Regards,
Michael


-- 
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

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Michael Biebl]

Am 27.07.2017 um 19:50 schrieb Patrick Flaig:
> Oh my fault, 99-default.link is available, I checked the wrong folder.
> The file is containing some text, saying that the machine is most likely a 
> virtualized guest.

Can you paste the contents verbatim.


-- 
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

Re: systemd autocompletion does not work

[Michael Biebl]

Am 27.07.2017 um 19:09 schrieb Kamil Jońca:
> 
> 1. Box with debian sid, updated frequently
> 2. Recently I realized that completion of systemd units does not work,
> ie.
> $sudo systemd restart  gives me "@" sign only.

...

> What am I missing?

The tool is called systemctl, not systemd.




signature.asc
Description: OpenPGP digital signature

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Michael Biebl]

Am 27.07.2017 um 18:55 schrieb debian-li...@patschie.de:

>> Am 27.07.2017 um 18:25 schrieb Michael Biebl <bi...@debian.org>:
>> lsinitramfs /boot/initrd.img-$(uname -r) | grep 99-default.link
>> lib/systemd/network/99-default.link
> Missing

Odd. Do you have that file on the host system?
Can you check with debsums -as udev systemd.

/usr/share/initramfs-tools/hooks/udev should copy that link file into
the initramfs.

Do you by chance have any custom initramfs hooks in
/etc/initramfs-tools/hooks which override the udev hook?




signature.asc
Description: OpenPGP digital signature

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Michael Biebl]

Am 27.07.2017 um 18:04 schrieb debian-li...@patschie.de:
> Hi Michael,
> 
> I forgot to mention that I also recreated the initramfs: 
> after several tries just to update it, I deleted the initramfs and recreated 
> it completely.
> But still the same effect.
> 
> Is there a way to manually check the contents of the initramfs, just to make 
> sure that the 70-persistent-net.rules isn’t there?


lsinitramfs /boot/initrd.img-$(uname -r) | grep  70-persistent-net.rules

This should come up empty.

The new naming is setup via /lib/udev/rules.d/80-net-setup-link.rules
and a link file called  99-default.link

lsinitramfs /boot/initrd.img-$(uname -r) | grep  80-net-setup-link.rules
lib/udev/rules.d/80-net-setup-link.rules
lsinitramfs /boot/initrd.img-$(uname -r) | grep 99-default.link
lib/systemd/network/99-default.link

Is this a bare metal or a VM?
-- 
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

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Michael Biebl]

Hi Patrick

Am 27.07.2017 um 17:15 schrieb debian-li...@patschie.de:
> Hi,
> 
> I’m running into some troubles to enable the predictable network interface 
> names for a system upgraded from Jessie.
> 
> What I figured out so far:
> Setting net.ifnames=1 on the kernel command line doesn’t help and seems no 
> longer to be supported parameter (at least "sysctl - a" doesn’t show it).

Setting that parameter should work, but it doesn't take precedence over
an existing /etc/udev/rules.d/70-persistent-net.rules

Since net.ifnames=1 is the default since stretch, you don't need to set
it explicitly though.

> Removing any /etc/udev/rules.d/ file handling the network interface doesn’t 
> bring the desired effect of having predictable network interface names.
> 
> I started now to compare /lib/udev/rules.d from a clean stretch installation 
> with the files on a upgraded system, the clean installation has much more 
> files.
> So next try reinstalling udev to get all missing/new rule files from stretch, 
> but that didn’t work either.
> 
> Any ideas what I could try next or missed to check?
> 

Most likely the file /etc/udev/rules.d/70-persistent-net.rules got
embedded in the initramfs. So once you removed that file, you also need
to rebuild the initramfs via update-initramfs -u

Michael



signature.asc
Description: OpenPGP digital signature

Re: Hibernate in stretch

[Michael Biebl]

Am 18.07.2017 um 05:02 schrieb behrad eslami:
> Hi 
> 
> Im installed stretch in thinkpad x260 and hibernate not work corrctly.
> When poweron laptop, resume hibernated desktop and suddeny go to the
> display manager and after login all application was closed
> 
> Graphical enviroment:
> i3
> lightdm
> tlp tlp-rdw tp-smapi-dkms acpi-call-dkms postfix (power saving)
> 
> Thanks 

Have you checked if
/etc/initramfs-tools/conf.d/resume
matches your swap partition? See /dev/disk/by-uuid/

-- 
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

Re: systemd & postgresql - flooding system log

[Michael Biebl]

Am 15.07.2017 um 00:07 schrieb Don Armstrong:
> This plugin is horribly designed, and runs su - $DBUSER -c [...] for its
> functioning.

Indeed.

> It should instead just su $DBUSER -c [...]; or better yet, not actually
> su to the database user, and instead run as a user which only has the
> ability to read the appropriate tables and cannot also write to.

There is an alternative utility called runuser which is more suitable
for such cases.
It uses a different pam config and doesn't start a systemd logind session.

-- 
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

Re: systemd & postgresql - flooding system log

[Michael Biebl]

Am 07.07.2017 um 16:03 schrieb Václav Ovsík:

>   Jul  7 15:42:35 rt2 systemd[1]: Started Session c4504 of user postgres.
>   Jul  7 15:42:35 rt2 systemd[1]: Started Session c4505 of user postgres.
>   Jul  7 15:42:35 rt2 systemd[1]: Started Session c4506 of user postgres.
>   Jul  7 15:42:35 rt2 systemd[1]: Started Session c4507 of user postgres.
>   Jul  7 15:42:35 rt2 systemd[1]: Started Session c4508 of user postgres.
>   Jul  7 15:42:36 rt2 systemd[1]: Started Session c4509 of user postgres.
> 
> Every minute 19 lines of this.


You create 19 PAM sessions for the postgres user per minute. What
exactly are you doing here?
-- 
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

Re: Superblock last write time is in the future.

[Michael Biebl]

Am 02.07.2017 um 17:49 schrieb Wellington Terumi Uemura:
> Just to give a feedback, this doesn't work if you have a second OS like
> Windows.

Windows (since 7) works fine with UTC. There is a registry key you can set.



-- 
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

Re: Stretch and network management

[Michael Biebl]

Am 28.06.2017 um 23:19 schrieb tony mollica:
> Networkmanager out, wicdin.
> 
> I purge both of these from the system an installed them one at a time,
> network-manager first.  It always connects to the wired interface but
> won't act reliably with the wireless connection.  I tried every which
> way but get either  a 'not managed' or 'not 'available' note in NMno
> matter what I put in the config files, or not.  No difference when using
> 'managed= TRUE or FALSE , or any other entries for that matter.  unreliable.

Could you try adding the following to
/etc/NetworkManager/NetworkManager.conf:

[device]
wifi.scan-rand-mac-address=no

Also make sure the wifi device is not configured in /etc/network/interfaces.

Does that help?


-- 
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

Re: no network after jessie -> stretch

[Michael Biebl]

Am 21.06.2017 um 17:53 schrieb D. R. Evans:
> I just completed an upgrade to stretch on an i386 machine.
> 
> There were no obvious showstopping errors during the install. I saw a few
> "unable to delete directory; directory not empty" errors fly by, but nothing
> that seemed dangerous, and the installation didn't complain about anything.
> 
> But when I tried the reboot following the upgrade, I lost all network
> connectivity. The boot screen said:
>   Failed to Start Network Manager Wait Online

Please share more details about your network configuration.
Do you use ifupdown to manage your interface, NetworkManager, something
else?

The error message above indicates, that you have network-manager
installed and since stretch NetworkManager-wait-online.service is
enabled by default (it wasn't in jessie).

Now, if you don't actually manage your interfaces with NetworkManager,
NetworkManager-wait-online.service might run into a timeout (of 30s).

The output nmcli might be helpful.


-- 
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

Re: Superblock last write time is in the future.

[Michael Biebl]

Am 21.06.2017 um 07:43 schrieb Wellington Terumi Uemura:

>  RTC in local TZ: yes
> 
> The bugreport show that this has been patched, anything else I could do
> to stop running system check/clean every time I boot?

I would set the system clock from LOCAL to UTC (see /etc/adjtime)


-- 
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

Re: gnome 3.22 unable to authenticate to google account

[Michael Biebl]

Am 13.05.2017 um 18:36 schrieb Michael Biebl:
> I'll ask the release team to unblock webkit2gtk 2.14.7-1

This happened in the mean time:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862502

-- 
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

Re: gnome 3.22 unable to authenticate to google account

[Michael Biebl]

Am 13.05.2017 um 00:54 schrieb andy:
> hello -
> 
> i recently upgraded my laptop from wheezy through jessie and straight
> on to stretch.  almost everything went much more smoothly than i had
> hoped.  the one glaring problem is that i am unable to re-add access to
> my gmail account and google calendars using either evolution or gnome's
> online accounts:
> evolution=3.22.6-1
> evolution-data-server=3.22.7-1
> gnome-online-accounts=3.22.5-1
> 


Known bug. Requires a newer webkit2gtk which is currently only available
in unstable.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862469


I'll ask the release team to unblock webkit2gtk 2.14.7-1


-- 
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

Re: systemd: How to get suricata started at boot?

[Michael Biebl]

Am 03.05.2017 um 13:12 schrieb Hans:
> Am Mittwoch, 3. Mai 2017, 12:38:39 CEST schrieb Dejan Jocic:
>> On 03-05-17, Hans wrote:
>>> Hello all,
>>>
> Hi Michael, high Dejan,
> 
> this works! But I will let the bugreport open (unless, you think it can be 
> closed), because the maintainer might want to look, why the installation 
> script in the package did not configure suricata correctly. 
> 
> However, if there is no bug found, so it is here on my system gone defective 
> by chance, who knows.

It's a valid bug in the package and needs to be fixed there. Don't close it.


-- 
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

Re: systemd: How to get suricata started at boot?

[Michael Biebl]

Am 03.05.2017 um 11:11 schrieb Hans:
> Hello all,
> 
> I have installed suricata on my system, but it will not start at boot.
> 
> When I manually start it, it is working well.
> 
> As the document advises, I copied  /lib/systemd/system/suricata.service to 
> /etc/systemd/system/suricata.service and tested with

You only need to copy suricata.service to /etc if you want to change its
contents. Even then, often drop-in snippets are preferrable, which only
override/extend the parts you need

> systemctl start suricata.service
> 
> "ps -aux | grep suricata" showed me the running process. But after reboot, 
> the 
> process is not started automatically. As init is no more supported by 
> suricata, but systemd,

The suricata package still ships a SysV init script, but if a systemd
service file exists, it takes precedence.

 how can I add this service into systemd, so that it is
> started automatically at boot? I am still not quite experienced with systemd.

systemctl enable suricata.service

will do the trick. That should be done by the package though.
I see you already filed a bug report [1] for that. The package should be
using init-system-helper/dh_systemd to help automate that.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861732

-- 
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

Re: device name (symlink) stability

[Michael Biebl]

Am 25.04.2017 um 16:09 schrieb Vincent Lefevre:
> Hi,
> 
> On 2017-04-25 12:14:30 +0200, Michael Biebl wrote:
>> Am 25.04.2017 um 10:53 schrieb Vincent Lefevre:
> [...]
>>> In particular, it is strange that all the symlinks point to sr0
>>> except cdrw, which now points to sr1.
>>
>> The udev rules responsible for creating those symlinks is
>> /lib/udev/rules.d/80-debian-compat.rules or
>>
>> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/extra/rules/80-debian-compat.rules#n18
>>
>> See the comment in there:
>>
>> # These rules will create symlinks for CD/DVD drives, to help old
>> # programs which are unable to automatically discover the devices.
>> # The first detected device gets the symlink, but this is not stable across
>> # reboots.
>>
>> So, yes, what you see can happen depending on the order devices are
>> discovered.
> 
> OK, but if sr0 is discovered first, then it should have all the
> symlinks, and if sr1 is discovered first, then it should have all
> the symlinks. But why do I get sr1 for only one of them?
> 
> lrwxrwxrwx  1 root root   3 2017-04-24 10:05:16 cdrom -> sr0
> lrwxrwxrwx  1 root root   3 2017-04-24 10:05:16 cdrw -> sr1
> lrwxrwxrwx  1 root root   3 2017-04-24 10:05:16 dvd -> sr0
> lrwxrwxrwx  1 root root   3 2017-04-24 10:05:16 dvdrw -> sr0
> 
> And why isn't there the same rule for cdrom?

I guess every sr0 can be considered a cdrom, but it's not necessarily a
dvd/cd writer.

> /lib/udev/rules.d/80-debian-compat.rules contains:
> 
> # These rules will create symlinks for CD/DVD drives, to help old
> # programs which are unable to automatically discover the devices.
> # The first detected device gets the symlink, but this is not stable across
> # reboots.
> ENV{ID_CDROM_CD_RW}=="?*", \
>   PROGRAM="/bin/sh -c 'ln -s %k /run/udev/link.cdrw 2>/dev/null; [ `readlink 
> /run/udev/link.cdrw` = %k ]", \
>   SYMLINK+="cdrw", OPTIONS+="link_priority=-100"
> ENV{ID_CDROM_DVD}=="?*", \
>   PROGRAM="/bin/sh -c 'ln -s %k /run/udev/link.dvd 2>/dev/null; [ `readlink 
> /run/udev/link.dvd` = %k ]", \
>   SYMLINK+="dvd", OPTIONS+="link_priority=-100"
> ENV{ID_CDROM_DVD_RW}=="?*", \
>   PROGRAM="/bin/sh -c 'ln -s %k /run/udev/link.dvdrw 2>/dev/null; [ `readlink 
> /run/udev/link.dvdrw` = %k ]", \
>   SYMLINK+="dvdrw", OPTIONS+="link_priority=-100"
> 
> but /lib/udev/rules.d/60-cdrom_id.rules contains:
> 
> KERNEL=="sr0", SYMLINK+="cdrom", OPTIONS+="link_priority=-100"


60-cdrom_id.rules is a rules provided by upstream,
80-debian-compat.rules a Debian specific file which we provide for
compat reasons.

I don't remember the details of 80-debian-compat.rules, but it's rather
ugly and it's maybe time to drop that hack early in the buster release
cycle.

-- 
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

Re: device name (symlink) stability

[Michael Biebl]

Hi

Am 25.04.2017 um 10:53 schrieb Vincent Lefevre:
> After a reboot of a Debian/unstable machine, I got:
> 
>   /dev/cdrw -> sr1
> 
> while it was
> 
>   /dev/cdrw -> sr0

[..]

> Is it normal that the device names are not stable?
> 
> In particular, it is strange that all the symlinks point to sr0
> except cdrw, which now points to sr1.

The udev rules responsible for creating those symlinks is
/lib/udev/rules.d/80-debian-compat.rules or

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/extra/rules/80-debian-compat.rules#n18

See the comment in there:

# These rules will create symlinks for CD/DVD drives, to help old
# programs which are unable to automatically discover the devices.
# The first detected device gets the symlink, but this is not stable across
# reboots.

So, yes, what you see can happen depending on the order devices are
discovered.

Michael
-- 
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

Re: Tuning boot time of my server

[Michael Biebl]

Am 08.04.2017 um 21:15 schrieb Markus Grunwald:
> Hello,
> 
> just for sports, I tried to minimise the boot time of my server, which
> is running systemd. I have one mayor blocker:
> 
>  % systemd-analyze blame
>  10.746s srv-share-backup.mount
>  10.258s nfs-kernel-server.service
>   3.311s mysql.service
>   1.444s apache2.service
>   1.344s epgd.service
>   1.012s privoxy.service
> 
> 
> /srv/share/backup lives on a Western Digital WD RED, and this device
> takes ages to spin up. So I'd rather /not/ spin this disk, if it is
> not necessary - which it isn't. That's why I've set up an automount
> unit for it.
> Now I don't understand why it is mounted on booting. /srv/share/backup
> is exported via NFS, which might be the reason for the slow
> nfs-kernel-server.service. But I have other exports on WD REDs as
> well, and they are not mounted while booting.
> 
> So why is srv-share-backup.mount started at boot-time? It's not wanted
> or directly enabled:

Most likely something is accessing the share, which trigger the mount
request. One possible candidate could be nfs-kernel-server.
If you stop exporting the share via NFS, is it still (auto)mounted?


-- 
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

Re: If Linux Is About Choice, Why Then ...

[Michael Biebl]

Am 05.04.2017 um 20:05 schrieb Dan Ritter:
> On Wed, Apr 05, 2017 at 07:26:03PM +0200, Michael Biebl wrote:
>> Am 05.04.2017 um 17:04 schrieb Dan Ritter:
>>> On Wed, Apr 05, 2017 at 03:47:33PM +0100, Jonathan Dowland wrote:
>>>> On Mon, Apr 03, 2017 at 05:06:22AM -0700, Rick Thomas wrote:
>>>>> Aside from being insulting, this is just plain untrue.  There are well 
>>>>> over
>>>>> 100,000 professional Linux sysadmins worldwide.  I'd estimate that at 
>>>>> least
>>>>> a third of them administer at least one - and probably  more than one -
>>>>> systems that work better with sysvinit than with systemd.
>>>>
>>>> That estimate sounds plucked out of the air to me.
>>>
>>> It certainly is.
>>>
>>> For example, I run on the order of a thousand servers that are
>>> running Wheezy because we haven't managed a smooth transition to
>>> Jessie yet, and systemd is a large part of that problem.
>>>
>>
>> what problems exactly do you have which are caused by systemd?
> 
> We have our own applications, built over the last 19 years, that
> are managed by sysvinit scripts which are handled by a configuration
> management system that we built and open-sourced before Chef or Puppet
> were born. Nobody wants to rewrite all of this. Initial testing of
> systemd compatibility were negative, and nothing looked so easy to fix
> that someone jumped up and said "I'll do that!"
> 

Any specifics? What problems did you run into with the sysv compat
support in systemd?


-- 
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

Re: If Linux Is About Choice, Why Then ...

[Michael Biebl]

Am 05.04.2017 um 17:04 schrieb Dan Ritter:
> On Wed, Apr 05, 2017 at 03:47:33PM +0100, Jonathan Dowland wrote:
>> On Mon, Apr 03, 2017 at 05:06:22AM -0700, Rick Thomas wrote:
>>> Aside from being insulting, this is just plain untrue.  There are well over
>>> 100,000 professional Linux sysadmins worldwide.  I'd estimate that at least
>>> a third of them administer at least one - and probably  more than one -
>>> systems that work better with sysvinit than with systemd.
>>
>> That estimate sounds plucked out of the air to me.
> 
> It certainly is.
> 
> For example, I run on the order of a thousand servers that are
> running Wheezy because we haven't managed a smooth transition to
> Jessie yet, and systemd is a large part of that problem.
> 

what problems exactly do you have which are caused by systemd?



-- 
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

Re: glade-gtk3?

[Michael Biebl]

Am 03.04.2017 um 17:18 schrieb Gene Heskett:
> Greetings;
> 
> My last question seemed to have been routed to /dev/null.
> 
> Is there a time in the foreseeable future the complete glade-gtk2 version 
> 3.8.0 kit of gfx widgits might be updated to gtk3 compatibility?
> 

https://packages.debian.org/sid/glade

glade is at version 3.20.0 and gtk3 based. What exactly are you missing?
-- 
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

Re: upgraded config files in /lib/systemd/system

[Michael Biebl]

Am 05.03.2017 um 21:29 schrieb Michael Biebl:
> Fwiw, systemctl edit (--full) foo.service can help you with that
> 
> https://www.freedesktop.org/software/systemd/man/systemctl.html#edit%20NAME%E2%80%A6
> 
> This is new in stretch, jessie's systemctl doesn't have that yet.

Just to clarify here: The drop-in mechanism works in jessie as well,
what's missing is the "systemctl edit" functionality.

Useful in that regard is also systemd-delta, which will show you local
overrides or extensions.

Regards,
Michael

-- 
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

Re: upgraded config files in /lib/systemd/system

[Michael Biebl]

Am 05.03.2017 um 20:47 schrieb Harald Dunkel:
> On 02/28/17 15:23, Dominique Dumont wrote:
> 
>> I don't understand why a change in /lib/systemd/system should trigger a 
>> conflict warning.
> 
> 
> A unit file provided by the package maintainer might introduce new
> dependencies, for example. Maybe an ExecStart or ExecStop script has
> been changed, or there are new/different command line options.
> 
> I don't think that conflicts between the user's old modified unit
> files in /etc and the new packages unit files are easy to avoid.
> 

Keep in mind, that in most cases you don't need to override the package
provided service file completely by making a full copy of it in
/etc/systemd/system

You can extend/override individual bits via drop-in files (e.g. adding
additional dependencies/orderings). For a service foo.service you create

/etc/systemd/system/foo.service.d/bla.conf
The name is arbitrary, you just need to make sure it has a .conf extension.

Fwiw, systemctl edit (--full) foo.service can help you with that

https://www.freedesktop.org/software/systemd/man/systemctl.html#edit%20NAME%E2%80%A6

This is new in stretch, jessie's systemctl doesn't have that yet.

Regards,
Michael



-- 
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

Re: X won't start after installing openbox

[Michael Biebl]

Am 27.02.2017 um 22:00 schrieb Sven Joachim:
>> [38.828] (II) VESA(0): initializing int10
>> [38.829] (EE) VESA(0): Cannot read int vect
> 
> And the vesa driver does not work either because it needs root rights
> which the X server does no longer have.  See
> /usr/share/doc/xserver-xorg-core/NEWS.Debian.gz.

If you have a no KMS capable driver, you can install xserver-xorg-legacy.


-- 
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

Re: apt's cache, was Re: Debian/Stretch - network-manager ...

[Michael Biebl]

Am 08.02.2017 um 15:38 schrieb David Wright:
> If you're worried about losing your .deb files, just copy
> them (as a user) or move them (as root) anywhere else,
> depending on how much storage you have. Using any of the -i
> -n -u options will avoid unnecessary overwriting.

Older deb files can be retrieved via http://snapshot.debian.org/.


-- 
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

Re: Debian/Stretch: how to boot in text mode

[Michael Biebl]

Am 01.02.2017 um 21:21 schrieb Ennio-Sr:
> Hi all!
> 
> After upgrading to Stretch I'm unable to find a way to boot with no GUI.
> I tried setting 'GRUB-GFXPAYLOAD_LINUX="text" in /etc/default/grub,
> moving to 'K01gdm3' all 'S??gdm3' instances in /etc/rc?.d, but nothing
> happens.
> Any help, please?

To temporarily boot into text mode, edit the kernel command line in grub
and add "systemd.unit=multi-user.target"

If you want to make this change permanent, run "systemct set-default
multi-user.target"

The default is graphical.target, which will start your display manager,
like gdm3.

Regards,
Michael


-- 
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

Re: Is the "fjes" Kernel Module loaded on every system?

[Michael Biebl]

Am 24.01.2017 um 17:17 schrieb Jens Sauer:
> Hey list,
> 
> During my custom kernel configuration using "make localmodconfig" I noticed 
> that
> the "fjes" driver was configured.
> I wondered why this network driver was needed for my laptop, so I have done 
> some
> research.
> According this [1] linux-netdev mailing list entry, which introduces the fjes
> module, it is only needed for Extended Partitions of Fujitsu Primequest 2000
> series servers.
> This mail [2] refers to a Fujitsu document in which these special Extended
> Partitions are explained.
> I am sure that I don't need this driver for my ThinkPad T450s.
> Nevertheless it is loaded because of an ACPI device "PNP0C02" which is linked 
> to
> the module [3].
> 
> TL;DR
> Can someone confirm if this module is loaded on their hardware, even if you
> don't have a Fujitsu Primequest 2000 series server?
> 
> [1]https://marc.info/?l=linux-netdev=142951966404542=2
> [2]https://lwn.net/Articles/655298/
> [3] https://cateee.net/lkddb/web-lkddb/FUJITSU_ES.html
> 
> Greetings
> 

It's also loaded here (Lenovo X220)

Afaics, this is a bug. The modinfo information for fjes is overly generic

See also
http://unix.stackexchange.com/questions/335238/is-it-normal-that-a-modalias-matches-various-devices

https://lkml.org/lkml/2016/6/8/98

Might be worthwile filing a bug report.

-- 
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

Re: shutdown fails to power off host

[Michael Biebl]

Am 18.01.2017 um 08:44 schrieb Joerg Desch:
> Am Wed, 04 Jan 2017 22:59:46 -0800 schrieb Bob McGowan:
> 
>> When I shutdown my desktop system, the screen displays messages from
>> systemd (I presume), the last of which is "Reached target Shutdown".
> 
> Just a thought...
> 
> I'm running Debian Jessie and I see the same behavior with my Thinkpad 
> T500.
> 
> In my case the reason is the Network Manager. I have 2 NFS shares mounted 
> over Wifi. The Network Manager stops Wifi before unmounting the NFS 
> shares. This leads to a long time out. After that, I see the "Reached 
> target Shutdown" message and the system in still powered.
> 
> I have to unmount the NFS volumes first and than I can shutdown the 
> system.

You could unmount the NFS shares via a dispatcher hook
See man NetworkManager → pre-down


-- 
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

Re: Systemd: no error but "maintenance mode"

[Michael Biebl]

Am 10.01.2017 um 20:08 schrieb Steffen Dettmer:
> On Sun, Jan 8, 2017 at 7:45 PM, Joe  wrote:
>>> What happened before:
>>> I had issue with a Debian server SATA bus [1]. I noticed because
>>> apt-get upgrade hung, because initramfs updater calls "sync" which
>>> hang because of [1]. All operations accessing a certain (backup) disk
>>> blocked. Shutdown over network. It was reported server power LED still
>>> up, so probably shutdown hang, too. Server was powered off and disk
>>> pulled.
>>
>> The disc you removed: did it have an entry in /etc/fstab? Does this
>> server use systemd? If yes to both, comment the /etc/fstab entry or
>> give it an extra option 'noauto'.
> 
> In short: yes, this was the problem. I didn't found this first because
> there was no easily visible error message.
> 
> Thanks you for your help!
> 
> Do you - or anyone - know how to mount a disk at boot without
> failing when it is not there?

https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-auto-mounts-incompat


-- 
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

Re: systemd requires "plymouth" on server? (was: Systemd: no error but "maintenance mode")

[Michael Biebl]

Am 10.01.2017 um 00:43 schrieb deloptes:
> Steffen Dettmer wrote:
> 
>> I'd rather keep it as simple as possible
> 
> you can still use sysvinit as init

The shell scripts used by sysvinit are not simpler. More familiar maybe,
but not simpler.


-- 
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

Re: Urgent help needed - Debian boot hangs

[Michael Biebl]

Am 06.01.2017 um 20:17 schrieb h...@hanswkraus.com:
> I get now the Boot menu, but I don't see the DVD drive.


> Any more tips for me? Since it's a bit late I will wait until tomorrow.

If you can get into the grub menu, then go to the advanced options menu
and select the recovery mode option.
This will boot into a rescue shell where ifupdown is not started.

I assume you have a dead lock in one of your if-up.d hooks in
/etc/network/if-up.d/

You could disable them one by one to find out which one it is.



-- 
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

Re: hotpluggable member of a bridge

[Michael Biebl]

Am 05.01.2017 um 10:29 schrieb to...@tuxteam.de:
> and delegates to specialized subsystems. In a pinch you can just sneak
> a complete shell script in an udev rule (and I'm guilty of having done
> such a thing [2]), but doing this as "system architecture" might lead to
> madness :-)

> [2] Once, for a customer: inserting the right storage medium (with
>the right UUID) triggered a system backup.

Please don't do that. udev is a not a service manager and starting (long
running) tasks from a udev rule is bad.
See also the udev man page:

Starting daemons or other long-running processes is not appropriate
for udev; the forked processes, detached or not, will be
unconditionally killed after the event handling has finished.

If you want to trigger the start of a service via udev, tag the device
with "systemd" and use SYSTEMD_WANTS [1] via a custom udev rule, like

,TAG+="systemd",ENV{SYSTEMD_WANTS}="foo.service"



Regards,
Michael

[1]
https://www.freedesktop.org/software/systemd/man/systemd.device.html#SYSTEMD_WANTS=

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-- 
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

Re: Preventing ACL on cdrom drive...

[Michael Biebl]

Am 23.12.2016 um 18:54 schrieb Nimrod:
> Hi,
> 
> sorry for this trivial question, but I really tried to find an answer on
> the web without any result.
> 
> This is the issue: on a computer at home (shared among relatives, each
> with his/her own account), the first user that logs in after boot locks
> the cdrom drive, and any other user that logs in can't eject the cdrom:
> only the first user can eject it.
> 
> Is there a way to avoid this? Being a home computer there are no privacy
> issues: the cdrom drive is used just for CD ripping or burning, there's
> no reason to prevent each other access to the unit.

Does it help if you mount the cdrom as shared?
See https://udisks.freedesktop.org/docs/latest/udisks.8.html →
UDISKS_FILESYSTEM_SHARED

https://wiki.archlinux.org/index.php/udisks#Mount_to_.2Fmedia_.28udisks2.29



-- 
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

Re: systemd automount - Parameter TimeoutIdleSec ignored?

[Michael Biebl]

Am 11.12.2016 um 18:04 schrieb Andreas Born:
> Michael Biebl wrote:
>> Am 08.12.2016 um 13:33 schrieb Andreas Born:
>>> Hi all,
>>> I need a device to be automatically mounted on access and unmounted when 
>>> being
>>> idle. My /etc/fstab entry:
>>>
>>> /dev/sdc1  /mnt/auto  ext4  defaults,noauto,x-systemd.automount,\
>>> x-systemd.idle-timeout=10   0   0
>>>
>>> Systemd correctly creates the mnt-auto.mount und mnt-auto.automount unit 
>>> files
>>> and automounting works perfectly.
>>>
>>> x-systemd.idle-timeout=10 is getting translated to TimeoutIdleSec=10s within
>>> mnt-auto.automount. According to the manpages (sytemd.automount(5)),  the
>>> parameter TimeoutIdleSec specifies the time interval after which the device 
>>> is
>>> to be be unmounted:
>>>
>>> "TimeoutIdleSec: Configures an idle timeout. Once the mount has been idle 
>>> for
>>> the specified time, systemd will attempt to unmount."
>>>
>>> However, this never happens. It seems that this parameter is completely
>>> ignored and the device never unmounted.
>>>
>>> Is it a bug, or what did i miss to get it working?
>>
>> Are you sure nothing is keeping that FS busy?
> 
> yes, I'm quite sure. The device is empty, lsof shows no open handle, and the
> only access to the filesystem was 'ls -al ' to trigger the
> automount and to list its content.

Might be
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821944

-- 
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

systemd-journald fails to start due to corrupted /etc/machine-id (was: Re: systemd-journald fails)

[Michael Biebl]

Am 10.12.2016 um 13:38 schrieb Rainer Dorsch:

> root@scw:~# cat /etc/machine-id 26da2c29c6a545fd9af95d29ca9b5a5a 6df 
> root@scw:~#
> 
> Not sure how the 6df ended in /etc/machine-id, but after removing
> that things seem to have settled:

> I upgraded from a fresh jessie installation (image from scaleway, I
> did not install myself). Is it worthwhile to chase down the origin of
> the 6df or is this a known issue which should not affect the standard
> upgrade path from jessie to stretch?

Sounds like https://github.com/systemd/systemd/issues/4475


-- 
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

Re: systemd-journald fails

[Michael Biebl]

Am 04.12.2016 um 16:18 schrieb Rainer Dorsch:
> The system is hosted at scaleway, i.e. it is not a Debian kernel, which
> is running.

What kernel is that? Can you check if all requirements as outlined in
/usr/share/doc/systemd/README.gz are fulfilled?


-- 
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

Re: systemd automount - Parameter TimeoutIdleSec ignored?

[Michael Biebl]

Am 08.12.2016 um 13:33 schrieb Andreas Born:
> Hi all,
> I need a device to be automatically mounted on access and unmounted when being
> idle. My /etc/fstab entry:
> 
> /dev/sdc1  /mnt/auto  ext4  defaults,noauto,x-systemd.automount,\
> x-systemd.idle-timeout=10   0   0
> 
> Systemd correctly creates the mnt-auto.mount und mnt-auto.automount unit files
> and automounting works perfectly.
> 
> x-systemd.idle-timeout=10 is getting translated to TimeoutIdleSec=10s within
> mnt-auto.automount. According to the manpages (sytemd.automount(5)),  the
> parameter TimeoutIdleSec specifies the time interval after which the device is
> to be be unmounted:
> 
> "TimeoutIdleSec: Configures an idle timeout. Once the mount has been idle for
> the specified time, systemd will attempt to unmount."
> 
> However, this never happens. It seems that this parameter is completely
> ignored and the device never unmounted.
> 
> Is it a bug, or what did i miss to get it working?

Are you sure nothing is keeping that FS busy?


-- 
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

Re: systemd and initial tmpfs mounts

[Michael Biebl]

Am 08.12.2016 um 13:32 schrieb Andreas Born:
> Hi all,
> 
> earlier in SysV there was /etc/default/tmpfs to configure the initial mounts
> like /run, /run/lock, /dev/shm, /tmp and so on. Now with systemd there is
> /lib/systemd/system/tmp.mount as unit file for /tmp, but where are the other
> tmpfs mounts configured? Which part of systemd is responsible for them?
> 
> (I need to setup size and options)

systemd has hard-coded defaults for them [1].
Overriding those entries is simple: Just add an entry to /etc/fstab with
the options you want.



[1]
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/src/core/mount-setup.c#n73


-- 
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

Re: WiFi after initial install

[Michael Biebl]

wiki.archlinux.org/index.php/NetworkManager#Connect_to_network_with_secret_on_boot



Am 5. Dezember 2016 16:31:41 MEZ, schrieb Mark Fletcher :
>Hello the list!
>
>I have a Mini-ITX PC, a few months old, running KDE on Stretch. 
>
>When I installed it, I used a Stretch netinst image burned to a USB 
>stick and had the wired ethernet plugged in, for speed during the 
>installation. (and also because I didn't know what fun and games I'd
>end 
>up having with firmware if I tried to install with WiFi).
>
>After the duly-installed machine was located in its final home, well
>out 
>of reach of ethernet cables, I set up the WiFi using native KDE network
>
>tool thingy (bottom right corner of the screen).
>
>This works but has the, to me significant, disadvantage that if a user 
>has not logged into the machine, it is not connected to the network. So
>
>I can't fire up the machine and then log into it remotely from my other
>
>computers to do remote maintenance etc.
>
>It also seems to lose the network when the machine locks, but I am not 
>sure about this, as the machine is right on the edge of the WiFi 
>router's range, so it could be just getting lost when it goes quiet. I 
>have purchased a WiFi extension and will be setting it up once I have 
>networking more comfortably installed on this box.
>
>So, what I'd like to do, is set up WiFi networking on this box the 
>"right", up to date, "Debian" way, so it becomes available on boot and 
>doesn't require someone to have logged into KDE before the machine can 
>be accessed remotely.
>
>I'm somewhat aware of systemd-networkd, and I know that it is
>super-easy 
>to set up a DHCP-based wired ethernet connection that way, and I also 
>know it is possible to do so with a WiFi connection too -- but I 
>strongly suspect that is not the "Debian way".
>
>The WiFi connection is secured with a password, and my access point is 
>also a DHCP server. I'm expecting to use DHCP to get an IP address as I
>
>do with all other machines on my network.
>
>All my past Debian experience of setting up WiFi is pre-systemd / 
>pre-stretch, and a long time in my past so I have forgotten more than I
>
>ever knew :) Outside Debian, I've done it on LFS using systemd-networkd
>
>-- I know that can be made to work but it doesn't seem very Debianesque
>
>to me.
>
>Any suggestions on what I should do to set this up?
>
>TIA
>
>Mark

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: forcefsck inconsistency

[Michael Biebl]

Am 29.11.2016 um 08:40 schrieb Pierre Frenkiel:
>   For example, how do you explain the presence in syslog of 12 times
>   the same 12 lines?

The lines you posted are not the same. They are for different mount points.


-- 
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

Re: forcefsck inconsistency

[Michael Biebl]

Am 28.11.2016 um 19:35 schrieb Pierre Frenkiel:
>  It seems that one must not be too curious, as each time you dig too
>  deep, you find some kind of mystery.

On the contrary, I think this is what makes Linux great. There might be
things which are a mystery to you at first, but you are allowed to look
behind the curtain.

It's certainly one reason why I love Linux. I can take it apart and go
as deep as I want.

Michael
-- 
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

Re: forcefsck inconsistency

[Michael Biebl]

Am 28.11.2016 um 15:10 schrieb Pierre Frenkiel:
> On Mon, 28 Nov 2016, Michael Biebl wrote:

>  thank you for this usefull information, but some inconsistency remains:
> 
> in /run/initramfs/fsck.log, I find:
> 
>  Log of fsck -C -a -V -t ext4 /dev/sda2
>  Sat Nov 26 06:53:12 2016
> 
>  fsck from util-linux 2.25.2
>  [/sbin/fsck.ext4 (1) -- /dev/sda2] fsck.ext4 -a -C0 /dev/sda2
>  /dev/sda2: clean, 424229/1679360 files, 3245606/6704384 blocks
> 
>  Sat Nov 26 06:53:13 2016
>  
> 
> and tune2fs -l /dev/sda2 gives:
> 
> Last checked: Fri Nov 25 22:45:38 2016
> 
> and on an other PC, the difference is much bigger (24/10/2016 and
> 17/11/2016)
> 
> as for fsck-root, it is empty on both.

Oh, this is quite simple to explain.
If your file system is clean, fsck will simply do nothing.

The "Last checked" attribute is only reset, if fsck is actually run due to
1/ unclean file system
2/ forced fsck (fsck.mode=force on the kernel command line)
3/ max mount count or check interval reached.



-- 
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

Re: forcefsck inconsistency

[Michael Biebl]

Am 28.11.2016 um 14:11 schrieb Richard Hector:
> On 26/11/16 22:03, Pierre Frenkiel wrote:
>>  According the tune2fs output, the check on / was actually done.
>>  I naïvely looked at syslog to find the checked devices, and I
>> could  not imagine
>>  that the fsck checks are reported in syslog for all partitions, but
>> not for /...
> 
> Because / was mounted read-only while being checked, so syslog couldn't
> be written, perhaps?

/ and /usr are fscked by the initramfs.
Assuming you use initramfs-tools, which is the default in Debian, you
can find the log files at
/run/initramfs/fsck*


-- 
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

Re: A full /var partition destroyed 3 hours of my life!

[Michael Biebl]

[rsyslog maintainer speaking here]

Am 15.11.2016 um 06:00 schrieb Borden Rhodes:
> One of the culprits in my full /var partition was a 3 gig syslog file
> which has only been getting bigger since January despite running
> logrotate -f. I try to run it this time but I'm told that it can't

I'd be interested to find out, why logrotation was not done
automatically. Do you have cron installed and running?
Do you have  /etc/cron.daily/logrotate which works when executed and a
corresponding /etc/logrotate.d/rsyslog?

Any idea why logrotate was not run or failed to do its job?

> My question, therefore, is whether this is a btrfs bug that got
> triggered by the full /var partition or whether Debian is designed to
> break irrecoverably when /var fills up. Any ideas of what happened?
> 

That sounds like a btrfs issue. Which kernel is that?
I do remember btrfs having problems when the disk runs full.

-- 
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

Re: Ensure service keeps running with systemd

[Michael Biebl]

Am 28.10.2016 um 00:50 schrieb Tobias Brink:
> Hello!
> 
> tl;dr: When a daemon exits "normally" (for example due to signal 15)
>although it should not exit (because I did not call "systemctl
>stop"), systemd does not consider it a failure.

[..]

> How do I tell systemd that it is a failure if the daemon is not running,
> except if I explicitly killed it via "systemctl stop" or similar? I
> either can't seem to find the right google query or this is not the
> right way to go about this.

There is also Restart=always

See
https://www.freedesktop.org/software/systemd/man/systemd.service.html#Restart=

and
https://www.freedesktop.org/software/systemd/man/systemd.service.html#SuccessExitStatus=
-- 
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

Re: Network manager not showing saved network connections

[Michael Biebl]

Am 24.10.2016 um 00:26 schrieb Michael Biebl:
> Am 23.10.2016 um 23:30 schrieb Paul Seyfert:
>> Deleting almost all connections (204 out of 214) in
>> /etc/NetworkManager/system-connections/ and only keeping those few I am
>> sure to use[2], I get a working state (all connections which I want to
> 
> ..
> 
>> Is this a known bug[3]? Any suggestions what to test/investigate/other
>> information I should provide?
> 
> Yes, known issue. You are hitting a D-Bus limit here.
> http://bugs.debian.org/781007

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773525
is the merged bug report with more details.

-- 
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