NEW YEAR PROGRAM BONUS

2017-01-09 Thread Turkish Airlines
Turkish Airlines
Istanbul Ataturk International Airport 
Istanbul
Turkish

Turkish Airlines Headquarter in  Istanbul is happy to inform you that the 
Turkish Airlines Awards Program selection's was conducted at the headquarters 
of our grounds of Ataturk Airport Istanbul, Turkish Airlines Awards Program is 
registered and organized in accordance with the Board of Star Alliance.

Therefore, we are Pleased to inform you about the status of your glorious 
victory notification from Turkish Airlines Program Committee is hereby issued 
you with a Ticket Number to your email address: TKHA-0651567/IST1, With Bonus 
Referrence Number: TKHA/ZN6-77999-09, With Lucky Draw Number: TKHA-95-87912 
which your email address was selected as a winner of The Turkish Airlines 
Awards 2017 selection of our yearly Program draw, You have subsequently won the 
Turkish Airlines Awards in the first group selections Program.

Regarding the above notice, we have officially approved the payment of a sum of 
$250,000,00 USD ( Two Hundred And Fifty Thousand United State Dollars) only for 
you and your family as a Awards as the Certified winner of Turkish Airlines 
Awards selection program, Our Organizing Committee of the Turkish Airlines 
Awards Program will immediately initiate Instant Transfer/Wire Funds of your $ 
250,000,00 USD (Two Hundred And Fifty Thousand United State Dollars) as soon as 
you have contacted them. Therefore, you are advised to contact the Turkish 
Airlines Awards Redemtion Desk below

Organizing Committee of Turkish Airlines Program is described as below:


Contact Person: Bari Aysel Dilek
Claim Officer in Charge
Organizing Committee Turkish Airlines LOC)
Email:  turkish-...@outlook.com.tr
==

Full Name:
Contact Address:
Phone Number:
Your Country:
Personal E-mail:

Organizing Committee of the Turkish Airlines Awards Program is happy that you 
do read and understood the content of this email and also sending greetings to 
you and your family with Love and Good Health Thank You.

Sincerely,
CEO: Temel Kotil
Turkish Airlines 
©2017 Turkish Airlines
All Rights Reserved. Turkish Airlines Co.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#850703: systemd: incorrect LSB support with monit's init script

2017-01-09 Thread Vincent Lefevre
Package: systemd
Version: 232-8
Severity: normal

The monit service (from the monit package) should be started last and
stopped first. This is not the case with systemd.

I've attached monit's init script.

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3
ii  libapparmor12.10.95-8
ii  libaudit1   1:2.6.7-1
ii  libblkid1   2.29-1
ii  libc6   2.24-8
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-3
ii  libgcrypt20 1.7.5-2
ii  libgpg-error0   1.26-1
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-4
ii  libkmod223-2
ii  liblz4-10.0~r131-2
ii  liblzma55.2.2-1.2
ii  libmount1   2.29-1
ii  libpam0g1.1.8-3.5
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.6-3
ii  libsystemd0 232-8
ii  mount   2.29-1
ii  util-linux  2.29-1

Versions of packages systemd recommends:
ii  dbus1.10.14-1
ii  libpam-systemd  232-8

Versions of packages systemd suggests:
ii  policykit-10.105-17
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.126
ii  udev 232-8

-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
Storage=persistent

/etc/systemd/system.conf changed:
[Manager]
DefaultTimeoutStopSec=20s


-- no debconf information
#!/bin/sh

### BEGIN INIT INFO
# Provides:  monit
# Required-Start:$remote_fs
# Required-Stop: $remote_fs
# Should-Start:  $all
# Should-Stop:   $all
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: service and resource monitoring daemon
# Description:   monit is a utility for managing and monitoring
#processes, programs, files, directories and filesystems
#on a Unix system. Monit conducts automatic maintenance
#and repair and can execute meaningful causal actions
#in error situations.
### END INIT INFO

set -e

. /lib/lsb/init-functions

DAEMON=/usr/bin/monit
CONFIG=/etc/monit/monitrc
NAME=monit
DESC="daemon monitor"
MONIT_OPTS=
PID="/run/$NAME.pid"

# Check if DAEMON binary exist
[ -f $DAEMON ] || exit 0

[ -f "/etc/default/$NAME" ] && . /etc/default/$NAME

MONIT_OPTS="-c $CONFIG $MONIT_OPTS"

monit_not_configured () {
  if [ "$1" != "stop" ]
  then
printf "\tplease configure $NAME and then edit /etc/default/$NAME\n"
printf "\tand set the \"START\" variable to \"yes\" in order to allow\n"
printf "\t$NAME to start\n"
  fi
  exit 0
}

monit_checks () {
  # Check if START variable is set to "yes", if not we exit.
  if [ "$START" != "yes" ]
  then
monit_not_configured $1
  fi
}

case "$1" in
  start)
log_daemon_msg "Starting $DESC" "$NAME"
monit_checks $1
if start-stop-daemon --start --quiet --oknodo --pidfile $PID --exec $DAEMON 
-- $MONIT_OPTS 1>/dev/null
then
  log_end_msg 0
else
  log_end_msg 1
fi
;;
  stop)
log_daemon_msg "Stopping $DESC" "$NAME"
if start-stop-daemon --retry TERM/5/KILL/5 --oknodo --stop --quiet 
--pidfile $PID 1>/dev/null
then
  log_end_msg 0
else
  log_end_msg 1
fi
;;
  reload)
log_daemon_msg "Reloading $DESC configuration" "$NAME"
if start-stop-daemon --stop --signal HUP --quiet --oknodo --pidfile $PID 
--exec $DAEMON -- $MONIT_OPTS 1>/dev/null
then
  log_end_msg 0
else
  log_end_msg 1
fi
;;
  restart|force-reload)
log_daemon_msg "Restarting $DESC" "$NAME"
start-stop-daemon --retry TERM/5/KILL/5 --oknodo --stop --quiet --pidfile 
$PID 1>/dev/null
if start-stop-daemon --start --quiet --oknodo --pidfile $PID --exec $DAEMON 
-- $MONIT_OPTS 1>/dev/null
then
  log_end_msg 0
else
  log_end_msg 1
fi
;;
  syntax)
$DAEMON $MONIT_OPTS -t
;;
  status)
status_of_proc -p $PID $DAEMON $NAME
;;
  *)
log_action_msg "Usage: /etc/init.d/$NAME 
{start|stop|reload|restart|force-reload|syntax|status}"
;;
esac

exit 0
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#850703: systemd: incorrect LSB support with monit's init script

2017-01-09 Thread Martin Pitt
Hello Vincent,

Vincent Lefevre [2017-01-09 15:15 +0100]:
> The monit service (from the monit package) should be started last and
> stopped first. This is not the case with systemd.
>
> # Should-Start:  $all
> # Should-Stop:   $all

Please note that the SysV concept of "$all" is notoriously broken (what if
another package uses $all too?), and cannot be represented sensibly in any
non-serial init system (systemd, upstart, and even sysv with startpar). If
monit needs to start/stop after/before other services, these should be
enumerated explicitly.

That said, the SysV generator could approximate this a bit better by running
"After=multi-user.target" instead of "Before=multi-user.target", i. e. similar
to Type=idle.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers


Bug#850703: systemd: incorrect LSB support with monit's init script

2017-01-09 Thread Michael Biebl
Am 09.01.2017 um 16:41 schrieb Martin Pitt:
> Hello Vincent,
> 
> Vincent Lefevre [2017-01-09 15:15 +0100]:
>> The monit service (from the monit package) should be started last and
>> stopped first. This is not the case with systemd.
>>
>> # Should-Start:  $all
>> # Should-Stop:   $all
> 
> Please note that the SysV concept of "$all" is notoriously broken (what if
> another package uses $all too?), and cannot be represented sensibly in any
> non-serial init system (systemd, upstart, and even sysv with startpar). If
> monit needs to start/stop after/before other services, these should be
> enumerated explicitly.

Heh, I was about to write the (almost) exact same reply :-)

> That said, the SysV generator could approximate this a bit better by running
> "After=multi-user.target" instead of "Before=multi-user.target", i. e. similar
> to Type=idle.

As I was curious, how many packages are potentially affected, I grepped
over the archive. We have 17 packages using $all, 2 are sysvinit
specific, 4 have a native service file, so the remaining 11 are
potential candidates.

The idea of using After=multi-user.target is interesting. I probably
wouldn't complain if a patch for that was applied.

On the other hand, for the few packages remaining still shipping SysV
init scripts only, those could just add native service files.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
1  bootchart/init.d/bootchart:# Required-Start:$remote_fs $all
2  cardstories/init.d/cardstories:# Required-Start:$all
   cardstories/init.d/cardstories:# Required-Stop: $all
3  debian-edu-install/init.d/xdebian-edu-firstboot:# Required-Start:
$remote_fs $all
4  dhcp-probe/init.d/dhcp-probe:# Required-Start:$local_fs $remote_fs 
$syslog $network $all
5  dtc-xen-firewall/init.d/dtc-xen-firewall:# Required-Start:$remote_fs $all
   dtc-xen/init.d/dtc-xen:# Required-Start:$all
6  monit/init.d/monit:# Should-Start:  $all
   monit/init.d/monit:# Should-Stop:   $all
7  reniced/init.d/reniced:# Required-Start:$all
8  syslog-nagios-bridge/init.d/syslog-nagios-bridge:# Required-Start:$all
   syslog-nagios-bridge/init.d/syslog-nagios-bridge:# Required-Stop: $all
9  torque-scheduler/init.d/torque-scheduler:# Required-Start:$all
   torque-scheduler/init.d/torque-scheduler:# Required-Stop: $all
   torque-scheduler/init.d/torque-scheduler:# Should-Start:  $all
   torque-scheduler/init.d/torque-scheduler:# Should-Stop:   $all
10 xymon-client/init.d/xymon-client:# Should-Start:  $all
11 xymon/init.d/xymon:# Should-Start:  $all

12 bootchart2/init.d/bootchart-done:# Required-Start:$remote_fs $all
13 cloud-init/init.d/cloud-final:# Required-Start:$all cloud-config
14 plymouth/init.d/plymouth:# Required-Start:   udev $remote_fs $all
15 watchdog/init.d/watchdog:# Required-Start:$all
   watchdog/init.d/watchdog:# Required-Stop: $all
   watchdog/init.d/wd_keepalive:# X-Start-Before:$all

16 initscripts/init.d/rc.local:# Required-Start:$all
   initscripts/init.d/rmnologin:# Required-Start:$remote_fs $all
   initscripts/init.d/single:# Required-Start:$local_fs $all killprocs
17 bootlogd/init.d/stop-bootlogd:# Required-Start:$local_fs $all
   bootlogd/init.d/stop-bootlogd-single:# Required-Start:$local_fs $all



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#850703: systemd: incorrect LSB support with monit's init script

2017-01-09 Thread Vincent Lefevre
Hi Martin,

On 2017-01-09 16:41:20 +0100, Martin Pitt wrote:
> Hello Vincent,
> 
> Vincent Lefevre [2017-01-09 15:15 +0100]:
> > The monit service (from the monit package) should be started last and
> > stopped first. This is not the case with systemd.
> >
> > # Should-Start:  $all
> > # Should-Stop:   $all
> 
> Please note that the SysV concept of "$all" is notoriously broken
> (what if another package uses $all too?),

I suppose that both should fall in the same class, with no
dependencies between them. Actually, this is how it is specified
in .

  $all  facility supported by insserv to start a script after all
the scripts not depending on $all, at the end of the boot
^
sequence. This only work for start ordering, not stop
ordering. Depending on a script depending on $all will
give incorrect ordering, as the script depending on $all
will be started after the script depending on it. 

According to this description, monit is incorrect for Should-Stop,
but anyway, the main problem may be with Should-Start.

> and cannot be represented sensibly in any non-serial init system
> (systemd, upstart, and even sysv with startpar). If monit needs to
> start/stop after/before other services, these should be enumerated
> explicitly.

monit can monitor arbitrary services, so that I suppose that it
doesn't know in advance. A solution would be to have a way to
enumerate all the available services on the system, and add them there
dynamically at system start up, but isn't this equivalent to $all?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers


Bug#850703: systemd: incorrect LSB support with monit's init script

2017-01-09 Thread Michael Biebl
Am 09.01.2017 um 17:30 schrieb Vincent Lefevre:
> Hi Martin,
> 
> On 2017-01-09 16:41:20 +0100, Martin Pitt wrote:
>> Hello Vincent,
>>
>> Vincent Lefevre [2017-01-09 15:15 +0100]:
>>> The monit service (from the monit package) should be started last and
>>> stopped first. This is not the case with systemd.
>>>
>>> # Should-Start:  $all
>>> # Should-Stop:   $all
>>
>> Please note that the SysV concept of "$all" is notoriously broken
>> (what if another package uses $all too?),
> 
> I suppose that both should fall in the same class, with no
> dependencies between them. Actually, this is how it is specified
> in .
> 
>   $all  facility supported by insserv to start a script after all
> the scripts not depending on $all, at the end of the boot
> ^

Well, what is "the end of the boot"? How is this defined?

That aside, if you've seen the list I posted in my other reply, what
happens if monit wants to monitor reniced?


> monit can monitor arbitrary services, so that I suppose that it
> doesn't know in advance. A solution would be to have a way to
> enumerate all the available services on the system, and add them there
> dynamically at system start up, but isn't this equivalent to $all?

An alternative idea: monit has a grace period, say 5 min, when it is
started. Within this grace period it does not warn about non-running
services.

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



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#850447: systemd backport sections only 4K aligned, won't boot with arm64 64K kernel

2017-01-09 Thread Steven Capper
Hi,
FWIW, I found that disabling gold (by tweaking configure.ac) then led to
executables with the correct alignment.

Cheers,
--
Steve
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

[bts-link] source package systemd

2017-01-09 Thread bts-link-upstream
#
# bts-link upstream status pull for source package systemd
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#

user bts-link-upstr...@lists.alioth.debian.org

# remote status report for #850074 (http://bugs.debian.org/850074)
# Bug title: systemd crashes on daemon-reexec when /run is full
#  * https://github.com/systemd/systemd/issues/5016
#  * remote status changed: (?) -> open
usertags 850074 + status-open

thanks

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers