With Jessie 8.6, gdm3 and XDMCP, the GDM face browser is built but not displayed (without the attached file)

[Jean-Paul Bouchet]

Hello,

I have sent yesterday the following message (slightly modified this 
morning) but committed the mistake to attach a too big file (I thought 
that a file of 27700 bytes was not too large - Sorry...). Maybe some of 
you have already received it, but I think that it is not the case for 
most of you. So I send it again, without the attached file that can be 
found at:

https://lists.debian.org/debian-user/2016/10/msg00417.html
This attached file contains lines extracted from /var/log/system and 
/var/log/debug (uncompress it with bunzip2 after having renamed it in 
something.bz2)


We used during 2 years Gnome and gdm3 on a server with Debian Wheezy to 
let users open sessions from their Windows PC via Cygwin and xlaunch 
(xdmcp). It worked well till the upgrade to Jessie 8.5, for these 
Windows PC, as for the system console. The upgrade to Jessie 8.6 didn't 
solve the problem. I have already tried to describe these problems the 
09th of september ("gdm3 doesn't work any more after the upgrade from 
Wheezy to Jessie 8.5") :

https://lists.debian.org/debian-user/2016/09/msg00301.html

As users were satisfied by the environment provided with gnome, when the 
server ran on Wheezy, I am still trying to launch gdm3.


The story is the same for the console (when the system restarts) and for 
the Windows PC (at each launching of xlaunch): I get during a split 
second a gray background screen, probably corresponding to the GDM face 
browser, followed during a new split second by a nice blue screen 
(debian 8 on the bottom-left corner, date and time on the middle, and a 
few icons on the upper left which are able to display information about 
the connection to the network), followed by a dark screen, till the 
first mouse or keyboard event, that activates definitely the blue 
screen. For the console the dark screen is very ephemeral and has 
appeared only once, before the blue screen is displayed. I have tried to 
understand what happens really and read carefully the /var/log files. It 
is clear that the GDM face browser with the list of all users is being 
built, but I have not yet understood why it is not displayed : warning 
and errors traced in these files should be more understandable for a 
person more expert than me in Gnome and gdm3. I have prepared a file 
with extracts from /var/log/system and /var/log/debug, compressed with 
bzip2 ...


I have read the warning about the upgrading from wheezie to jessie: 
5.10. The GNOME desktop requires basic 3D graphics
The GNOME 3.14 desktop in Jessie no longer has fallback support for 
machines without basic 3D graphics. To run properly, it needs either a 
recent enough PC (any PC built in the last 10 years should have the 
required SSE2 support) or, for architectures other than i386 and amd64, 
a 3D-accelerated graphics adapter with EGL drivers.


It could mean that was I am trying to do is no more possible. But during 
the 3 first days just after the upgrading to Jessie 8.5 I had a degraded 
but nearly working situation with Windows PC: a few minutes to get the 
GDM face bowser, again a few minutes to get the session, which was then 
normal but impossible to close, and sometimes nothing. My attempts to 
improve the situation lead to a much clearer one: what I get now is 
always this nice blue screen, maybe built by gnome-screensaver (I am not 
sure at all). That was not exactly my aim... But it lets me think or 
hope that I am not in the case reported in the warning 5.10.


Today I don't ever know whether the problem I try to solve may be solved 
or not, and if it is due to an error of installation (lacking packages 
to install or packages to uninstall), or an error of configuration 
(despite my attempts to compare the new and the previous ones for gdm, 
pam, ...), an error in Cygwin installation (lacking packages) or, 
possibly, a bug of Jessie.


It would be nice if someone could answer that it works on his system : 
Jessie, gdm3 with xdmcp enabled and Windows PC emulating a X11 server 
with xlaunch (through Cygwin or another free software) to open sessions. 
The problem is not important for the console, as I can leave the blue 
screen with Ctrl-Alt-F1 and open a non-graphical session on tty1, which 
is enough for my needs. It is more annoying for the Windows PC.


Many thanks in advance ! Best regards,
Jean-Paul

Re: Linux source address selection (Was Re: url redirected in chrome/chromium, but working fine, according to ping/traceroute, lynx, w3m, iceweasel.)

[rhkramer]

Hi Andy,

Thanks very much!  It looks like quite a comprehensive answer (including 
links) that I'll surely have to read more than once to absorb.  (At that 
point, I'll ask more questions if I feel the need.)

regards,
Randy Kramer


On Tuesday, October 11, 2016 10:18:38 PM Andy Smith wrote:
> On Sun, Oct 09, 2016 at 04:23:45PM -0400, rhkra...@gmail.com wrote:
> > I'm not the OP, and I'm sort of piggybacking and going somewhat (or a
> > lot?) OT,
> 
> In that case it would be good to change the subject of the email.
> I've done so here.
> 
> > but I am curious about how old inet4 (right term?) and the new
> > inet6 addresses interact.

Other good stuff elided.

face header

[Richard Hector]

Anyone know how I can (in Icedove) either stop displaying the 'face'
header, or display it nicely as a picture?

There are a couple of users on here that have them, and they result in a
huge header section of the icedove display, leaving about 5 lines for
the content of the message.

I have the 'Display Contact Photo' extension installed, but it doesn't
seem to work (or perhaps only works on 'X-Face' headers).

Or are these users' headers simply not conforming to whatever standard
exists for this?

Cheers,
Richard



signature.asc
Description: OpenPGP digital signature

Re: Recommendation: Backup system

[Richard Hector]

On 07/10/16 23:19, Jonathan Dowland wrote:
> I don't know whether dirvish does something to improve matters, but with
> hard link trees, if you have lots of little files (such as Maildir archives
> of busy mailing lists like LKML), the amount of space consumed by the file
> system metadata to represent the trees is very high, getting towards the
> size used for the files themselves. This is compounded on some filesystems
> (the ext family amongst them) that only ever increase the amount of space
> for storing dirent metadata, never decrease it, so if you have a Maildir
> which has high churn, and you move from having a large amount of mail to
> a small amount, the storage allocated for metadata for the directory will
> remain large.

The metadata you're talking about is merely the directory entries,
right? I'm still searching, but haven't yet found info on how much space
a directory entry takes up. Any pointers would be most welcome :-)

I'm on xfs, btw.

Regardless, in the trivial case where nothing has changed between
backups, the directories in the new backup must take up exactly the same
space as the ones in the old backup, where both point to the same files.
So whether there's one set of links or several, it's still the case that
for small files, the directory entries will take proportionately more
space relative to the file - that's inevitable.

I think I'm right in saying that in the dirvish (or similar) use case,
the number of directory entries in a given directory will never decrease
anyway - except in the odd case where I discover I've backed up
something I shouldn't have (eg a huge or confidential file), and gone
through purging it from all the backups.

Richard




signature.asc
Description: OpenPGP digital signature

Script vs command line behaviour

[Mark Fletcher]

Greetings

I am observing a strange behaviour and I am wondering what stupid thing 
I have done that is causing it. A shell command that is supposed to 
start fetchmail running every 15 minutes works fine run from the command 
line, but has no effect when run from inside a script. I am running 
Jessie upgraded many times from an original install from etch, I think 
it was. Or squeeze. Whichever of those two it was that came first.

I recently took the plunge and installed Amanda to get my backups 
organised. At the moment I am only backing up the one machine but will 
expand it later to other machines on my network.

Automating the Amanda backup once I was happy with the configuration 
prompted me to write a small bash shell script, reproduced below. It 
expects to run as root. It stops the svnserve instance running on my 
machine and a mysql instance, and also stops the fetchmail daemon. Then 
it starts with a basic amanda config and, if my Windows VMs are not 
running, adds their disks and config directories to the stuff that is in 
scope for backup. If they are running it refrains from including them. 
Then, it kicks off the backup, running as the backup user. Finally, it 
restarts the services it stopped.

Then I have created a systemd service to run this script, and set up a 
systemd timer to kick off the pocess at 01:30 local time every day.

It runs fine, at the right time, except for one thing. When I get up in 
the morning and come to my computer, I find that the backup report is 
sitting in my email reporting success, SVNServe is running as it should 
be, mysql is running as it should be -- but fetchmail has not been 
restarted.

If I do sudo journalctl -b | grep fetchmail and look at this morning's 
entries, I see the following:

Oct 12 01:30:02 kazuki sudo[2197]: root : TTY=unknown ; PWD=/ ; 
USER=mark ; COMMAND=/usr/bin/fetchmail -q Oct 12 01:30:02 kazuki 
homebackup.sh[2154]: fetchmail: background fetchmail at 31717 killed. 

Oct 12 04:19:04 kazuki sudo[3582]: root : TTY=unknown ; PWD=/ ; 
USER=mark ; COMMAND=/usr/bin/fetchmail -d 900

[lines justified to be easier to read]

The first of those lines indicates the script successfully stopped 
fetchmail at 01:30 before starting the backup.

The second would appear to indicate at least that it correctly attempted 
to start fetchmail again, as my non-privileged user mark, at 04:19 when 
the backup finished. But, when I came to my computer at about 07:30 this 
morning, fetchmail was not running and all the mails to this list from 
you lovely people were backed up at my email provider waiting to be 
downloaded.

I started fetchmail by hand from the command line, and came home this 
evening to find it still running sweetly. And it'll continue to do so 
until tonight's backup run kills it, at which point I'll get up tomorrow 
morning to find it is not running again, if the experience of the last 
few days is anything to go by.

If I copy and paste the line that is supposed to restart fetchmail from 
the script (reproduced below) to a root shell, with PWD=/, and run the 
command, it works, correctly. I am stumped why it is not working from 
the script. Anyone see what I have missed? I wondered if it was paths 
not being set right, but from the above journal log you can see it 
correctly mapped the fetchmail instance to /usr/bin/fetchmail.


/etc/systemd/scripts/homebackup.sh:

#! /bin/bash

# THIS ASSUMES MYSQL AND SVNSERVE ARE RUNNING, AND WE WANT THEM RUNNING
# AGAIN ONCE DONE

# stop a couple of services we don't want running while doing backups
systemctl stop mysql
systemctl stop svnserve

# The systemctl stop for svnserve may not work as I haven't got around to 
# making a stop script for it.
# So kill the process the old fashioned way
ps -ef | grep svnserve | grep -v grep | awk '{print $2}' | xargs kill -9

# And kill fetchmail so it doesn't update the mail while we are backing up
sudo -u mark fetchmail -q

# Start with the base disklist
cp /etc/amanda/RealBackup/disklist.stem /etc/amanda/RealBackup/disklist

# If the two VirtualBox VMs are NOT running, add them to the disk list
sudo -u mark vboxmanage showvminfo "TRADER2" | grep -q "running (since" || echo 
localhost /opt/vms/TRADER2 comp-user-tar >> /etc/amanda/RealBackup/disklist
sudo -u mark vboxmanage showvminfo "TRADER2" | grep -q "running (since" || echo 
"localhost "\""/home/mark/VirtualBox VMs/TRADER2"\"" comp-user-tar" >> 
/etc/amanda/RealBackup/disklist
sudo -u mark vboxmanage showvminfo "TRADER3" | grep -q "running (since" || echo 
localhost /opt/vms/TRADER3 comp-user-tar >> /etc/amanda/RealBackup/disklist
sudo -u mark vboxmanage showvminfo "TRADER3" | grep -q "running (since" || echo 
"localhost "\""/home/mark/VirtualBox VMs/TRADER3"\"" comp-user-tar" >> 
/etc/amanda/RealBackup/disklist

# Now actually run the backup
sudo -u backup amdump RealBackup

# and restart the services we stopped
systemctl start svnserve
systemctl start mysql
sudo -u mark fetchmail -d 900



Mark

Re: Script vs command line behaviour

[Greg Wooledge]

On Wed, Oct 12, 2016 at 09:34:22PM +0900, Mark Fletcher wrote:
> # The systemctl stop for svnserve may not work as I haven't got around to 
> # making a stop script for it.
> # So kill the process the old fashioned way
> ps -ef | grep svnserve | grep -v grep | awk '{print $2}' | xargs kill -9

Please consider replacing this with some variant of:

pkill svnserve

And stop using -9 (SIGKILL).  Forever.  Pretend it never existed.

Re: Script vs command line behaviour

[Frédéric Marchal]

On Wednesday 12 October 2016 08:40:12 Greg Wooledge wrote:
> And stop using -9 (SIGKILL).  Forever.  Pretend it never existed.

That's a bit harsh. The tool exists for a good reason :-)

"Unix was not designed to stop you from doing stupid things, because that 
would also stop you from doing clever things."

Doug Gwyn, in Introducing Regular Expressions (2012) by Michael Fitzgerald

And for the curious, here is why kill -9 should only be used as a last resort 
when everything else failed:

http://unix.stackexchange.com/questions/8916/when-should-i-not-kill-9-a-process

Frederic

Re: Script vs command line behaviour

[Greg Wooledge]

On Wed, Oct 12, 2016 at 10:40:57PM +0900, Mark Fletcher wrote:
> ...Any thoughts on what is preventing the restart of fetchmail from 
> working?

Nothing in particular.  I haven't used fetchmail in many years, and
never as a "service" at the system level.  So, just general thoughts:

1) Use "systemctl status fetchmail" to see what the operating system
   thinks is happening.  Are the service process(es) still running, or
   did they terminate?  Are there informative messages?  How long did
   they run before terminating, if they did terminate?

2) Look for fetchmail-specific logs.  If you've defined a logfile location,
   look there.  Otherwise, figure out how fetchmail normally logs, and
   look where it does that.  Maybe it logs through syslog(), in which
   case you'd look for some file in /var/log, unless you've changed
   the syslog configuration to send those somewhere else.  Or maybe it
   has its own default logging location outside of the syslog()
   infrastructure.

3) If the current logs are not detailed enough, look for fetchmail-specific
   options to increase logging verbosity.

4) Log what your backup script does.  Since it's a shell script, this is
   generally done with something like:

#!/bin/sh
exec >> /var/tmp/mylog 2>&1
echo " New backup started: $(date)"
set -x

Adjust to suit your needs.  This isn't *likely* to uncover the problem,
unless you get something blazingly obvious like:

Failed to start ftechmail.service: Unit ftechmail.service failed to load: No 
such file or directory.

But as I said, these are just general thoughts about how to approach
this *kind* of problem.  And hey, you never know

Re: Script vs command line behaviour

[Mark Fletcher]

On Wed, Oct 12, 2016 at 08:40:12AM -0400, Greg Wooledge wrote:
> On Wed, Oct 12, 2016 at 09:34:22PM +0900, Mark Fletcher wrote:
> > # The systemctl stop for svnserve may not work as I haven't got around to 
> > # making a stop script for it.
> > # So kill the process the old fashioned way
> > ps -ef | grep svnserve | grep -v grep | awk '{print $2}' | xargs kill -9
> 
> Please consider replacing this with some variant of:
> 
> pkill svnserve
> 
> And stop using -9 (SIGKILL).  Forever.  Pretend it never existed.
> 

...Any thoughts on what is preventing the restart of fetchmail from 
working?

Mark

Re: Re: Icedove crashes after recent update

[Mario Pereyra]

I'm also having the same problem for about the same mentioned time, but 
I use Debian wheezy & gnome


No report of error, no log, ... no information, only the application 
disappear.

Re: Script vs command line behaviour

[Mark Fletcher]

On Wed, Oct 12, 2016 at 09:56:06AM -0400, Greg Wooledge wrote:
> On Wed, Oct 12, 2016 at 10:40:57PM +0900, Mark Fletcher wrote:
> > ...Any thoughts on what is preventing the restart of fetchmail from 
> > working?
> 
> Nothing in particular.  I haven't used fetchmail in many years, and
> never as a "service" at the system level.  So, just general thoughts:
> 
> 1) Use "systemctl status fetchmail" to see what the operating system
>thinks is happening.  Are the service process(es) still running, or
>did they terminate?  Are there informative messages?  How long did
>they run before terminating, if they did terminate?
> 

Fetchmail isn't set up as a service through systemd, although mysql and 
svnserve are. fetchmail is just started from this script (or supposed to 
be!) and launched by hand from the command line when that fails.

So at least systemd isn't complicating the issue. I'll want to get a 
service wrapped around fetchmail _eventually_ so it starts automatically 
on boot, but I haven't gotten around to that yet. Once I do, then I'll 
have to replace the command in this script with a systemctl start 
command, but I don't want to just cut to that without understanding what 
is going on here.

> 2) Look for fetchmail-specific logs.  If you've defined a logfile location,
>look there.  Otherwise, figure out how fetchmail normally logs, and
>look where it does that.  Maybe it logs through syslog(), in which
>case you'd look for some file in /var/log, unless you've changed
>the syslog configuration to send those somewhere else.  Or maybe it
>has its own default logging location outside of the syslog()
>infrastructure.
> 
> 3) If the current logs are not detailed enough, look for fetchmail-specific
>options to increase logging verbosity.
> 
> 4) Log what your backup script does.  Since it's a shell script, this is
>generally done with something like:
> 
> #!/bin/sh
> exec >> /var/tmp/mylog 2>&1
> echo " New backup started: $(date)"
> set -x
> 
> Adjust to suit your needs.  This isn't *likely* to uncover the problem,
> unless you get something blazingly obvious like:
> 
> Failed to start ftechmail.service: Unit ftechmail.service failed to load: No 
> such file or directory.
> 
> But as I said, these are just general thoughts about how to approach
> this *kind* of problem.  And hey, you never know
> 

Yeah, I think I'll have to try some combination of these ideas. In a 
strange way I'm encouraged actually, I was half-cringing expecting 
someone to go "Mark, you idiot, you've done XYZ stupid thing, duh!"

Mark

Re: Script vs command line behaviour

[Nicolas George]

Le primidi 21 vendémiaire, an CCXXV, Mark Fletcher a écrit :
> Fetchmail isn't set up as a service through systemd, although mysql and 
> svnserve are. fetchmail is just started from this script (or supposed to 
> be!) and launched by hand from the command line when that fails.
> 
> So at least systemd isn't complicating the issue.

Maybe it is. Unlike SysV init and the other legacy tools, systemd keeps
tracks of the processes it starts, grouping them as "units" using pgroups.
Your script tries to start fetchmail in background, using the -d option
(which, by the way, is not present in the man page for the testing version,
unless I have trouble reading); that would allow it to escape SysV init and
cron, for example, but not systemd.

I do not know the exact rules systemd applies to the processes started by a
timer, but it is entirely possible this is the source of your problem.
Remember when all the systemd haters started shouting "systemd broke screen
and tmux" because the option to clean up the processes in finished user
sessions had been activated by default.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Script vs command line behaviour

[Gene Heskett]

On Wednesday 12 October 2016 09:40:57 Mark Fletcher wrote:

> On Wed, Oct 12, 2016 at 08:40:12AM -0400, Greg Wooledge wrote:
> > On Wed, Oct 12, 2016 at 09:34:22PM +0900, Mark Fletcher wrote:
> > > # The systemctl stop for svnserve may not work as I haven't got
> > > around to # making a stop script for it.
> > > # So kill the process the old fashioned way
> > > ps -ef | grep svnserve | grep -v grep | awk '{print $2}' | xargs
> > > kill -9
> >
> > Please consider replacing this with some variant of:
> >
> > pkill svnserve
> >
> > And stop using -9 (SIGKILL).  Forever.  Pretend it never existed.
>
> ...Any thoughts on what is preventing the restart of fetchmail from
> working?
>
> Mark

My best guess is a stale lock file, leftover because you used the brute 
force kill, so it did not exit gracefully, cleaning up after itself.  My 
own scripts restart fetchmail on a nightly basis so fetchmail can't muck 
up an sa-train-bayes run.  It uses "killall fetchmail", then waits 20 
seconds for any mail in the spamd pipes to drain, and when the sa-learn 
bits are completed:

# and restore fetchmail but let the disks synch first
sleep 6
fetchmail -d 180 --fetchmailrc /home/gene/.fetchmailrc

This has not failed in many years.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Icedove crashes after recent update

[Tony Baldwin]

On 10/12/2016 08:55 AM, Mario Pereyra wrote:

I'm also having the same problem for about the same mentioned time, but
I use Debian wheezy & gnome

No report of error, no log, ... no information, only the application
disappear.



similar experience.
Seems to occur randomly here, like when I delete something or mark it 
read/unread, or move something to another folder, and other  generally 
trivial operations.


tony
--
http://tonybaldwin.me
all tony, all the time

Re: New amd64 kernel in Debian x86 testing?

[Stefan Monnier]

>> AFAICT, the latest amd64 kernel in Debian x86 testing is still 3.16
>> (i.e. the one from Debian stable).
>> Any idea why there's no newer one?
> Since linux 4.0, the -amd64 kernel flavor is no longer built on i386:

Hmm... that's what I thought.

> To install the -amd64 kernel via multiarch, run these commands:
>
> # dpkg --add-architecture amd64
> # apt-get update
> # apt-get install linux-image-amd64:amd64

Thanks.  It's kind of silly to have to download the complete list of amd64
packages, but I can live with it.

And I guess I can --remove-architecture right after that so I don't keep
downloading/updating the list of amd64 packages all the time.


Stefan

Re: Script vs command line behaviour

[Mark Fletcher]

On Wed, Oct 12, 2016 at 04:29:01PM +0200, Nicolas George wrote:
> Le primidi 21 vendémiaire, an CCXXV, Mark Fletcher a écrit :
> > Fetchmail isn't set up as a service through systemd, although mysql and 
> > svnserve are. fetchmail is just started from this script (or supposed to 
> > be!) and launched by hand from the command line when that fails.
> > 
> > So at least systemd isn't complicating the issue.
> 
> Maybe it is. Unlike SysV init and the other legacy tools, systemd keeps
> tracks of the processes it starts, grouping them as "units" using pgroups.
> Your script tries to start fetchmail in background, using the -d option
> (which, by the way, is not present in the man page for the testing version,
> unless I have trouble reading); that would allow it to escape SysV init and
> cron, for example, but not systemd.
> 
> I do not know the exact rules systemd applies to the processes started by a
> timer, but it is entirely possible this is the source of your problem.
> Remember when all the systemd haters started shouting "systemd broke screen
> and tmux" because the option to clean up the processes in finished user
> sessions had been activated by default.
> 
You bring up a good point, actually. I'm calling systemctl stop and 
systemctl start to stop and start mysql -- and I'm doing that in a 
script that is itself being called by a systemd unit (the one triggered 
by the timer). I wonder if that is in some way naughty and contributing 
to the problem? Hmmm, is there a better way to ensure these services are 
stopped before the backup starts and started again afterwards?

Although that said, MySQL and SVNServe (which are started by systemd) go 
down and come back up fine, it is the one that ISN'T currently 
controlled by systemd that I am having problems with.

Hmmm, interesting, although I'm not sure quite what to do with that...

Mark

Re: Script vs command line behaviour

[Darac Marjal]

On Thu, Oct 13, 2016 at 12:09:12AM +0900, Mark Fletcher wrote:

On Wed, Oct 12, 2016 at 04:29:01PM +0200, Nicolas George wrote:

Le primidi 21 vendémiaire, an CCXXV, Mark Fletcher a écrit :
> Fetchmail isn't set up as a service through systemd, although mysql and
> svnserve are. fetchmail is just started from this script (or supposed to
> be!) and launched by hand from the command line when that fails.
>
> So at least systemd isn't complicating the issue.

Maybe it is. Unlike SysV init and the other legacy tools, systemd keeps
tracks of the processes it starts, grouping them as "units" using pgroups.
Your script tries to start fetchmail in background, using the -d option
(which, by the way, is not present in the man page for the testing version,
unless I have trouble reading); that would allow it to escape SysV init and
cron, for example, but not systemd.

I do not know the exact rules systemd applies to the processes started by a
timer, but it is entirely possible this is the source of your problem.
Remember when all the systemd haters started shouting "systemd broke screen
and tmux" because the option to clean up the processes in finished user
sessions had been activated by default.


You bring up a good point, actually. I'm calling systemctl stop and
systemctl start to stop and start mysql -- and I'm doing that in a
script that is itself being called by a systemd unit (the one triggered
by the timer). I wonder if that is in some way naughty and contributing
to the problem? Hmmm, is there a better way to ensure these services are
stopped before the backup starts and started again afterwards?


https://www.freedesktop.org/software/systemd/man/systemd.unit.html says

Conflicts=
 A space-separated list of unit names. Configures negative requirement 
 dependencies. If a unit has a Conflicts= setting on another unit, 
 starting the former will stop the latter and vice versa. Note that 
 this setting is independent of and orthogonal to the After= and 
 Before= ordering dependencies.


 If a unit A that conflicts with a unit B is scheduled to be started at 
 the same time as B, the transaction will either fail (in case both are 
 required part of the transaction) or be modified to be fixed (in case 
 one or both jobs are not a required part of the transaction). In the 
 latter case, the job that is not the required will be removed, or in 
 case both are not required, the unit that conflicts will be started 
 and the unit that is conflicted is stopped.


So you should, in theory, be able to add "Conflicts=mysql" to your unit 
and systemd will arrange for it to be stopped before running your unit, 
and started thereafter.




Although that said, MySQL and SVNServe (which are started by systemd) go
down and come back up fine, it is the one that ISN'T currently
controlled by systemd that I am having problems with.

Hmmm, interesting, although I'm not sure quite what to do with that...

Mark



--
For more information, please reread.

Re: Script vs command line behaviour

[Mark Fletcher]

On Wed, Oct 12, 2016 at 10:36:40AM -0400, Gene Heskett wrote:
> On Wednesday 12 October 2016 09:40:57 Mark Fletcher wrote:
> 
> > On Wed, Oct 12, 2016 at 08:40:12AM -0400, Greg Wooledge wrote:
> > > On Wed, Oct 12, 2016 at 09:34:22PM +0900, Mark Fletcher wrote:
> > > > # The systemctl stop for svnserve may not work as I haven't got
> > > > around to # making a stop script for it.
> > > > # So kill the process the old fashioned way
> > > > ps -ef | grep svnserve | grep -v grep | awk '{print $2}' | xargs
> > > > kill -9
> > >
> > > Please consider replacing this with some variant of:
> > >
> > > pkill svnserve
> > >
> > > And stop using -9 (SIGKILL).  Forever.  Pretend it never existed.
> >
> > ...Any thoughts on what is preventing the restart of fetchmail from
> > working?
> >
> > Mark
> 
> My best guess is a stale lock file, leftover because you used the brute 
> force kill, so it did not exit gracefully, cleaning up after itself.  My 

Uh no I didn't, not for fetchmail. It was svnserve I brute force killed. 
And svnserve starts again just fine. Greg's led you down the garden path 
by zeroing in on what is evidently a pet peeve of his but actually has 
nothing to do with the problem.

I shut down fetchmail with fetchmail -q which is how the man page says 
to do it.

> 
> # and restore fetchmail but let the disks synch first
> sleep 6
> fetchmail -d 180 --fetchmailrc /home/gene/.fetchmailrc
> 
> This has not failed in many years.

I wonder if passing the --fetchmailrc option will work. The systemd 
journal snippet I included in my original post shows that fetchmail is 
getting started successfully -- but by the morning it's not running. 
Now, clearly nothing gets past me, but that means it's terminating. 
Which suggests it doesn't know what it is supposed to do once it is 
started. Which suggests maybe it's not finding the fetchmailrc file?

I'm going to try specifying where .fetchmailrc is for tonight's run and 
see what happens.

Will report back in the morning. If this nails it, it suggests that 
something is screwy about the environment when run from a systemd script 
(that's only ever been root) compared to running it from a root terminal 
(which was logged in as mark, then su'd to root)

Mark

Re: Script vs command line behaviour

[Nicolas George]

Le duodi 22 vendémiaire, an CCXXV, Mark Fletcher a écrit :
> You bring up a good point, actually. I'm calling systemctl stop and 
> systemctl start to stop and start mysql -- and I'm doing that in a 
> script that is itself being called by a systemd unit (the one triggered 
> by the timer). I wonder if that is in some way naughty and contributing 
> to the problem? Hmmm, is there a better way to ensure these services are 
> stopped before the backup starts and started again afterwards?

This is exactly the correct way of proceeding: with systemctl start, you are
not directly starting the service (like you did with /etc/init.d/something
start, with all the drawbacks it implies, like user environment bleeding
into the service); instead, you are sending a message to systemd to tell it
to start the service.

From your point of view, it does not change anything, but as a design, it is
much cleaner.

> Although that said, MySQL and SVNServe (which are started by systemd) go 
> down and come back up fine, it is the one that ISN'T currently 
> controlled by systemd that I am having problems with.

It IS controlled by systemd, everything is. But you neglected to inform
systemd there was something special about it.

You can debug what happens to your script by adding this line near the
beginning:

strace -f -e execve -s 1 -o /tmp/my_script.$$.$(date +%Y%m%d%H%M%S) &

Tomorrow, the file in /tmp will tell you what happened.

Note that the idea of the stale PID file is worth checking still.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Script vs command line behaviour

[Frank]

Op 12-10-16 om 17:17 schreef Mark Fletcher:

I wonder if passing the --fetchmailrc option will work. The systemd
journal snippet I included in my original post shows that fetchmail is
getting started successfully -- but by the morning it's not running.
Now, clearly nothing gets past me, but that means it's terminating.
Which suggests it doesn't know what it is supposed to do once it is
started. Which suggests maybe it's not finding the fetchmailrc file?


Looking at question C6 in the fetchmail FAQ, I'd say that's quite 
likely... :)


Regards,
Frank

==
C6. Fetchmail works OK started up manually, but not from an init script.

Often, startup scripts have a different environment than an interactive 
login shell. For instance, $HOME might point to "/root" when you are 
logged in as root, but it might be either unset, or set to "/" when the 
startup scripts are running. That means fetchmail at startup can't find 
the .fetchmailrc.


Pick a location (such as /etc/fetchmailrc) and use fetchmail's -f option 
to point fetchmail at it. That should solve the problem.

Re: New amd64 kernel in Debian x86 testing?

[Sven Joachim]

On 2016-10-12 10:45 -0400, Stefan Monnier wrote:

>>> AFAICT, the latest amd64 kernel in Debian x86 testing is still 3.16
>>> (i.e. the one from Debian stable).
>>> Any idea why there's no newer one?
>> Since linux 4.0, the -amd64 kernel flavor is no longer built on i386:
>
> Hmm... that's what I thought.
>
>> To install the -amd64 kernel via multiarch, run these commands:
>>
>> # dpkg --add-architecture amd64
>> # apt-get update
>> # apt-get install linux-image-amd64:amd64
>
> Thanks.  It's kind of silly to have to download the complete list of amd64
> packages, but I can live with it.

It certainly slows down apt operations somewhat, also all packages show up
twice in aptitude's TUI which is a bit annoying.

> And I guess I can --remove-architecture right after that so I don't keep
> downloading/updating the list of amd64 packages all the time.

No, dpkg refuses to remove an architecture as long as there are packages
of that architecture installed.  What you _can_ do, however, is to limit
the architecture list to i386 in sources.list(5), e.g.

deb [arch=i386] http://ftp.debian.org/debian/ testing main

Whether the bandwith save is worth the cost of not getting timely kernel
upgrades is debatable, of course.

Cheers,
   Sven

Resume From Hibernation Failing With Automatic Reboot - Debian Testing

[Sicelo]

Hi

I am running Debian Testing, and for the last two weeks or so, it is
impossible to successfully resume the system from hibernation.

The actual hibernation process goes through fine, as also shown in the
systemd journal. When powering the system back on, with the `quiet`
kernel cmdline removed, I can see that the hibernation image is reloaded
successfully. Immediately after that the laptop reboots for no apparent
reason, with the result that the file systems are not cleanly unmounted.

I have enabled persistent journal for systemd, and when booting, i add
`systemd.log_level=debug` to the kernel command line. Unfortunately the
error does not appear in the journal.

In addition to the foregoing, I have also run the tests mentioned in the
'basic-pm-debugging' document from kernel.org [1]. The laptop fails all
the tests, and hibernation does not work even with `init=/bin/sh`
specified in the kernel command line as per the referenced document.

The hardware is a ThinkPad X40 (yes, old), running Debian testing with
the 4.7.0-1-686 #1 SMP Debian 4.7.5-1 kernel. It has 1GB RAM, and a 60GB
SSD.

At this time I am out of clues on what to check and how. I understand
that the hardware is old, but if it would be possible to narrow down the
problem to a specific package, etc. I will appreciate any clues or
suggestions you can give.

Regards
Sicelo A. Mhlongo

[1]
https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt


signature.asc
Description: PGP signature

Re: Script vs command line behaviour

[Jude DaShiell]

On Wed, 12 Oct 2016, Mark Fletcher wrote:


Date: Wed, 12 Oct 2016 08:34:22
From: Mark Fletcher 
To: debian-user@lists.debian.org
Subject: Script vs command line behaviour
Resent-Date: Wed, 12 Oct 2016 12:34:43 + (UTC)
Resent-From: debian-user@lists.debian.org

Greetings

I am observing a strange behaviour and I am wondering what stupid thing
I have done that is causing it. A shell command that is supposed to
start fetchmail running every 15 minutes works fine run from the command
line, but has no effect when run from inside a script. I am running
Jessie upgraded many times from an original install from etch, I think
it was. Or squeeze. Whichever of those two it was that came first.

I recently took the plunge and installed Amanda to get my backups
organised. At the moment I am only backing up the one machine but will
expand it later to other machines on my network.

Automating the Amanda backup once I was happy with the configuration
prompted me to write a small bash shell script, reproduced below. It
expects to run as root. It stops the svnserve instance running on my
machine and a mysql instance, and also stops the fetchmail daemon. Then
it starts with a basic amanda config and, if my Windows VMs are not
running, adds their disks and config directories to the stuff that is in
scope for backup. If they are running it refrains from including them.
Then, it kicks off the backup, running as the backup user. Finally, it
restarts the services it stopped.

Then I have created a systemd service to run this script, and set up a
systemd timer to kick off the pocess at 01:30 local time every day.

It runs fine, at the right time, except for one thing. When I get up in
the morning and come to my computer, I find that the backup report is
sitting in my email reporting success, SVNServe is running as it should
be, mysql is running as it should be -- but fetchmail has not been
restarted.

If I do sudo journalctl -b | grep fetchmail and look at this morning's
entries, I see the following:

Oct 12 01:30:02 kazuki sudo[2197]: root : TTY=unknown ; PWD=/ ;
USER=mark ; COMMAND=/usr/bin/fetchmail -q Oct 12 01:30:02 kazuki
homebackup.sh[2154]: fetchmail: background fetchmail at 31717 killed.

Oct 12 04:19:04 kazuki sudo[3582]: root : TTY=unknown ; PWD=/ ;
USER=mark ; COMMAND=/usr/bin/fetchmail -d 900

[lines justified to be easier to read]

The first of those lines indicates the script successfully stopped
fetchmail at 01:30 before starting the backup.

The second would appear to indicate at least that it correctly attempted
to start fetchmail again, as my non-privileged user mark, at 04:19 when
the backup finished. But, when I came to my computer at about 07:30 this
morning, fetchmail was not running and all the mails to this list from
you lovely people were backed up at my email provider waiting to be
downloaded.

I started fetchmail by hand from the command line, and came home this
evening to find it still running sweetly. And it'll continue to do so
until tonight's backup run kills it, at which point I'll get up tomorrow
morning to find it is not running again, if the experience of the last
few days is anything to go by.

If I copy and paste the line that is supposed to restart fetchmail from
the script (reproduced below) to a root shell, with PWD=/, and run the
command, it works, correctly. I am stumped why it is not working from
the script. Anyone see what I have missed? I wondered if it was paths
not being set right, but from the above journal log you can see it
correctly mapped the fetchmail instance to /usr/bin/fetchmail.


/etc/systemd/scripts/homebackup.sh:

#! /bin/bash

# THIS ASSUMES MYSQL AND SVNSERVE ARE RUNNING, AND WE WANT THEM RUNNING
# AGAIN ONCE DONE

# stop a couple of services we don't want running while doing backups
systemctl stop mysql
systemctl stop svnserve

# The systemctl stop for svnserve may not work as I haven't got around to
# making a stop script for it.
# So kill the process the old fashioned way
ps -ef | grep svnserve | grep -v grep | awk '{print $2}' | xargs kill -9

# And kill fetchmail so it doesn't update the mail while we are backing up
sudo -u mark fetchmail -q

# Start with the base disklist
cp /etc/amanda/RealBackup/disklist.stem /etc/amanda/RealBackup/disklist

# If the two VirtualBox VMs are NOT running, add them to the disk list
sudo -u mark vboxmanage showvminfo "TRADER2" | grep -q "running (since" || echo 
localhost /opt/vms/TRADER2 comp-user-tar >> /etc/amanda/RealBackup/disklist
sudo -u mark vboxmanage showvminfo "TRADER2" | grep -q "running (since" || echo "localhost 
"\""/home/mark/VirtualBox VMs/TRADER2"\"" comp-user-tar" >> /etc/amanda/RealBackup/disklist
sudo -u mark vboxmanage showvminfo "TRADER3" | grep -q "running (since" || echo 
localhost /opt/vms/TRADER3 comp-user-tar >> /etc/amanda/RealBackup/disklist
sudo -u mark vboxmanage showvminfo "TRADER3" | grep -q "running (since" || echo "localhost 
"\""/home/mark/VirtualBox VMs/TRADER3"\"" comp-user-tar" >> /etc/am

Re: Script vs command line behaviour

[Mark Fletcher]

On Wed, Oct 12, 2016 at 04:51:40PM -0400, Jude DaShiell wrote:

> ># and restart the services we stopped
> >systemctl start svnserve
> >systemctl start mysql
> >sudo -u mark fetchmail -d 900
> >
> I think the issue revolves around unknown pwd.  Perhaps running fetchmail as
> the user rather than root will solve that problem.

sudo -u mark fetchmail -d 900   _IS_ running fetchmail as the user, no?

Mark

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Lisi Reisz]

On Friday 07 October 2016 15:43:17 Vincent Lefevre wrote:
> On 2016-10-04 22:51:34 +0100, Lisi Reisz wrote:
> > On Tuesday 04 October 2016 08:25:46 Vincent Lefevre wrote:
> > > my position remains the same:
> > > aptitude is poorly designed.
> >
> > Fine.  So don't use it.  But moaning won't help anyone, not even you. 
> > You don't like Aptitude.  We get the message.  So don't use Aptitude.
>
> And what do you propose instead?

I don't use Sid, so haven't tested out which package managers are good for it 
when there are problems, but how about looking at apt or apt-get?  Ben says 
that he has great success with apt-get.  Apt-get is much less aggressive than 
aptitude - but less fully featured.

If I use aptitude with a large number of upgrades, I try to break it up.  At 
the very least I do
# aptitude update
#aptitude -s safe-upgrade
# aptitude safe-upgrade
# aptitude -s full-upgrade
# aptitude full-upgrade

Thus giving me a chance to sort out problems before I wreck my system!

Then nothing  gets removed if I don't want it to be.

And there are tricks like:

http://serverfault.com/questions/696241/mark-packages-to-be-installed-and-run-aptitude-in-interactive-mode
 

 If you ask what people find good for that particular problem, I am sure you 
will get a lot of helpful replies.

Lisi

Re: Script vs command line behaviour

[Mark Fletcher]

On Wed, Oct 12, 2016 at 05:59:10PM +0200, Frank wrote:
> Op 12-10-16 om 17:17 schreef Mark Fletcher:
> >I wonder if passing the --fetchmailrc option will work. The systemd
> >journal snippet I included in my original post shows that fetchmail is
> >getting started successfully -- but by the morning it's not running.
> >Now, clearly nothing gets past me, but that means it's terminating.
> >Which suggests it doesn't know what it is supposed to do once it is
> >started. Which suggests maybe it's not finding the fetchmailrc file?
> 
> Looking at question C6 in the fetchmail FAQ, I'd say that's quite likely...
> :)
> 

Likely though it may have been, I'm afraid it didn't work. I modified 
the last line of the script to: sudo -u mark fetchmail -d 900 
--fetchmailrc /home/mark/.fetchmailrc

Which is the correct location of my .fetchmailrc.

Then sudo journalctl -b | grep fetchmail shows:

Oct 12 23:59:04 kazuki systemd[1]: Starting LSB: init-Script for system 
wide fetchmail daemon... 

Oct 12 23:59:04 kazuki fetchmail[2801]: Not starting fetchmail daemon, 
disabled via /etc/default/fetchmail. 

Oct 12 23:59:04 kazuki systemd[1]: Started LSB: init-Script for system 
wide fetchmail daemon. 

Oct 13 01:30:06 kazuki sudo[4323]: root : TTY=unknown ; PWD=/ ; 
USER=mark ; COMMAND=/usr/bin/fetchmail -q 

Oct 13 01:30:06 kazuki homebackup.sh[4280]: fetchmail: background 
fetchmail at 3734 killed. 

Oct 13 03:48:33 kazuki sudo[5443]: root : TTY=unknown ; PWD=/ ; 
USER=mark ; COMMAND=/usr/bin/fetchmail -d 900 --fetchmailrc 
/home/mark/.fetchmailrc

[lines justified to make them easier to read]

I rebooted yesterday evening, as I was playing around with tails, but 
that is a different story. So the above is the entirety of the output of 
the command.

The first 3 lines are the system-wide fetchmail daemon getting kicked 
off at system boot and deciding not to do anything.

Subsequently, unknown to systemd, I started fetchmail as my unprivelegd 
user mark by hand from the command line using fetchmail -d 900 . That 
invariably works correctly.

In line 4 you can see my backup script stopping fetchmail by running 
fetchmail -q as user mark. Again this command does not involve systemd 
(except for the fact that it is being executed in a script which is 
being executed by a systemd unit)

Line 5 reports the success of that command.

And line 6 _appears_ to be a successful execution of the (modified) last 
line of the script, sudo -u mark fetchmail -d 900 --fetchmailrc 
/home/mark/.fetchmailrc , except once again this morning I got up to 
find fetchmail was not running. And once again running fetchmail -d 900 
from the command line started it successfully.

So I see Nicolas and others suggested other approaches involving greater 
logging of what is going on overnight after I had gone to bed; my next 
step is to try some of those ideas.

Mark

Re: Script vs command line behaviour

[Mark Fletcher]

On Wed, Oct 12, 2016 at 04:29:01PM +0200, Nicolas George wrote:
> Le primidi 21 vendémiaire, an CCXXV, Mark Fletcher a écrit :
> > Fetchmail isn't set up as a service through systemd, although mysql and 
> > svnserve are. fetchmail is just started from this script (or supposed to 
> > be!) and launched by hand from the command line when that fails.
> > 
> > So at least systemd isn't complicating the issue.
> 
> Maybe it is. Unlike SysV init and the other legacy tools, systemd keeps
> tracks of the processes it starts, grouping them as "units" using pgroups.
> Your script tries to start fetchmail in background, using the -d option
> (which, by the way, is not present in the man page for the testing version,
> unless I have trouble reading); that would allow it to escape SysV init and
> cron, for example, but not systemd.
> 

I don't know about testing, but in Jessie, the description starts at 
line 1236 of the man page.

Also, I'm sorry, I suspect you may be right at the crux of the issue, 
but I don't completely understand what you mean. Are you saying that, 
even though the command to start fetchmail is not an invokation of a 
systemd unit, the fact that it is happening from inside a script that is 
run by a systemd unit somehow allows systemd to capture the PID for 
fetchmail, and that that in turn is having a bearing on my being able to 
restart it? If so, I don't understand the mechanism at work here, and 
I'm lost as to what to do about it.

My next step is to try your other suggestions re searching for log files 
and increasing logging in the script; will report back on what that 
finds.

Stupid question -- if I comment out the actual backup command from the 
script, can I then run the script at will in the same environment it 
would be kicked off by the timer by using systemctl start ? 
The _timer_ is enabled (linked to multi-user.wants) so it starts at 
boot, would starting the _service_ have the effect of running 
immediately and would that have any nasty side effects? I'm looking for 
a way to not have to wait until the next backup run to test the 
suggestions that have been made.

Mark

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Ben Caradoc-Davies]

On 13/10/16 12:09, Lisi Reisz wrote:

I don't use Sid, so haven't tested out which package managers are good for it
when there are problems, but how about looking at apt or apt-get?  Ben says
that he has great success with apt-get.  Apt-get is much less aggressive than
aptitude - but less fully featured.


"apt-get dist-upgrade" can be very aggressive and should be used with 
caution. In my view, the key skill for users is to recognise when an 
upgrade is likely to have unwanted effects. This requires caution and 
experience. Users who proceed with upgrades without considering the 
possible effects will have unpleasant experiences. A small amount of 
effort to investigate unusual removals or upgrades, such as identifying 
a package or looking in changelogs, will go a long way to improving user 
experience.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Icedove crashes after recent update

[Ben Caradoc-Davies]

On 13/10/16 03:43, Tony Baldwin wrote:

On 10/12/2016 08:55 AM, Mario Pereyra wrote:

I'm also having the same problem for about the same mentioned time, but
I use Debian wheezy & gnome
No report of error, no log, ... no information, only the application
disappear.

similar experience.
Seems to occur randomly here, like when I delete something or mark it
read/unread, or move something to another folder, and other  generally
trivial operations.


Setting layers.offmainthreadcomposition.enabled to false helped me:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829188
https://bugzilla.mozilla.org/show_bug.cgi?id=619621
https://bugzilla.mozilla.org/show_bug.cgi?id=1198710

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand