Sponsored Content
Operating Systems Linux Red Hat Production unexpectedly server rebooted Post 302488607 by vasdaax on Tuesday 18th of January 2011 12:35:33 AM
Old 01-18-2011
Bug

Might be problem of RAM. Reinsert the RAM and check.
 

10 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

How to identify who rebooted the linux server

Hi All, Since server is located at remote place so how to identify which user rebooted the server. Is there any way to identify the user. Thanks in advance, Reg, Bache Gowda (1 Reply)
Discussion started by: bache_gowda
1 Replies

2. Solaris

server rebooted by user

Hi, how can i know who has rebooted the server? even last command is not displaying the user, wheather any way to track the user. (2 Replies)
Discussion started by: manoj.solaris
2 Replies

3. HP-UX

How can we know that the server was rebooted by which user in hp unix

Hi , Plz some one can help me ... How can we know that the server was rebooted by which user in hp unix and linux. Regards Venkata Jeevan (1 Reply)
Discussion started by: jeevanbv
1 Replies

4. AIX

server rebooted

Hi, I want to know how to find out which user has rebooted the server? I have used last command but it is not giving username though it is showing below output reboot --------------- date Regards, Manoj (5 Replies)
Discussion started by: manoj.solaris
5 Replies

5. UNIX for Dummies Questions & Answers

To know the server which the production is pointing to?

Hi, How to know which server(Application or webserver) the production link or url is pointing to? Is there any command to get the server IP address? Thanks in advance. (3 Replies)
Discussion started by: venkatesht
3 Replies

6. Solaris

How to check when a solaris server got rebooted

In Windows we can check the event viewer for entries 6005,6006,6009 to confirm the system down times, as in when it got down and when it came back up. Is there some similar log files in Solaris/RHEL that I can check the timings and who or what caused the system reboot. I am an absolute newbie. Need... (4 Replies)
Discussion started by: lubu
4 Replies

7. Red Hat

Server rebooting unexpectedly

hi, I have been working on Solaris am very new to linux. My concern is as it goes....our server is getting rebooted automatically and I am not able to understand anything from the var log messages. Could anybody help me out in troubleshooting the issue. 2.6.18-128.el5 #1 x86_64 GNU/Linux is... (1 Reply)
Discussion started by: EmbedUX
1 Replies

8. Red Hat

Server uptime is showing 0hr but server not rebooted

Hi One of our server is showing the uptime 0hr 5mints there is no log in /var/log/messages there is no log in command "last" kernel version is 2.4.9 (RH2.1 AS) What could be the reason for this. is this issue is related to uptime counter reached max how to verify this. Best Regards KVK (4 Replies)
Discussion started by: venikathir
4 Replies

9. Red Hat

Server rebooted.

Hi, Yesterday one of Red Hat Server 4.2 got rebooted. I have checked /var/log/messages, but does not find out any serious issue related to peformance / hardware issue. how to find out why server was rebooted? (1 Reply)
Discussion started by: manoj.solaris
1 Replies

10. UNIX for Dummies Questions & Answers

AIX mount goes away if server rebooted

I have been mounting a directory to share with a windows pc. If i reboot the AIX box the mount goes away. How can i make the mount permanent? Here is the command I use to make the mount exportfs -i -o root=<servername> /path (1 Reply)
Discussion started by: fierfek
1 Replies
SYSTEMD-CRYPTSETUP-GENERATOR(8) 			   systemd-cryptsetup-generator 			   SYSTEMD-CRYPTSETUP-GENERATOR(8)

NAME
systemd-cryptsetup-generator - Unit generator for /etc/crypttab SYNOPSIS
/lib/systemd/system-generators/systemd-cryptsetup-generator DESCRIPTION
systemd-cryptsetup-generator is a generator that translates /etc/crypttab into native systemd units early at boot and when configuration of the system manager is reloaded. This will create systemd-cryptsetup@.service(8) units as necessary. systemd-cryptsetup-generator implements systemd.generator(7). KERNEL COMMAND LINE
systemd-cryptsetup-generator understands the following kernel command line parameters: luks=, rd.luks= Takes a boolean argument. Defaults to "yes". If "no", disables the generator entirely. rd.luks= is honored only by initial RAM disk (initrd) while luks= is honored by both the main system and the initrd. luks.crypttab=, rd.luks.crypttab= Takes a boolean argument. Defaults to "yes". If "no", causes the generator to ignore any devices configured in /etc/crypttab (luks.uuid= will still work however). rd.luks.crypttab= is honored only by initial RAM disk (initrd) while luks.crypttab= is honored by both the main system and the initrd. luks.uuid=, rd.luks.uuid= Takes a LUKS superblock UUID as argument. This will activate the specified device as part of the boot process as if it was listed in /etc/crypttab. This option may be specified more than once in order to set up multiple devices. rd.luks.uuid= is honored only by initial RAM disk (initrd) while luks.uuid= is honored by both the main system and the initrd. If /etc/crypttab contains entries with the same UUID, then the name, keyfile and options specified there will be used. Otherwise, the device will have the name "luks-UUID". If /etc/crypttab exists, only those UUIDs specified on the kernel command line will be activated in the initrd or the real root. luks.name=, rd.luks.name= Takes a LUKS super block UUID followed by an "=" and a name. This implies rd.luks.uuid= or luks.uuid= and will additionally make the LUKS device given by the UUID appear under the provided name. rd.luks.name= is honored only by initial RAM disk (initrd) while luks.name= is honored by both the main system and the initrd. luks.options=, rd.luks.options= Takes a LUKS super block UUID followed by an "=" and a string of options separated by commas as argument. This will override the options for the given UUID. If only a list of options, without an UUID, is specified, they apply to any UUIDs not specified elsewhere, and without an entry in /etc/crypttab. rd.luks.options= is honored only by initial RAM disk (initrd) while luks.options= is honored by both the main system and the initrd. luks.key=, rd.luks.key= Takes a password file name as argument or a LUKS super block UUID followed by a "=" and a password file name. For those entries specified with rd.luks.uuid= or luks.uuid=, the password file will be set to the one specified by rd.luks.key= or luks.key= of the corresponding UUID, or the password file that was specified without a UUID. rd.luks.key= is honored only by initial RAM disk (initrd) while luks.key= is honored by both the main system and the initrd. SEE ALSO
systemd(1), crypttab(5), systemd-cryptsetup@.service(8), cryptsetup(8), systemd-fstab-generator(8) systemd 237 SYSTEMD-CRYPTSETUP-GENERATOR(8)
All times are GMT -4. The time now is 03:56 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy